Beim Durchstöbern der esxtop man page stösst man im Abschnitt “Experimental Features” auf eine für diesen Fall sehr nützliche Eigenschaft von esxtop. Mit den Optionen -export-entity und -import-entity lassen sich gezielt mit wenigen Handgriffen die virtuellen Maschinen herausfiltern, die man analysieren möchte.

Schritt 1:

# esxtop -export-entity entity-file

erzeugt im aktuellen Verzeichnis eine Textdatei mit allen aktuellen Entities des ESX-Servers. Dies sind neben allen VMs auf diesem ESX-Server auch die dazugehörigen Netzwerk- und Storageadapter.

Schritt 2:

Als nächstes bearbeitet man die Textdatei mit einem Editor (zB vi) und setzt vor die Zeilen ein Kommentarzeichen ‘#’, welche man nicht analysieren möchte. Da die Textdatei unter Umständen, je nach Anzahl der VMs auf dem ESX-Server, ziemlich lang sein kann, ist es eventuell besser erstmal alle VMs mit einem Kommentarzeichen zu versehen. Dazu kann beispielsweise folgendes Kommando verwendet werden:

perl -i -ne \
  'if ($_ =~ /^(|SchedGroup|Adapter|Device|NetPort|InterruptVector)$/) {
     print $_;
   } else {
     print "#$_"
   }' entity-file

In der modifizierten Datei entity-file sind nun alle Entities mit einem Kommentarzeichen versehen. Also bitte nicht vergessen bei den VMs das Kommentarzeichen wieder zu entfernen, die untersucht werden sollen.

Im letzten Schritt wird mit

# esxtop -import-entity entity-file

das angepasste Entityfile importiert und in der jetzt übersichtlichen Darstellung steht einer gezielten Analyse nichts mehr im Weg.

Aktuell werden die folgenden Hypervisor-Versionen unterstützt:

• ESX Server 3.5/ ESXi 3.5 Updates 3&4
• ESX Server 4.0 / ESXi 4.0
• Virtual Infrastructure Client oder vSphere Client für die Installation der gelieferten Appliance

Für die virtuelle Maschine, welche dann in VDI-in-a-box verwendet wird, gelten aktuell unter anderem die folgenden Einschränkungen:

• nur Windows XP (32-Bit) oder Windows 7 (32-Bit)
• dürfen nur EIN disk image mit maximal 35Gb haben

Die virtuellen Desktops, welche vom kMGR erstellt und verwaltet werden, beinhalten das Desktop-Betriebssystem, eine oder mehrere Applikationen und den Kaviza Desktop Agent (kDA). Dieser ist für die Kommunikation mit dem kMGR zuständig und protokolliert Login-Vorgänge der Benutzer, sowie den Zustand der virtuellen Desktops. Zur Administration des kMGR steht eine Web-basierte Konsole bereit.

Existieren weitere Hypervisor mit installiertem kMGR, ist es sinnvoll, diese zu einem Kaviza Grid zu verbinden. Hierdurch wird eine Lastverteilung, eine Koordination der VM-Aktivitäten und Ausfallsicherheit gewährleistet. Da das Kaviza Grid selbständig verwaltet wird, ist die Verwendung von VMware HA, VMware DRS und vMotion nicht unterstützt.

Wie bei Sun VDI gibt es bei virtuellen Desktops von VDI-in-a-box die Möglichkeit diese einfach “mitzunehmen”. Dies bedeutet, dass, wenn der Benutzer sich vom Desktop eines Endgerätes trennt und sich an einem anderen Endgerät wieder anmeldet, er seinen zuvor benutzten Desktop 1:1 wieder vorfindet. Die Liste der Merkmale wird ergänzt durch zeitbasierte, dynamische Desktops, beispielsweise für Schichtarbeiter oder für Arbeiten im Lab, sowie durch statische und Kiosk-Mode Desktops. Bei der zuletzt genannten Möglichkeit wird nach jedem Gebrauch ein neuer Desktop zur Verfügung gestellt, welcher auch eingeschränkten Zugriff beinhalten kann.

Die Zielgruppe für VDI-in-a-box von Kaviza dürften in erster Linie Schulungs- und Testumgebungen oder auch die Produktionsumgebungen von kleineren bis mittelgroßen Firmen sein. Denkbar sind natürlich auch noch andere Einsatzgebiete.