Grundverständnis bzgl. Service Console

[McStarfighter]

Mal ne grundsätzliche Frage: Für was ist die Service Console gut? Was macht sie und tut sie was, was der vSphere Client nicht auch regeln kann?

Danke im Voraus.

[Dayworker]

Das würde mich auch mal interessieren.

[JMcClane]

Man kann dort 3rd Party Tools installieren. Z.B. hab ich dort den Agenten einer USV Anlage drin damit die VMs und auch der Host sauber runter fahren können bei Stromausfall. Geht zwar auch beim ESXi, aber dort nur über VMA.
Man kann dort eigene Scripte laufen lassen.
Man kann sich direkt allo Logfiles anschauen, das Verzeichnissystem etc... für das Troubleshooting ist die Konsole besser geeignet. Z.B. esxtop und Konsorten suche ich beim ESXi vergeblich.
Gibt bestimmt noch andere Dinge die mir grad nicht einfallen.

[Dayworker]

Das die SC abgespeckt ist, war mir bewußt. Aber "esxtop" ?
Gibt es überhaupt eine Auflistung seitens VMware, welche Befehle dem ESXi überhaupt fehlen oder ist das auch wieder eine Frage, welche Lizenz dabei verwendet wird?

[McStarfighter]

Unterm Strich fehlen dann bei nem ESXi also esxtop, esxconfig und so manche Notwendigkeit?!
Greift der vSphere Client eigentlich auf Funktionen der Service Console zurück?

[JMcClane]

Nein, tut der vSphere Client nicht.
In der ESXi Console gibt es eigentlich gar keine Befehle dieser Art. Dafür ist sie auch nicht gedacht. Dafür gibt es die RemoteCLI.

[Tschoergez]

Aus VMware-Sicht ist die Service Console ein "überbleibsel" aus alten Zeiten. So ziemlich alle Funktionen, auch die esxcfg-Befehle oder esxtop gibts in der vMA bzw. der RemoteCLI. Die heißen da dann vicfg-xyz bzw. resxtop .

Idee von VMware ist, sämtliche Funktionen über die API bereitzustellen (die auch der vSphere-Client nutzt), aber gerade beim Zugriff auf Dateien in Datastores oder die Logdateien ist das noch recht "gewöhnungsbedürftig", ums mal vorsichtig zu sagen.

Für den täglichen Betrieb und die Administration sind die vorhandenen Schnittstellen (also vSphere-Client, PowerCLI, RemoteCLI, vMA usw.) vollkommen ausreichend, da spielts also keine Rolle, ob man ESX oder ESXi verwendet.

Anders siehts aus beim Troubleshooting, da helfen der direkte Zugriff auf die logfile und das /proc-Dateisystem auf dem "vollen" ESX schon.
(Das ist zwar fast alles über den "Technical Support Mode", wie die Console via "unsupported" beim ESXi heißt, mit dem BEfehl 'vsish' auch möglich, aber als Endkunde ist das halt unsupported.)

Für den Endkunden ist der ESXi also mehr oder weniger eine Blackbox, die einfach einzurichten ist und dann fein über die grafische Oberfläche verwaltet wird. Dafür muss man aber bei Problemen relativ schnell zum VMware-Support greifen.

Der ESX bietet da ne größere Schnittstelle, die mehr möglichkeiten zum selber-troubleshooten bietet, dazu aber auch schwieriger zum einrichten, patchen ist und leichter "verkonfiguriert" werden kann.

Von eigenen Agenten bzw. Scripten auf dem ESX würde ich persönlich eher abraten. Denn die müssen wirklich vom HErsteller speziell für den ESX geschrieben worden sein, und die Vergangenheit zeigt, dass es da durchaus größere Probleme geben kann.
Hier ist man flexibler, wenn man so Dinge wie USV-Überwachung, scripte usw. von außen auf das vCenter loslässt, anstatt am einzelnen ESX anzusetzen.

Die Hardware-Überwachung funktioniert ja inzwischen auch über die CIM-Schnittstelle einigermaßen gut.

