Virtual Machine Message – Moved or Copied?

Sollte eine virtuelle Maschine beim Starten bei 95 % Fortschritt hängen bleiben, sollte man meistens genauer auf das virtuelle Maschinen Icon achten. Hier ist oftmals ein gelbes „i“ vermerkt. Geht man in die Übersicht der virtuellen Maschine, sieht man Folgendes:

question

Auch in den Logs der virtuellen Maschine kann ich diese Situation wiederfinden:

vmx| Msg_Question:
vmx| [msg.uuid.altered] This virtual machine may have been moved or copied.
vmx|
vmx| In order to configure certain management and networking features VMware ESX needs to know which.
vmx|
vmx| Did you move this virtual machine, or did you copy it?
vmx| If you don’t know, answer “I copied it”.
vmx|
vmx| —————————————-

Wieso müssen Sie diese Frage beantworten?
  • Die virtuelle Maschine war bereits auf Ihrem ESXi Host registriert, anschließend wurde die Registrierung allerdings aufgehoben und die Maschine auf einen anderen Datastore verschoben
  • Bei standalone ESXi Host kommt diese Meldung oft nach einem BIOS Update des Hosts vor

Ursache dieser durchaus sinnvollen Frage ist die UUID (universally unique identifier) der VM. Die UUID dient als Identifizierungsmerkmal der virtuellen Maschine und unterscheidet diese somit von anderen VM’s. Die UUID einer virtuellen Maschine (128 bit) basiert einerseits auf dem Identifier des physischen Hosts, sowie auf dem Pfad zur Konfigurationsdatei der virtuellen Maschine (.vmx). Die UUID wird beim ersten Einschalten, sowie beim Verschieben einer virtuellen Maschine generiert. Es gibt zwei Arten von UUID’s:

  • uuid.bios
  • uuid.location (Gehashter Pfad zur .vmx Datei)

Registrieren wir nun eine virtuelle Maschine, die händisch auf einen anderen Datastore verschoben wurde und starten diese, vergleicht der ESXi Host die vorhandene uuid.location innerhalb der .vmx mit dem tatsächlichen Pfad zur virtuellen Maschine. Weichen diese beiden Pfade voneinander ab, müssen Sie zum Starten der Maschine die oben genannte Frage beantworten.

Was ist der Unterschied zwischen „I moved it“ und „I copied it“?

Sollten Sie ganz bewusst die VM nur verschoben haben, können Sie die Frage guten Gewissens mit „I moved it“ beantworten. Anschließend wird innerhalb der .vmx Datei zwar die uuid.location auf einen Hashwert für den neuen Pfad zur virtuellen Maschine geändert, allerdings bleiben uuid.bios und die MAC – Adresse des Netzwerkadapters unangetastet.

Sollten Sie die VM z.B. händischen kopiert haben oder sich einfach nicht sicher sein, woher diese VM stammt, antworten Sie mit „I copied it“. Anschließend werden neben der uuid.location auch die Werte uuid.bios, sowie die MAC – Adresse des Netzwerkadapters neu generiert.

Man sollte einigermaßen vorsichtig mit dem Beantworten dieser Frage umgehen, da auf Basis der UUID auch andere Identifier (z.B. MAC – Adresse) generiert werden. Anderseits sollte man auch immer im Hinterkopf haben, dass viele Softwarekomponenten (besonders Lizenzierungssoftware) von einer bestimmten MAC – Adresse abhängen und nach dem Ändern dieser eventuell nicht mehr richtig funktionieren.

Ich hatte vor einem Monat den Fehlerfall, dass ca. 100 virtuelle Maschinen innerhalb einer VMware View Umgebung diese Frage zu beantworten hatten. Diesen Vorgang konnte ich via PowerCLI vereinfachen:

Connect-VIServer vCenter_FQDN
Get-VM | Get-VMQuestion | Set-VMQuestion -Option “I moved it”/”I copied it” -Confirm:$false

How to simulate a bad network connection with MacOS

Oft stellt sich die Frage, wie viel Bandbreite für einen virtuellen Desktop notwendig ist. Besonders bei sehr schlecht angebundenen Außenstellen oder Mitarbeitern, die über UMTS oder andere Verbindungen arbeiten, besteht oftmals die Angst, dass diese nicht qualitativ ausreichend versorgt werden können.

Die Qualität der Verbindung hängt von mehreren Faktoren ab:

  • Geschwindigkeit der Verbindung
  • Latenz
  • Packet Loss
  • Wie aufwendig ist die Darstellung innerhalb des Desktops?

Der letzte Punkt ist meiner Meinung nach der Wichtigste. Ein Benutzer, der schnell Outlook (Outlook Version 2013 ausgeklammert) um seine Mails zu lesen, wird nicht so viel Bandbreite benötigen wie ein Benutzer, der an verschiedene Bilder via Photoshop arbeitet. Da es wie hier beschrieben immer auf den jeweiligen Anwendungsfall ankommt, empfehle ich immer: Probieren, Testen und Forschen!

Während es unter Windows verschiedene kommerzielle oder auch freie Tools (WANem) gibt, können unter MacOS Boardmittel (Um ehrlich zu sein sind das eher FreeBSD Mittel) benutzt werden. Wir können mittels Pipes Netzwerkgeschwindigkeit, Latenzen oder auch Packet Loss simulieren. Um diese Pipes anzulegen, einfach den Terminal öffnen:

# Anlegen einer Pipe um alle Verbindungen zu „simulieren“:

$ sudo  ipfw add pipe 1 ip from any to any

# Nun die Einstellungen der Pipe anpassen:

$ sudo  ipfw pipe 1 config delay 100ms bw 1Mbit/s plr 0.2

Mit Hilfe dieser Pipe simulieren wir nun 100ms Latenz, eine Bandbreite von maximal 1Mbit/s und einen Packet Loss von 20 %. Diese Einstellungen können jederzeit angepasst werden. Somit kann man sich von einem bestimmten Einstiegspunkt immer weiter „herunterhangeln“, bis man die ungefähre Mindestleitung des Netzwerkanschlusses simuliert hat. Hilfreich sind hier immer die jeweiligen Knowledge Anwender der Anwendung.

