Für all diejenigen, die Essentials Plus oder Standard nutzen, aber bis jetzt nicht auf 4.1 aktualisiert haben und ergo immer noch ohne vMotion auskommen müssen, sei hier das etwas betagtere aber dennoch hilfreiche Quick Migration Skript von Mike DiPetrillo erwähnt:
Interaktiv leitet dieses Quick Migration Skript durch einen Suspend-Unregister-Register-Resume Mechanismus, der eine VM kurzzeitig einfriert, auf einen anderen Host “verschiebt” und dort wieder weiterlaufen lässt. Falls man das Ganze geskriptet ablaufen lassen möchte (z.B. Evakuieren eines kompletten Hosts), existiert auch eine funktions-basierte Variante. Den Ablauf könnte man prinzipiell natürlich auch manuell vornehmen.

Man könnte aber auch einfach noch einen Grund mehr fürs Upgrade auf 4.1 ins Feld führen und sich nach erfolgtem Upgrade über vMotion out-of-the-box freuen.

PowerCLI kennt ab 4.0 Update 1, das Copy-VMGuestFiles cmdlet zum geskripteten Dateitransfer zu/von VMs und mit der Virtual Guest Console aus den VMware Labs lassen sich Dateien noch einfacher GUI-basiert hoch- oder runterladen. Bei vielen VMs ist die Orientierung etwas fummelig, aber die Entwickler haben das bereits auf der Verbesserungsliste. Die Verbindung in den Gast findet dabei über den ESX Host und die VMware-Tools statt. Einzige Voraussetzung: Credentials zum Anmelden am vCenter oder ESX Host sowie am Gast-OS in der VM. Funktioniert auch mit Nicht-Windows VMs, aber wie gesagt nur, wenn die Tools installiert sind.

Andererseits ist eine gewisse Komplexität nicht von der Hand zu weisen und gerade wenn man Perl SDK basierte Skripte mit ihren PowerCLI-Pendants vergleicht, darf man sich schonmal überlegen, welches Framework für diverse Zweck das geeignetere Werkzeug ist.

Beispielszenario Massen-VM-vMotion

Nehmen wir folgendes Szenario: Abendliche Failover-Tests in einer VDI-Umgebung mit der Bitte, doch alle 60 VMs eines Servers, dem der Stecker gezogen wird, nach erfolgten Tests wieder auf diesen Server zurückzuschieben. Manuelles Verschieben via GUI verbietet sich bei der Anzahl von selbst. Kein Problem, lässt sich mit Perl SDK machen … wenn da nicht die Neugier wäre, wie das denn alternativ mit der PowerCLI aussähe. Nach kurzem Einlesen in die Grundlagen kommt überraschend schnell Folgendes zustande.

1) Vor dem Failover-Test die Liste der aktiven VMs des betroffenen Hosts sichern.

