Artikel-Schlagworte: „PowerCLI“

Schon seit ein paar Monaten (d.h. seit vSphere 4.1) dürfen sich Nutzer der Essentials Plus sowie der Standard Edition über vMotion freuen, was vorher den hochpreisigeren Editionen vorbehalten war.

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.

Oftmals fragen sich ESX-Nutzer, ob man Dateien ähnlich wie bei VMware Workstation per Drag&Drop in virtuelle Maschinen verschieben kann. Verfechter der ultimativen Sicherheit antworten dann, dass genau das aus Isolations-Gründen nicht vorgesehen ist, man also Daten auf Nicht-VMware-Wegen in die VMs transportieren muss (was in komplizierten Netzwerk-Setups umständlich sein kann). Insofern die VMware Tools installiert sind, geht es jedoch trotz weitläufiger Meinung auch einfacher.

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.

Ein Blick über den Tellerrand hat noch niemandem geschadet und genau dafür ist die VMware PowerCLI ein gutes Beispiel. Bisher dominierte Perl SDK unsere VMware-Scripting-Ecke. Speziell in Linux/Unix-Umgebungen gefragt, kommt es nicht nur Perl-versierten Admins entgegen, sondern bildet auch das Fundament gängiger Nagios-Checks.

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.
Diesen Beitrag weiterlesen »

Hier noch eine Sammlung einiger Kleinigkeiten, die das Arbeiten mit Powershell-Skripten erleichtern

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.

Mit diesem Eintrag beginnt eine neue Phase in meinem IT-Leben, das erste Mal betrete ich das Neuland der Blog-Szene. Es soll hier um die Erfahrungen im Zusammenhang mit der Umsetzung von Virtualisierungs-Projekten gehen.

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.