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!