Das nun nicht weiterhin mit dieser Netzwerkverbindung gearbeitet werden muss, werfen wir die Pipe noch heraus:

$ sudo ipfw -q flush

vSphere 5.5 U1 NFS issue

Derzeit haben updatewillige vSphere Benutzer die Wahl zwischen Pest und Cholera: Entweder sie haben Lust unter vSphere 5.5 mit dem allseits beliebten E1000 Purplescreen Bekanntschaft zu machen oder sie nehmen NFS Datastore Disconnects unter vSphere 5.5 U1 in Kauf.

Bug Nummer 1 habe ich persönlich noch nicht miterlebt, allerdings schon aus den verschiedensten Erzählungen erfahren. Nachdem ich vom Problem der NFS Disconnects hörte, wollte ich dieses sofort nachstellen, da 90 % meiner Kunden NFS verwenden und ich ihnen sehr gerne erklären würde, wieso das Update auf Version 5.5 U1 derzeit nicht möglich ist. Nach dem Upgrade meines Labhosts, dauerte es nicht lang, bis ich Folgendes im Log entdeckte:

[vob.storage.apd.start] Device or filesystem with identifier [----] has entered the All Paths Down state.

Diese Meldung wiederholte sich alle paar Minuten. Die Disconnects waren meist nicht von großer Dauer, aber ein Disconnect ist immerhin ein Disconnect zu viel. Was mir allerdings sofort auffiel: Ich bekam keinerlei Fehlermeldungen im vSphere Web- bzw. C# Client. Leider sind keine Standardalarme für APD (All Paths Down) Events vorhanden, also müssen wir diese selbst kreieren:

Im vSphere Web Client eine Alarmdefinition hinzufügen:

Menü

Anschließend den gewünschten Anzeigenamen vergeben, das Überwachen der Hosts festlegen und die Option “Bestimmte Ereignisse…” anwählen:

Definition Richtig

Anschließend die folgenden drei Trigger setzen:

  • esx.problem.storage.apd.start
  • esx.problem.vmfs.nfs.server.disconnect
  • esx.problem.storage.apd.timeout

specify

Wenn nun eine dieser gesetzten Trigger erfüllt wird, wird ein Alarm im vCenter erzeugt.

Nun werden wir zumindest auch ohne Lesen der Logs benachrichtigt, dass ein APD Event aufgetreten ist. Allerdings löst dies das grundlegende Problem nicht und somit heißt es: Abwarten auf einen Patch oder Downgrade auf vSphere 5.5 (Natürlich nur mit vmxnet3 Adaptern).

Multiple-NIC vMotion

vMotion ist eines der Features, das vermutlich jeder, der schon einmal mit VMware vSphere gearbeitet hat, kennt und benutzt. Hiermit ist es möglich laufende virtuelle Maschinen im Livebetrieb von einem ESXi Host auf einen anderen ESXi Host umzuziehen. Die Tatsache, dass es seit vSphere 5.1 nun auch möglich ist, ohne Shared-Storage zwischen den beiden Hosts eine Livemigration durchzuführen, macht vMotion zu einem der genialsten Features überhaupt. Durch die Möglichkeit, neben des RAM’s der virtuellen Maschine, auch die virtuellen Disks im Livebetrieb umzuziehen, stellt sich natürlich eine Frage: Wie kitzle ich die beste Perfomance aus vMotion heraus? Hier gibt es seit dem Release von vSphere 5 eine Antwort: Multiple-NIC vMotion! Hiermit ist es nun möglich einen oder auch mehrere vMotion Vorgänge über mehrere NIC’s zu verteilen. Wie konfiguriere ich das und wie sind die Perfomanceverbesserungen?

Konfiguration:

In meiner Testumgebung stehen mir 2 dedizierte Links (Diese Konfiguration würde ich auch empfehlen) zur Verfügung. Für diese beiden Uplinks lege ich zu aller Erst einen neuen vSwitch an. Innerhalb des vSwitches müssen wir nun den ersten VMkernel anlegen:

vMotionA

Wir nennen unseren neuen VMkernel vMotion_A und setzen den Haken für die vMotion Funktionalität. Wichtig auch: Vergeben Sie im nächsten Schritt eine IP – Adresse aus dem einem anderen Subnetz als dem Verwaltungsnetzwerk. Dies ist extrem wichtig! Tun Sie das nicht, werden die Daten immer über den ersten VMkernel (Verwaltungsnetzwerk) gesendet und Ihr neu angelegter vMotion VMkernel ist nutzlos. Sind wir mit dem Anlegen des ersten VMkernel fertig, gehen wir noch einmal in dessen Eigenschaften:

vMotionA - NIC

Unter NIC-Gruppierung nehmen wir folgende Einstellungen vor:

  • Wir setzen eine NIC (vmnic4) als aktiven Adapter und die andere NIC (vmnic5) als standby Adapter.
  • Switch-Failover-Reihenfolge außer Kraft setzten. Wie wir gleich sehen, wollen wir nicht, dass beide NIC’s als aktiv gesetzt werden, dies ist beim vSwitch allerdings der Fall.
  • Lastenausgleich: Hier macht nur anhand der ursprünglichen ID des virtuellen Ports routen Sinn, da wir eine Active-Passive Beziehung zwischen den beiden NIC’s haben.
  • Failback: Ja. Dass nach einem Ausfall einer der beiden NIC’s die hier eingestellte Reihenfolge der NIC’s wiederhergestellt wird.

Anschließend legen wir innerhalb des gleichen vSwitches einen zweiten VMkernel, vMotion_B, an. Dieser bekommt eine eigene IP – Adresse aus Ihrem vMotion Subnetz und erhält ansonsten die gleichen Einstellungen wie vMotion_A. Nur eine Sache unterscheidet sich grundlegend von vMotion_A: Hier setzen wir die in vMotion_A als aktiv gesetzte NIC (vmnic4) als standby Adapter und die in vMotion_A als standby gesetzte NIC (vmnic5) als aktiven Adapter. Wir drehen die Reihenfolge der NIC’s also herum. So sieht nun unser fertiger vSwitch samt der beiden vMotion VMkernel aus:

vMotionFertig