Viele Grüße,
Jörg

[McStarfighter]

Hm, gut, was wäre dann also in meinem Falle besser (siehe meinen vorherigen Post weiter oben)? Denn ich brauche ja für nen einzelnen Server kein vCenter (oder irre ich?!), kein FT, kein vMotion und den ganzen anderen Hokuspokus bei mehreren Servern. Den ESXi kann man ja auch lizenzieren und dadurch so ziemlich alles freischalten, was man beim ESX hat ...

[bla!zilla]

Tja, viele Kunden sehen die Installation von Agents in der VM aber als Weg des geringsten Wiederstandes. Ich bin da durchaus skeptisch. Ich bin z.B. kein Freund davon, z.B. HP Insight Agents in der SC zu betreiben. Backupagenten okay, die sind, wie auch USV Agenten, oft so simpel gestrickt, dass da nix passiert.

[McStarfighter]

Hm, dann nochmal bitte auf den Punkt gebracht: Braucht man die Service Console unbedingt? Denn wenn ich das richtig sehe, dann ist dein zusätzlich lizenzierter ESXi im Grunde wie der ESX, aber nur ohne Service Console. Und wenn die Service Console nicht unbedingt von Nöten ist, dann kann ich mir auch nen ESXi holen.

Danke mal wieder im Voraus ...

[irix]

Hm, dann nochmal bitte auf den Punkt gebracht: Braucht man die Service Console unbedingt? Denn wenn ich das richtig sehe, dann ist dein zusätzlich lizenzierter ESXi im Grunde wie der ESX, aber nur ohne Service Console. Und wenn die Service Console nicht unbedingt von Nöten ist, dann kann ich mir auch nen ESXi holen.

Danke mal wieder im Voraus ...

Brauch ich die Service Console? Ja.
Kann man ohne Sie leben? Ja.
Wird VMware die SC entfernen? Ja.


Die Service Console basiert auf einem RH 5.3 und ist eine priviligierte VM welche neben den normalen LINUX Bordmitteln eine Reihe von ESX spezifischen Tools mitbringt.

- Grep|awk|tail geben die Macht ueber alle Logfiles
- Ein fdisk hilft bei unwilligen LUNs
- Der CIFS oder NFS Client bindet externen Speicher an falls man doch mal was aussenrum machen muss und groessere Datenmengen zuverschieben hat
- esxcfg-* gibt dir in Sekundenschnelle einen Ueberblick ueber die Config. Sofern die Einrichtung ueber diese Kommandos erfolgt ist kannst in weniger als 2 Minuten deinen wiederhergestellen oder einen neuen ESX konfigurieren
- vcbMount und vcbRestore nur fuer ESX (leider EOL)
- vmware-cmd bzw. vimsh geben eine volle Controlle ueber die VMs und den Host. Mal eine oder alle VMs stoppen/starten.... kein Probem und ist ein Einzeiler
- Wer sich mal mit einem vDSwitch verkonfiguriert hat der weis das nur eine SC ihn retten kann
- Das herstellen des VMK Binding an den SWISCSI kann nur ueber die SC oder RCLI aber nicht ueber den VIC gemacht werden
- AD Anbindung, Serielle Schnittstellen, SNMP gibts nur fuer ESX bzw. nur rudimentaer fuer ESXi
- Einige 3rd. Party Tools oder aus der Backup/Replikations Branche moechten einen ESX
- Fixen von Snapshotunfaellen.....

Wenn du Geld fuer die Lizenz ausgibts dann bekommst du doch eh beide und hast dann die Wahl was du installieren moechtest.

Ob man das ein oder andere von der obigen Liste braucht haengt von einem selber ab und das Umfeld in dem man seine(n) ESXi(s) betreibt.
Natuerlich stehen mit RCLI auch alle Tools fuer den externen Zugriff bereit. Nur dauert es damit ein bisschen laenger weil bei jedem Kommando eine Authentifizierung gemacht werden muss.

Gruss
Joerg

[McStarfighter]

Ok, damit ist die Entscheidung für mich endlich klar. Vielen Dank.