connect-viserver vcenter.acme.com
get-vm -location (get-vmhost vdi-esx006.acme.com) | where `
  { $_.powerstate -eq "PoweredOn" } > vms.lst

2) Nach erfolgter Arbeit, den Host wieder reanimieren und die in der Zwischenzeit via HA woandershin geschwenkten VMs wieder zurückholen.

cat vms.lst | foreach { move-vm `
  -confirm:$false -vm $_ `
  -destination (get-vmhost vdi-esx006.acme.com) }

Pragmatisch und simpel

Dieses einfache Beispiel lässt sich sicherlich noch verfeinern, soll hier aber lediglich zwei Dinge verdeutlichen: Zum einen ist eine solche Anforderung in PowerCLI extrem simpel zu implementieren. Zum anderen lädt es Linux/Unix Admins dank bekannter Elemente wie Pipes, Redirection und “cat” geradezu ein, damit zu arbeiten. Und das Beste an der Sache: Sowas lässt sich auch ohne lange Einarbeitungsphase umsetzen oder aber auch mal einem Kollegen übers Telefon vermitteln. Beim Perl SDK ist meiner Meinung nach beides eher unwahrscheinlich.

Das soll nicht bedeuten, dass Perl SDK hiermit seine Darseinsberechtigung verliert. Man sollte sich lediglich überlegen, wofür man es einsetzt und ob der damit verbundene Aufwand in einem gesunden Verhältnis zum Nutzen steht. Mit Wissen über existierende Alternativen/Werkzeuge geht bekanntlich mancher Job deutlich schneller von der Hand.

Nicht nur simpel, sondern auch mächtig

Natürlich lassen sich mit PowerCLI auch beliebig komplexe Aufgaben lösen. Ein Blick ins PowerCLI cmdlets Poster verdeutlicht den Funktionsumfang und Al Renoufs PowerCLI Scripts oder einige der Gewinner-Beiträge des Script-o-Mania Contests 2010 sind Beispiele, wie sich praktische Helfer bauen lassen.

Also nichts wie los, Powershell/PowerCLI runterladen und selbst davon überzeugen, dass PowerCLI auch für eingefleischte Perl SDK-Fans eine einfach zu nutzende, äußerst hilfreiche und willkommene Ergänzung zum Scripting-Portfolio ist. Selbst (oder gerade) für Administratoren, die ansonsten mit Windows vielleicht nicht so viel am Hut haben.

1. Bestätigungsrückfrage abschalten: Bei vielen Kommandos wird bei der Ausführung eine mehr oder weniger lästige Bestätigung abgefragt:[vSphere PowerCLI] C:\> Disconnect-VIServer
   Confirm
   Are you sure you want to perform this action?
   Performing operation “Disconnect VIServer” on Target “Server
   vcenter1.vmlab.roc.consol.de”.
   [Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
   (default is “Y”):

   Dies lässt sich mit dem Parameter “-Confirm$false” beim Aufruf der entsprechenden Funktion abschalten.

2. Auf SDK-Methoden zugreifenPowershell CLI bietet auch die Möglichkeit, Methoden der API direkt aufzurufen. So dient die Methode RegisterVM_Task() dazu, eine VM über den absoluten Pfad ihrer .vmx Datei auf einem ESX-Server zu registrieren. Bei den cmdlets der Powershell konnte ich keine geeigneten Methoden dazu finden.
   Eine guter Einstieg in die Dokumentation der unterschiedlichen Skript-Schnittstellen von VMware findet sich im Dokument DOC-7270.
3. Task innerhalb von Powershell starten und Ergebnis abrufen$task = Get-View $taskMoRef
   while ($task.info.state -eq “running” -or $task.info.state -eq “queued”){
   $task = Get-View $taskMoRef
   }

   if ($task.info.error -eq $null){
   Write-Output “Task successfully completed”
   } else {
   Write-Output “Task NOT successfully completed”
   }

   Diese Sequenz prüft den Status einer zuvor erzeugten Task und wartet solange, bis sich diese beendet hat. Anschließend kann über $task.info.error festgestellt werden, ob bei der Ausführung ein Fehler auftrat.

Als Teil eines Kundenprojekts betreuen wir im Endausbau eine Installation von über 6000 virtuellen Desktops bei über 5000 Benutzern gleichzeitig, verteilt auf über 50 ESX-Instanzen. Besondere Herausforderung bei dieser Installation ist die Verwendung von SunVDI, da hier auch Sun Rays als Thin Clients verwendet werden sollen.

Bei ca. 100VMs pro ESX ist der Einsatz von VMware HA nicht mehr möglich. VMware HA unterstützt maximal bis zu 40 VMs pro ESX (Version 3.5). Um das Problem eines ESX-Ausfalls abzufangen, wurde nach einer eigenen HA-Lösung gesucht.

Als guter Ausgang hat sich dabei die Verwendung von Powershell-Snapins, VMware vSphere PowerCLI herausgestellt. Damit lassen sich mit wenigen Statements komplexe Aufgaben automatisieren.

Erste Schritte:

Die cmdlet-Snapins sind beim interaktiven Aufruf der Shell geladen, wird ein Skript über cmd.exe oder durch Doppelklick gestartet, sind die Snapins noch nicht geladen. Folgende Sequenz prüft das und lädt ggf. die Snapins nach, sollten sie nicht bereits verfügbar sein.

& {
$ErrorActionPreference = “silentlycontinue”
$vmwareSnap = get-pssnapin -name “VMware.VimAutomation.Core”
if (! $?) { add-pssnapin “VMware.VimAutomation.Core” }
}

Komplexe Anforderungen einfach umsetzen

Danach lassen sich recht einfach auch komplexe Aufgaben erledigen:

$povms = Get-VM -Server $vCenter -Location (Get-VMHost -Server $vCenter -State NotResponding) | Where-Object {$_.PowerState -eq “PoweredOn”}

Diese Sequenz liefert alle VMs, die auf einem ESX, der nicht mehr antwortet (State “NotResponding”) eingeschaltet ($_.PowerState -eq “PoweredOn”) waren.

$folder = Get-View (Get-Datacenter -Server $esxFailover -Name “ROC_VDI” | Get-Folder -Server $esxFailover -Name “SUN VDI”).ID
$respool = Get-View (Get-ResourcePool -Server $esxFailover -Location (Get-VMHost -Server $esxFailover)).ID

$destesx = Get-VMHost -Server $esxFailover -Name “esx2.vmlab.roc.consol.de”

Damit sollten eigentlich alle Informationen verfügbar sein, um eine VM, die auf einem Shared Storage abgelegt ist, auf einem anderen ESX-Server, der darauf ebenfalls Zugriff hat, zu starten.