Mit dem gleichen Vorgehen, konfigurieren wir nun auch noch unsere anderen ESXi Hosts. Bitte beachten Sie, dass die vMotion Konfiguration immer konsistent sein sollte, da sonst sehr unschöne Fehler auftreten können. Weiterhin zu beachten ist, dass durch sich durch diese Konfiguration nicht die Maximalwerte des vMotion Features erhöhen:

  • Maximal 8 simultane vMotion Vorgänge bei einer 10 Gbit/s Verbindung
  • Maximal 4 simultane vMotion Vorgänge bei einer 1 Gbit/s Verbindung
  • Maximal 4 x 10 Gbit/s Uplinks
  • Maximal 16 x 1 Gbit/s Uplinks

Perfomance:

Für meine Perfomancetests migrierte ich folgende virtuelle Maschine zwischen meinen beiden Lab – Hosts:

VM

Mittels der VMkernel Logs ist es möglich die Dauer und den Durchsatz des vMotion Vorgangs zu betrachten:

Durchsatz

Wie wir hier bereits schön sehen können, nutzt vMotion selbst bei der Migration einer einzelnen Maschine beide VMkernel. Die von mir gemessenen Durchsatzraten habe ich grafisch dargestellt:

Throughput

Beim Test dieser einzelnen Maschine konnte ich eine Perfomanceverbesserung von ca. 20 Prozent feststellen. Migrierte ich mehrere virtuelle Maschinen gleichzeitig, stieg dieser Wert sogar auf 30 – 35 %.

Jumbo – Frames

Durch das Setzen der MTU Size auf 9000 konnte ich noch einmal deutlich gesteigerte (ca. 10 – 15% ) Durchsatzraten beim vMotion Vorgang feststellen.

Fazit

Durch Multiple-NIC vMotion können wir vMotion Vorgänge deutlich beschleunigen. Dies fällt bei der Migration einer einzelnen  virtuellen Maschine vielleicht nicht unbedingt ins Auge, beim Leerräumen eines Hosts aus Wartungsgründen, kann uns dies aber doch sehr viel Zeit sparen.

Restart Priority Of Clustered VMs

Immer wieder bekomme ich die Frage gestellt, ob es denn Sinn mache, bestimmte virtuellen Maschinen mit Neustartprioritäten zu versehen, um sicherzugehen, dass im Falle eines Hostausfalls “Business-Critical-Apps” in der richtigen Reihenfolge starten. JA, es macht durchaus Sinn diese Einstellungen vorzunehmen. Als Beispiel meine Lab Konfiguration:

Prio

Folgendes habe ich mir bei dieser Konfiguration gedacht:

  • Als Erstes soll der Domänencontroller gestartet werden. Da auf diesem auch die DNS und DHCP Dienste laufen, sollte er zuerst starten. Auch der SQL Server besitzt die gleiche Neustartpriorität. Da sich auf diesem Server die SQL Datenbank meines vCenter Servers befindet, möchte ich, dass diese beim Start des vCenters verfügbar ist.
  • Mein virtueller vCenter Server wurde mit der nächst niedrigeren Priorität ausgestattet. Er sollte erst dann starten, wenn DNS und SQL Server verfügbar sind.
  • Alle anderen Server wurden mit der Clustereinstellung versehen. Diese ist auf “Niedrig” gesetzt und somit “unwichtiger” als der mit “Mittel” ausgestattete vCenter Server.

Sicherlich kann man die Clustereinstellungen noch verfeinern. Besonders im Falle von VDI Umgebungen ist ein sauberer Neustart der verschiedenen Dienste wichtig. Als Beispiel nenne ich hier immer den Start des Connectionsservers vor dem Start der virtuellen Desktops. Dies muss nicht zwangsläufig, aber kann durchaus zu unschönen Problemen führen. Diese Einstellungen sind vermutlich jedem bekannt und werden, hoffentlich, auch von den meisten umgesetzt. Eine Frage stellt sich aber: Kann ich sichergehen, dass diese Einstellungen im Falle eines Hostausfalls auch umgesetzt werden? Hierfür gehen wir etwas tiefer in den Zyklus des Neustarts von virtuellen Maschinen. Das folgende Wissen, habe ich mir übrigens durch das Buch “VMware vSphere 5.1 – Clustering Deepdive von Duncan Epping und Frank Dennemann angeeignet. Sie finden dies auch in der About Seite wieder.

Die “interne” Neustartorder eines vSphere Clusters sieht folgendermaßen aus:

  1. Start von Agent virtual machines. Schon einmal davon gehört? Agent Virtual Machines sind VMs, die einen bestimmten Dienst innerhalb der Infrastruktur ausführen. Als gutes Beispiel kann hier immer der vShield Endpoint hergenommen werden.
  2. Start von FT secondary virtual machines. Dies ist eine virtuelle Machine, die als “Standby-Klon” für eine andere Maschine dient.
  3. Start von virtuellen Maschinen, die mit der Neustartpriorität “Hoch” versehen wurden.
  4. Start von virtuellen Maschinen, die mit der Neustartpriorität “Mittel” versehen wurden.
  5. Start von virtuellen Maschinen, die mit der Neustartpriorität “Niedrig” versehen wurden.

Doch was ist, wenn der Neustart einer virtuellen Maschine fehlschlägt? Standardmäßig versucht HA 4 weitere Neustarts der virtuellen Maschine durchzuführen. Zuzüglich dem initialen Versuch die Maschine auf einem anderen Host neuzustarten, versucht HA also insgesamt 5 Mal die Maschine zu starten. Die Zahlen im folgenden Diagramm geben die Dauer in Minuten an, die nach dem initialen Startversuch der VM vergehen:

RetryJPEG

Sollten Sie wollen, dass HA weitere Versuche unternimmt die Maschine zu starten, müssen Sie die gewünschte Anzahl in den Advanced Settings unter das.maxvmrestartcount angeben.

Dies alles soll zu folgender Feststellung führen: HA Neustartprioritäten sind keine Versicherung dafür, dass eine virtueller Maschine mit einer höheren Priorität auch wirklich vor einer niedrigpriorisirteren Maschine startet. Sollte zum Beispiel mein DC Controller in die, im Diagramm beschriebenen, mehrmaligen Neustartversuche gehen müssen, startet HA andere Maschinen trotzdem. Denn stellen wir uns vor, der DC Controller kann wegen einer beschädigten virtuellen Festplatte nicht mehr starten – alle anderen Maschinen würden ausgeschaltet bleiben und das wollen wir doch wohl wirklich nicht!

Centralized configuration tasks with PowerCli

Oftmals kämpfe ich mit dem Problem, mehrere ESXi Hosts konsistent konfigurieren zu müssen. Besonders das Einbinden von NFS Datastores oder das Anlegen von Portgroups wird schnell zu Fließbandarbeit und ist somit immer wieder fehlerträchtig. Doch wie können wir uns hier Zeit sparen? Die erste und vermutlich auch sinnvollste Antwort heißt: Hostprofiles. Leider sind die wenigstens meiner Kunden entsprechend lizenziert und können somit dieses Feature nicht nutzen. Außerdem hatte ich in letzter Zeit doch zu häufig meine Problemchen mit den Hostprofiles – ob das an mir oder dieser Funktion lag, lasse ich mal dahingestellt. Welche anderen Möglichkeiten habe ich nun, Konfigurationsaufgaben möglichst zentral durchzuführen? Meine Antwort: Die PowerCLI! Lange traute ich mich nicht an dieses Thema heran, als ich aber vor der Aufgabe stand, an 6 ESXi Hosts jeweils 4 NFS Datastores einzubinden, fing ich an zu skripten. In den folgenden Passagen finden Sie die verschiedensten Skripte, zu den verschiedensten Anwendungszwecken. Die Skripte wurden von mir immer im Dialogformat aufgebaut. Dies vereinfacht besonders das Handling für Benutzer ohne Erfahrung im Handling mit PowerCLI oder PowerShell. Für diese Benutzer auch folgende Info: Nach dem Download (www.vmware.com) und der anschließenden Installation der vSphere PowerCLI (Bitte auf die passende Version zum vCenter achten), diese einfach durch einen Doppelklick starten. Die Skripte im Editor der Wahl via Copy and Paste in eine *.ps1 Datei abspeichern und via Drag and Drop in das PowerCli Fenster ziehen. Eine Downloadsektion der Skripte wird noch folgen.

Hinzufügen einer Portgruppe

Um alle Hosts eines Clusters mit einer neuen Portgruppe auszustatten, kann folgendes Skript verwenden werden. Bitte beachten Sie, dass bereits ein vSwitch vorhanden sein muss.

$vCenterName = Read-Host -Prompt "Mit welchem vCenter Server wollen Sie sich verbinden?"
$vCenter = Connect-VIServer $vCenterName
 
$ClusterName = Read-Host -Prompt "In welchem Cluster wollen Sie die Einstellung vornehmen?"
$Cluster = Get-Cluster $ClusterName
 
$vSwitchName = Read-Host -Prompt "Welchem vSwitch (z.B. vSwitch0) soll die Portgruppe hinzugefügt werden?"
$PGName = Read-Host -Prompt "Geben Sie den Namen der Portgruppe an (z.B. VM DMZ):"
$VLAN = Read-Host -Prompt "Geben Sie eine VLAN ID (0-4095) an. Soll kein VLAN getagged werden, bitte die ID 0 angeben:"
 
$TargetHosts = $Cluster | Get-VMHost
    Foreach ($VMHost in $TargetHosts)
    {
    $VMHost | Get-VirtualSwitch -Name $vSwitchName | New-VirtualPortGroup -Name $PGName -VLanId $VLAN
    }
 
Disconnect-VIServer $vCenter -Confirm:$false

 

Hinzufügen eines NFS – Datastores

Mit Hilfe des folgenden Skripts ist es möglich, einen NFS Datastore auf allen Hosts eines Clusters einzubinden. Hierfür brauchen wir nur die, hoffentlich bekannten, Parameter (IP-Adresse/Hostname des NFS Hosts, den Exportpfad und den Anzeigenamen). Sollte der Datastore bereits auf einem oder mehreren Hosts gemountet sein, stellt dies kein Problem dar. Er übergeht diesen Host einfach und wirft eine weniger hübsche Meldung innerhalb der PowerCLI aus.

$vCenterName = Read-Host -Prompt "Mit welchem vCenter Server wollen Sie sich verbinden?"
$vCenter = Connect-VIServer $vCenterName
 
$ClusterName = Read-Host -Prompt "In welchem Cluster wollen Sie die Einstellung vornehmen?"
$Cluster = Get-Cluster $ClusterName
 
$NASHost = Read-Host -Prompt "Wie lautet die IP-Adresse Ihres NFS Servers?"
$PathTo = Read-Host -Prompt "Geben Sie den Pfad (z.B. /vol/Test) zum Volume an:"
$DSName = Read-Host -Prompt "Geben Sie den Anzeigenamen des Datastores an:"
 
$TargetHosts = $Cluster | Get-VMHost
    Foreach ($VMHost in $TargetHosts)
    {
    $VMHost | New-Datastore -Nfs -Name $DSName -Path $PathTo -NfsHost $NASHost
    }
 
Disconnect-VIServer $vCenter -Confirm:$false

 

Syslogserver

Der allseits beliebte und für die externe Aufbewahrung von Syslogs auch wichtige Syslogserver, muss in den Advanced Settings jedes ESXi Hosts angegeben werden. Dies können wir uns durch das nächste, denkbar einfache, PowerCLI Skript vereinfachen:

$vCenterName = Read-Host -Prompt "Mit welchem vCenter Server wollen Sie sich verbinden?"
$vCenter = Connect-VIServer $vCenterName
 
$ClusterName = Read-Host -Prompt "In welchem Cluster wollen Sie die Einstellung vornehmen?"
$Cluster = Get-Cluster $ClusterName
 
$Sysloghost = Read-Host -Prompt "Wie lautet die IP-Adresse des Syslogservers?"
$syslogport = Read-Host -Prompt "Welcher Port soll genutzt werden? 514/80?"
 
$TargetHosts = $Cluster | Get-VMHost
    Foreach ($VMHost in $TargetHosts)
    {
    $VMHost | Set-VMHostSysLogServer -SysLogServer $Sysloghost -SysLogServerPort $syslogport
    }
 
Disconnect-VIServer $vCenter -Confirm:$false

 

NTP Konfiguration

Eines der wichtigsten Themen bei der Einrichtung eines neuen ESXi Hosts, ist die Konfiguration des NTP – Services. Mit dem folgenden Skript kann man für alle, dem Cluster zugehörigen, ESXi Hosts den NTP Server eintragen und anschließend , auf Nachfrage der PowerCLI, den NTP Client Dienst neustarten. Sollte bereits ein anderer NTP Server konfiguriert worden sein, wird dieser nicht ersetzt. Es erscheint außerdem wiederum eine “unauffälliger” roter Schriftzug.

ntp.ps1   
$vCenterName = Read-Host -Prompt "Mit welchem vCenter Server wollen Sie sich verbinden?"
$vCenter = Connect-VIServer $vCenterName
 
$ClusterName = Read-Host -Prompt "In welchem Cluster wollen Sie die Einstellung vornehmen?"
$Cluster = Get-Cluster $ClusterName
 
$NTPHost = Read-Host -Prompt "Wie lautet die IP-Adresse/Hostname des NTP Servers (z.B. 0.de.pool.ntp.org)?"
 
$TargetHosts = $Cluster | Get-VMHost
    Foreach ($VMHost in $TargetHosts)
    {
    $VMHost | Add-VmHostNtpServer -NtpServer $NTPHost
    }
    Foreach ($VMHost in $TargetHosts)
    {
    $VMHost | Get-VMHostService | Where-Object{$_.key -eq 'ntpd'} | Restart-VMHostService
    }
 
Disconnect-VIServer $vCenter -Confirm:$false

 

Da mich dieser Artikel nun schon den kompletten Abend und meine kompletten Nerven gekostet hat, schließe ich das Ganze für’s Erste ab. Sobald mir neuen Ideen kommen, werde ich die Skripte anlegen und hier posten. Ein weiteres großes Projekt ist derzeit auch in Arbeit: Aus den einzelnen vorhandenen und später erscheinenden Skripten, werde ich ein “Monsterskript” formen, mit dem die Konfiguration der grundkonfigurierten (Mgmt IP, Einbindung in das Cluster) ESXi Hosts zentral durchgeführt werden kann. Dies muss allerdings noch getestet werden – ein Update folgt!

NVIDIA and VMware – EOL for workstations?

Durch den großen Launch von Horizon 6 ist ein Thema in den letzten beiden Wochen leider etwas untergegangen: VMware und NVIDIA kündigten durch eine engere Zusammenarbeit die Integration des vGPU Features für den hauseigenen Hypervisor ESXi an. Bevor ich das Thema vGPU technisch näher beleuchte, möchte ich im Zeitstrahl der Desktopvirtualisierung früher beginnen:

So schön die Desktopvirtualsierung in Dingen wie Administration, Ausfallsicherheit usw. war, man stieß sehr oft an eine bestimmte Grenze und zwar die Grafikleistung. Wenn eine Maschine mehr RAM oder CPU Leistung benötigte, fuhr man sie eben herunter und stattete sie mit mehr Ressourcen aus. Geht es um Grafikleistung, ist das nicht so einfach. Zwar bringt VMware einen onboard “3D Grafikrenderer” mit, aber alleine die Tatsache, dass ich dies in Anführungszeichen setze, sollte jedem klarmachen, dass man hier mit einer Nagelpfeile versucht, einen Felsen zu zerschneiden. Damit meine ich: Man kann nun mal keine GPU durch ein Rendering innerhalb der CPU ersetzen. Sicherlich bringt dieses Feature gewisse Vorteile, wenn man z.B. das Windows Aero Feature ohne zusätzliche Hardware nutzen möchte, aber alleine bei der Darstellung einer Windows 8 Metro Oberfläche stößt man sehr schnell an seine Grenzen. Irgendwann dachte man sich: Wieso sollen Grafikkarten eigentlich immer nur in Clients und nicht auch in Servern laufen? Dies war (beachten Sie bitte, dass ich immer nur die Zeitschiene des Produktes VMware View betrachte) die Geburtsstunde von SVGA.

SVGA:

SVGAJPEG

 

Durch SVGA haben wir die Möglichkeit den vRAM (Video RAM) einer Grafikkarte mit mehreren virtuellen Maschinen zu teilen. Dieser Modus hat viele Nachteile, aber meiner Meinung nach auch einen sehr großen Vorteil:

  • Der erste große Nachteil dieser Variante ist sicherlich die fehlende Perfomance. Durch die reine Zuteilung von vRAM erreicht man einfach nicht die nötige Grafikleistung, die nötigen FPS (Frames per second), um besonders 3D Objekte darzustellen. Allerdings reicht dieser Variante, im Gegensatz zum Renderer, aus um z.B. die aufwendige Metro Oberfläche eines Windows 8/8.1 Systems sauber darzustellen. Durch diese Methode habe ich des Weiteren auch schon Projekte, die mit aufwendigen Photoshop Workloads zusammenhingen, realisiert.
  • Der zweite und für mich noch wichtigere Nachteil ist: Dadurch, dass der Grafiktreiber im Hypervisor installiert ist und die Maschine als Grafikkarte weiterhin, die durch die VMware Tools installierten, die virtuelle VMware Grafikkarte sieht, fallen Features wie DirectX oder OpenGL komplett weg. Viele Programme, besonders im CAD Bereich, benötigen allerdings zwingend diese Features und starten ohne diese nicht einmal.
  • Einen großen Vorteil sehe ich allerdings in dieser Variante: Im Shared Modus sind weiterhin Features wie vMotion nutzbar. Zieht unser virtueller Desktop von einem Host mit Grafikkarte auf einen Host ohne Grafikkarte um, hat er zwar nicht mehr die gesharten vRAM Ressourcen zur Verfügung und muss damit auch mit weniger Grafikleistung auskommen, allerdings läuft die virtuelle Maschine ohne Downtime weiter. Wieso das ein Vorteil ist, beleuchte im nächsten Absatz.

DVGA:

DVGAJPEG

 

Seit VMware Horizon View 5.3 wird nun auch endlich das Feature DVGA unterstützt. Hierbei reichen wir eine physische GPU, einer im Server eingebauten Grafikkarte, einer virtuellen Maschine via PCI – Passtrough zu. Wir haben hier also eine 1:1 Verbindung zwischen GPU und virtueller Maschine. Auch hier wieder die Vor- und Nachteile:

  • Diese Variante ist sicherlich die Variante, die uns am wenigstens Kopfzerbrechen in Sachen Perfomance machen wird. Durch die direkte Durchreichung (Der Hypervisor wird einfach übergangen) der GPU, steht der virtuellen Maschine nun die volle Leistung einer physischen Grafikkarte zur Verfügung. Als kleines Beispiel: Die Perfomance einer GPU der NVIDA GRID K1 ist vergleichbar mit der Leistung einer Entry Kepler based GPU (z.B. der Quadro K4000). Diese sind oftmals in 3D CAD Workstations verbaut, die hauptsächlich zum Betrachten von CAD – Zeichnung gedacht sind. Sollen höchstaufwendige und große Zeichnungen geöffnet und bearbeitet werden, sollte auf eine NVIDIA GRID K2 zurückgegriffen werden. Diese besitzt zwar nur 2 GPU’s, diese sind allerdings jeweils mit den aktuellste High End Grafikkarten von NVIDIA vergleichbar.
  • Durch die direkte Durchreichung der Karte als PCI – Device an die virtuelle Maschine, erledigen sich die VMware SVGA Treiber. Diese werden nun ersetzt durch die nativen Windows Treiber von NVIDIA. Durch das Vorhandensein dieser Treiber ist es nun natürlich auch möglich DirectX, OpenGL usw. zu nutzen.
  • Der Nachteil an dieser Sache: Wir können nur so viele User bzw. Desktops ausstatten, wie physische GPU’s auf der Grafikkarte vorhanden sind. Haben wir also eine NVIDIA GRID K1 verbaut, können wir maximal 4 User bzw. Desktops mit der benötigten Grafikleistung versorgen. Des Weiteren ist durch die starre PCI – Passtrough Zuweisung die Möglichkeit eines Umzuges auf einen anderen Host im Live Betrieb nicht gegeben. Selbst im Zuge einer Cold – Migration, muss im anderen Host die gleiche Grafikkarte verbaut sein und die PCI – Passtrough Zuweisung neu vorgenommen werden. Dies ist natürlich nicht im Sinne einer Desktopvirtualisierung, aber ich bin sicher, dass hier in den nächsten Jahren Abhilfe geschaffen wird.

vGPU:

vGPUJPEG

Wie bereits in der Einleitung erwähnt: VMware und NVIDIA gaben bekannt, dass das vGPU Feature bald unter VMware vSphere verfügbar sein wird. Bisher ist vGPU dem Hypervisor aus dem Hause Citrix, XenServer, exklusiv vorbehalten. Wieso erst so spät unter ESXi? Ganz einfach: Citrix machte es sich mit dem XenServer denkbar einfach und übergab diesen wieder zurück an die Community. Dadurch hatte NVIDIA nun die Möglichkeit, ganz einfach ihren Code in den Hypervisor zu bringen, um die virtuellen GPU’s sehen und verwalten zu können. VMware hat es mit dem ESXi hier natürlich nicht so einfach. Der ESXi ist und bleibt das Zugpferd und kann nicht einfach als OpenSource Produkt veröffentlicht werden. Auch einem einzelnen Hersteller, in diesem Falle NVIDIA, will man natürlich nicht ohne Weiteres den heiligen Code öffnen. Deswegen kam die Ankündigung, vGPU bis Ende 2014/Anfang 2015 unter vSphere verfügbar zu machen, umso überraschender für mich. Nun aber zum Technischen. Was ist vGPU von NVIDIA überhaupt? Durch vGPU wird es möglich sein, dass sich mehrere Benutzer eine physische GPU teilen, ohne auf die nativen Treiber im Betriebssystem und damit auf DirectX und OpenGL verzichten zu müssen. Der vGPU Manager weist jedem Anwender genau soviel Grafikspeicher zu, wie er benötigt. Jedes virtuelle System verfügt über einen diskreten Grafikspeicher, genau wie ein Desktop-PC, so dass jeder Anwender über die nötigen Ressourcen für seine Anwendungen verfügt. Über den vGPU Manager können wir nun bis zu 8 Anwender gleichzeitig eine GPU benutzen lassen. Die Zuteilung der physischen Ressourcen erfolgt dynamisch, denn sind wir mal ehrlich: Wann drehen genau 8 CAD Benutzer gleichzeitig an ihrer Zeichnung? In den meisten Fällen holen gerade 2 Benutzer einen neuen Kaffee, einer beantwortet eine Email und der andere ist am Telefon. Die restlichen 4 Benutzer teilen sich somit also einen Großteil der physischen Ressourcen. Kommen die Kollegen vom Kaffeholen zurück, werden die Ressourcenzuweisungen wieder angepasst. Durch die vGPU Technologie können wir eine viel höhere Packungsdichte auf den GRID Karten erzielen und damit natürlich auch die Kosten rapide senken. Wie hier der prozentuale Anteil sein wird, kann ich leider erst sagen, wenn ich die ersten Beta Tests durchgeführt habe.  Auch die Vor- und Nachteile werde ich erst beleuchten, wenn es hierzu die ersten seriösen Tests meinerseits gab.

Um ein kleines Fazit zu ziehen: Es ist unglaublich, was sich in den letzten Jahren im Bereich VDI getan hat. Vor Jahren konnte man sich kaum vorstellen einen reinen Office – Arbeitsplatz zu virtualisieren. Mittlerweile sind selbst, die von Administratoren so oft gehassten, Workstations angreifbar. Ich freue mich schon auf vGPU unter VMware vSphere und VMware View – Euch halte ich natürlich jederzeit auf dem Laufenden!

 

VMware Horizon 6 – Part 2

Wie versprochen, hier nun der zweite Teil zu den Vorstellungen im Bereich EUC seitens VMware. Im ersten Teil beleuchtete ich die Neuerungen im Bereich der Desktopvirtualisierung unter VMware View. Und da ist auch schon der erste Fehler meinerseits: Das Produkt VMware View wird in den Preistabellen so nicht mehr auftauchen. Die EUC Produkte VMware Horizon View, Horizon Mirage und Horizon Workspace, die bisher in einer Horizon Suite geordert werden konnten, werden nun zu einem eigenständigen Produkt, VMware Horizon 6, zusammengeführt. Innerhalb dieses Produktes wird es drei verschiedene Lizenzierungsarten geben:

horizon

Standard: 

Die Variante Standard bildet die derzeitige VMware View Bundle Lizenzierung und beinhaltet VMware View (Connection Server, Composer..), ThinApp und die Infrastrukturkomponente vSphere Desktop und vCenter Desktop. Bitte unbedingt beachten: In dieser Lizenzierungsvariante ist die von mir, in Teil 1 beschriebene, Applikations- und Desktopbereitstellung via RDS nicht inkludiert! In dieser Lizenzierung werden sich alle bisherigen VMware Horizon View Kunden wiederfinden. Im Gegensatz zu den beiden anderen Stufen der Lizenzierung von Horizon 6, gibt es hier wie bisher ausschließlich concurrent Lizenzen.

Advanced:

Die nächst höhere Variante von Horizon 6, die Version Advanced, schätze ich als mit Abstand attraktivste ein. Neben den bisherigen VMware View Komponenten, kann man hier die neuen RDS – Features nutzen. Außerdem ist hier das Image Management für physische und virtuelle Maschinen, Mirage, inkludiert. Die für mich größte Überraschung innerhalb dieser Edition ist und bleibt allerdings, dass VMware Virtual SAN (vSAN) mit inbegriffen ist. Ich bin nach einigen Labsessions ein großer Fan von Virtual SAN, sah das Thema Lizenzierungskosten aber sehr kritisch. Durch die mitgelieferten Lizenzen in Verbindung mit der eher Storagesparenden Möglichkeit von Puplished Desktops, könnte es nun möglich werden, vergleichsweise günstige VDI Umgebungen zu planen und umzusetzen. In einer meiner nächsten Blogposts werde ich versuchen eine Kalkulation zwischen der herkömmlichen Lösung und einer Umgebung, die diese neuen Features nutzt, aufzustellen.

Enterprise:

Die Enterprise Variante bietet neben den zuvor genannten Features der anderen Lizenzierungsstufen vCenter Operations Manager for View. Hiermit ist eine End to End Analyse der VDI Infrastruktur möglich. Wer also wissen möchte, auf welchem Wegstück zwischen virtuellen Desktop und Storage ein Problem auftreten könnte, sollte sich mit dieser Variante beschäftigen. Um allerdings ehrlich zu sein, habe ich mich wegen der einerseits viel zu hohen Preispolitik seitens VMware (ca. 100 Euro pro virtuellen Desktop) und anderseits wegen der mir bisher fehlenden Notwendigkeit, nicht mit dem Thema vCenter Operations Manager for View beschäftigt. Alle von mir geplanten und implementierten VDI Umgebungen laufen bis heute problemlos. In Zukunft wird dieses Thema auf Grund der neuen Lizenzierung auch ein Thema werden – ja Blogposts werden folgen! Die andere Differenzierung, die VMware zur Variante Advanced schafft, ist die Sparte Cloud Automation. Es wird ein besonderes Orchestrator Plugin für den Bereich Desktop geben. Hiermit sollen Tasks wie Rocomposes, Pool Erstellung usw. automatisiert geschehen. Dieses Feature muss ich allerdings erst live betrachten, um eine seriöse Aussage darüber treffen zu können.

Jetzt bleibt natürlich noch eine Frage offen: Was mache ich mit meinen vorhandenen View/Mirage/Horizon Suite Lizenzen? Darauf eine kurze Antwort: Es gibt verschiedene Upgradepfade, die Sie sich am besten unter: http://www.vmware.com/files/pdf/products/horizon-view/VMware-Horizon-View-Pricing-Licensing-FAQ.pdf anschauen oder beim Debitor Ihres Vertrauens nachfragen. Mir wird leider immer ganz schwindelig, wenn ich Preistabellen und Produktnummern sehe.

Zum Abschluss noch wie versprochen mein Senf dazu:

Die versprochene Neuerfindung des Desktop ist, wie von mir erwartet, zwar ausgeblieben, aber es ist ein riesen Schritt in die richtige Richtung. Sie können im Bereich RDS sicherlich noch nicht mit Citrix XenApp mithalten, aber das erwartet derzeit sicherlich auch noch niemand. Was mir bei dem Produkt Horizon 6 besonders gut gefällt: VMware sieht den Kunden als Ganzes! So ziemlich jedes, einigermaßen an Innovation interessiertes, Unternehmen denkt derzeit über eine Desktopvirtualsierung nach. Aber alle diese Unternehmen stehen immer noch vor dem Problem, was sie mit Ihren Notebookusern machen, die durch die tolle und flächendeckende (ein Witz muss nach 3 Stunden Schreiberei dann doch mal raus) Breitbandanbindung im deutschen Raum oft ohne Anbindung dastehen. VDI ist und bleibt die Zukunft, aber sie lebt einfach von ihrem Connect. In einer kommenden Blogserie über VMware Mirage werde ich die tollen Möglichkeiten, die dieses Produkt bietet, genauer beleuchten. Durch Horizon 6 (betrachten wir erstmal nur die Variante Advanced) haben Kunden nun die Möglichkeit Ihre gesamte Client Infrastuktur, inklusive Lizenzierung von vSphere und vSAN, abzudecken. Diese Preisgestaltung wird sicherlich so manches, noch fehlendes, Feature egalisieren. Ich bin nach einem Jahr Frustration über VMware’s EUC Strategie endlich wieder frohen Mutes, dass es vorangeht, dass VMware wieder dahinkommt, wo sie hingehören – an die Spitze!

 

 

 

 

VMware Horizon 6 – Part 1

Seit mehreren Wochen streute VMware immer wieder folgenden Satz: “Something big is on the horizon” durch soziale Medien. Da selbst ich als Techniker mit Partnerstatus keine näheren Infos zu diesem Thema erhielt, musste ich mich fast genauso lang wie jeder andere mit Mutmaßungen befriedigen. Am 9. April war es dann so weit: Im Rahmen einer Session des VMware Partner Boot Camps erfuhr ich mehr über die Neuerungen im EUC Bereich:

Terminalservices:                                                                                                                       Die sicherlich größte und für mich wichtigste Neuerung ist die Möglichkeit Applikationen und Desktops via Remote Desktop Services bereitzustellen. Leider scheiterten im vergangenen Jahr viele Projektverhandlungen an zwei Themen:

  • VDA Lizenzierung: Um ein Windows Betriebssystem innerhalb einer VDI Umgebung durch nicht Windows – Clients (Zero Clients, Tablets usw.) zugänglich zu machen, bedarf es einer besonderen Windows 7 Lizenz auf Mietbasis. Diese schlugen mit ca. 100 Euro im Jahr auf. Für eine Umgebung mit 200 Desktops wurden also mindestens 20.000 Euro im Jahr für Windows 7 Lizenzen fällig. Durch den Umzug von entweder einem Teil oder sogar allen Benutzern auf einen Shared – Desktop, fallen nur noch Lizenzen für das Serverbetriebssystem, das die meisten Kunden so oder so durch eine Datacenter Lizenz abgedeckt haben, und für die Remote – Desktop Zugriffslizenzen (RDS CAL) an. Diese können außerdem entweder pro User oder auch pro Zugriffsgerät lizenziert werden. Da diese Lizenzen Kauflizenzen sind, sparen sich Kunden ca. nach einem Jahr die ersten Lizenzkosten.
  • Storageperfomance: Durch die Tatsache, dass jeder Benutzer unter VMware View bisher seinen eigenen Desktop besaß, waren die Anforderungen an das Storage vergleichsweise hoch. Selbst in einer homogenen Büroumgebung mit Einsatz von Officeanwendungen , ERP etc. konnte man mit ca. 15 IOPS pro Desktop rechnen. Bei unseren 200 Usern aus dem Beispiel zuvor, wären das ca. 3000 IOPS. Hierbei ist natürlich noch nicht die Möglichkeit eines Bootstorms in Zeit zwischen 07:00 Uhr und 08:30 Uhr eingerechnet.

Durch dieses neue Feature wird es nun auch möglich sein, einzelne Anwendungen a la XenApp auf Endgeräte aller Art (iOS, Android…) bereitzustellen. Hier hatten wir bisher zwar die Möglichkeit den kompletten Desktop freizugeben, dies war vielen Kunden allerdings doch zu mühselig.  Wieso denn auch den Desktop öffnen, wenn ich mein ERP System direkt aufrufen kann?

Doch es ist noch nicht alles gold, was glänzt:

  • Auch auf Nachfrage konnte man mir noch nicht beantworten, wie das Userprofilmanagement bei einem Shared – Desktop ablaufen wird. Eventuell kommt hier das Feature View Persona zum Einsatz.
  • Die Bereitstellung der Terminalserver erfolgt händisch. Das heißt: Installieren eines Windows Servers (2008 R2, 2012, 2012R2), Installation der Remotedesktopdienste, Installation des View Agents. Anschließend taucht der RDP – Server in View Administrator auf. Wenn ich das ganze Failover – Sicher gestalten möchte, muss ich das Gleiche noch einmal mit einem zweiten Server ausführen. Das bedeutet auch: Ich muss die beiden Server händisch konsistent halten. Installiere ich die freizugebende Anwendung A (z.B. Office) auf RDP Server 1, sollte ich diese auch auf RDP Server 2 installieren, dass im Falle eines Ausfalls von Server 1, Server 2 übernehmen kann. Hier sehe ich bisher den riesen Vorteil von Citrix XenApp: Ein zentrales Imagemenagement via Provisioning oder Machine Creation Services. Ich hoffe und glaube, dass in naher Zukunft die View Composer Integration für Terminalserver erscheinen wird. Solange werde ich mir mit anderen Hilfsmitteln (VMware Horizon Mirage, ThinApp Verteilung via GPO etc.) behilflich sein müssen.
  • Man wird nicht jeden Benutzer Terminalserverfähig machen können. Die Option des Shared Desktop eignet sich besonders für homogene Umgebungen, in denen viele Benutzer den exakt gleichen Desktop brauchen. Als gutes Beispiel sind hier immer Callcenter zu sehen. Haben wir also sehr viele verschiedene Desktops, wird die Anpassung sehr kompliziert. Hier kann man allerdings keine pauschale Aussage treffen und muss immer den bestimmten Anwendungsfall sehen. Ein weiteres Problem könnten hier auch Anwendungen sein, die nicht auf Serverbetriebssystemen installiert werden können und/oder nicht auf diesen offiziell freigegeben sind. Ein gutes Beispiel sind hier mehrere Adobe Produkte. Hierbei hat VMware allerdings noch ein Ass im Ärmel: Ihre Paketierungssoftware ThinApp. Hiermit habe die Möglichkeit unter Windows 7 zu paketieren und das fertige ThinApp Paket auf dem RDP Server auszuführen.
  • Auch bei der Variante des Shared – Desktop bedarf es einer genauen Analyse und einer noch genaueren Planung. Wir können (vermutlich) nicht einfach alle User auf einen Terminalserver schmeißen und alles ist gut. VMware gab auf Nachfrage meinerseits die Information heraus, dass die Grenze bei 150 Sessions (Zugriff auf eine einzelne Anwendung oder einen ganzen Desktop) liegt. Dies kann wohl durch in View Administrator angepasst werden, hat sich bei den Tests aber wohl als Grenze herauskristallisiert.

Da ich auf dieses Feature seit meinem Einstieg in den EUC Bereich gewartet habe, freue ich mich wie ein Schneekönig auf die erste Installation und den ersten Aufruf einer via RDS bereitgestellten Applikation auf iPad und co. Sicherlich ist diese Funktion nicht so ausgereift wie die Lösung aus dem Hause Citrix, aber es ist endlich wieder ein Schritt in die richtige Richtung und das war das, was ich in den letzten Monaten vermisst habe, eine Richtung, in die VMware in Sachen EUC gehen möchte.

In Teil 2 erfahrt ihr mehr über das Produkt Horizon 6 und auch ich werde natürlich wieder meinen persönlichen Senf dazugeben.