Es gibt immer wieder interessante Konstellationen und Anforderungen in der IT. Eine Sache die mich dabei schon länger umhertreibt ist die Thematik, dass die VHD Datei einer VM, die über ein VM Template mittels VMM in einer Private Cloud bereitgestellt wird, den Namen der VHD Datei aus der VMM Library behält. Für eine einfache Zuordnung der VHD Datei zur VM verwende ich die Logik VHD Dateiname gleich Name der VM. Während einem VM Deployment über ein Template kann man den VHD Dateinamen nur anpassen, wenn man die VM auf einen speziellen Hyper-V Host bereitstellt, aber nicht wenn man eine Private Cloud auswählt.
Da ich mich in letzter Zeit mit dem Orchestrator auseinandergesetzt hatte, stand die Entscheidung schnell fest dies mit einem Runbook zu realisieren. Das Runbook deckt dabei nur das VHD Renaming der Bootplatte ab, berücksichtigt dabei aber, ob die VM zum Beispiel mittels Hyper-V Replica repliziert wird.
Mein Szenario, welches ich mit dem Runbook abdecke, ist folgendes. Das Runbook läuft täglich Nachts um 02:00 Uhr. Die VMs die in die Verarbeitung einbezogen werden, sind am selben Tag mittels VM Template bereitgestellt und mit einem Tag versehen worden, so dass das Löschen und Erstellen der Replizierungsbeziehung bei Hyper-V Replica keinen relevanten Nachteil nach sich zieht, wie es zum Beispiel bei VMs wäre die schon länger mit Hyper-V Replica repliziert werden.
Nun aber zu dem Runbook bzw. den Runbooks, da die Lösung aus zwei Runbooks VHDRename und VHDRename_Sub besteht, um das wohlbekannte Double Hop Issue beim Orchestrator zu umgehen. So muss man nicht die CredSSP Beziehungen zwischen dem Orchestrator und den anderen Servern, die im Runbook angesprochen werden, konfigurieren.
Wie man auf den ersten Blick sehen kann, werden laufende und heruntergefahrene VMs berücksichtigt sowie ob Hyper-V Replica aktiviert oder deaktiviert ist.
Die erste Activity im VHDRename Runbook ist selbsterklärend. Hier wird einfach über eine Monitoring Activity gewartet bis der Fall eintritt, dass es 02:00 Uhr ist und das Runbook dadurch getriggert wird.
Die nächste Activity Get VM ermittelt sämtliche VMs, die durch den VMM verwaltet werden, die in der Custom Property 1 vhdrename stehen haben und bei denen die Custom Property 2 nicht vhdrenamed entspricht. Hier können natürlich auch andere Werte eingetragen werden. Ich hinterlege bei meinen VM Templates direkt als Custom Property 1 vhdrename, so dass ich diese VMs für den Prozess sehr leicht identifizieren kann.
Sollte die Activity keine VMs zurückliefern, so wird mittels des Smart Links If VM ID is empty => Stop Processing das Runbook an dieser Stelle beendet. Ansonsten werden die VMs an die nächste Activity Shut Down VM übergeben.
Denn für das Umbenennen der VHD Datei muss die VM heruntergefahren sein. Mittels der Smart Links VM was running und VM was stopped wird einfach zwischen bereits heruntergefahrenen VMs und noch laufenden VMs unterschieden. Denn bereits heruntergefahrene VMs werfen bei der Activity Shut Down VMs Fehler.
Die nächsten Konfigurationschritte werden nur anhand der Activities Get Disk, IDE Filtering, Invoke VHDRename_Sub, VM Refresh und Update VM beschrieben, da die Activites Get Disk Stopped, etc. identisch sind und sich sonst auf die vorhergehende Activity beziehen.
Nach der Filterung der Shut Down VM Activity, werden in der nächsten Activity Get Disk die VHD Informationen abgerufen.
Die zurückgegebenen Werte verarbeitet dann direkt die Activity IDE Filtering.
Da meine VM Templates nur aus der Bootplatte am IDE Port bestehen und zusätzliche VHDs per SCSI angehangen werden, finden weitere VHDs an einem IDE Port sowie die per SCSI angebundenen VHDs keine Beachtung.
Der Smart Link Only IDE stellt sicher, dass nur die IDE VHD an die Activity Invoke VHDRename_Sub weitergereicht wird.
Das Runbook VHDRename_Sub benötigt die folgenden Informationen aus seinem Parent Runbook Bus, VHDName, BusType, VHDLocation, VMName und HostName. Eine weitere aber wichtige Kleinigkeit muss hier ebenfalls erwähnt werden. Zur Umbenennung von VHDs muss man, zumindestens bei VHDs auf einem CSV, lokaler Administrator auf dem Hyper-V Host sein. Daher rufe ich das Runbook VHDRename_Sub mit dem Domain Service Account des VMM auf, da dieser automatisch bei Hinzufügen der Hyper-V Hosts zum VMM in die Gruppe der lokalen Administratoren hinzugefügt wird. Wichtig hierbei ist es, dass der Domain Service Account des VMM der Gruppe OrchestratorSystemGroup auf dem Orchestrator hinzugefügt wird. Ansonsten funktioniert der Aufruf des Runbooks VHDRename_Sub nicht.
Nachdem die Daten übergeben wurden, wird ein PowerShell Skript Names Replica Remove ausgeführt. Dieses stellt fest, ob Hyper-V Replica aktiviert ist und gibt dies in einer Variable zurück. Bevor bei aktivierter Hyper-V Replica diese entfernt wird. Hier erfolgt die Rückgabe des Replica Servers für eine spätere erneute Aktivierung.
$ReplicationEnabled=Invoke-Command -ComputerName {HostName from “Initialize Data”} -ScriptBlock{
if(Get-VMReplication -ComputerName {HostName from “Initialize Data”} -VMName {VMName from “Initialize Data”}){
$ReplicationEnabled=”true”
$ReplicationEnabled
}
}
$ReplicaServer=Invoke-Command -ComputerName {HostName from “Initialize Data”} -ScriptBlock{
if(Get-VMReplication -ComputerName {HostName from “Initialize Data”} -VMName {HostName from “Initialize Data”}){
$ReplicationSettings=Get-VMReplication -ComputerName {HostName from “Initialize Data”} -VMName {VMName from “Initialize Data”}
$ReplicaServer=$ReplicationSettings.ReplicaServer
Remove-VMReplication -VMName $ReplicationSettings.Name
$ReplicaServer
}
}
Beide Variablen $ReplicationEnabled und $ReplicaServer werden über Published Data für die weitere Verarbeitung im Runbook nach Außen zur Verfügung gestellt.
Die Smart Links No Replication und Replication steuern den weiteren Ablauf des Runbooks.
Bei vorheriger aktivierter Hyper-V Replica muss man auf dem Replica Server noch die VM löschen, so dass nach erfolgreicher Umbenennung der VHD diese wieder aktiviert werden kann. Dies wird durch ein PowerShell Skript Replica VM Delete bewerkstelligt.
Invoke-Command -ComputerName {ReplicaServer from “Replica Remove”} -ScriptBlock{
Remove-VM -Name {VMName from “Initialize Data”} -Force
}
Danach folgt das nächste PowerShell Skript VHD Rename für die eigentliche Umbenennung.
Invoke-Command -ComputerName {HostName from “Initialize Data”} -ScriptBlock{
if(“{BusType from “Initialize Data”}” -eq “IDE” -and {Bus from “Initialize Data”} -eq 0){
if(Test-Path -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}.vhdx”){
Rename-Item -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}.vhdx” -NewName {VMName from “Initialize Data”}.vhdx
Set-VMHardDiskDrive -ComputerName {HostName from “Initialize Data”} -VMName {VMName from “Initialize Data”} -ControllerType IDE -Path “{VHDLocationfrom “Initialize Data”}{VMName from “Initialize Data”}.vhdx” -ControllerNumber 0 -ControllerLocation 0 -AllowUnverifiedPaths
}
if(Test-Path -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}.vhd”){
Rename-Item -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}.vhd” -NewName {VMName from “Initialize Data”}.vhd
Set-VMHardDiskDrive -ComputerName {HostName from “Initialize Data”} -VMName {VMName from “Initialize Data”} -ControllerType IDE -Path “{VHDLocationfrom “Initialize Data”}{VMName from “Initialize Data”}.vhd” -ControllerNumber 0 -ControllerLocation 0 -AllowUnverifiedPaths
}
if((Test-Path -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}”) -and (“{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}” -like “*.vhdx”)){
Rename-Item -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}” -NewName {VMName from “Initialize Data”}.vhdx
Set-VMHardDiskDrive -ComputerName {HostName from “Initialize Data”} -VMName {VMName from “Initialize Data”} -ControllerType IDE -Path “{VHDLocationfrom “Initialize Data”}{VMName from “Initialize Data”}.vhdx” -ControllerNumber 0 -ControllerLocation 0 -AllowUnverifiedPaths
}
if((Test-Path -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}”) -and (“{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}” -like “*.vhd”)){
Rename-Item -Path “{VHDLocationfrom “Initialize Data”}{VHDName from “Initialize Data”}” -NewName {VMName from “Initialize Data”}.vhd
Set-VMHardDiskDrive -ComputerName {HostName from “Initialize Data”} -VMName {VMName from “Initialize Data”} -ControllerType IDE -Path “{VHDLocationfrom “Initialize Data”}{VMName from “Initialize Data”}.vhd” -ControllerNumber 0 -ControllerLocation 0 -AllowUnverifiedPaths
}
}
}
Zum Abschluss des Runbooks VHDRename_Sub folgt noch das PowerShell Skript Replica Enable, bevor mit der Return Data Activity zurück in das Parent Runbook gesprungen wird.
Invoke-Command -ComputerName {HostName from “Initialize Data”} -ScriptBlock{
if(“{ReplicationEnabled from “Replica Remove”}” -eq “true”){
Enable-VMReplication -VMName {VMName from “Initialize Data”} -ReplicaServerName {ReplicaServer from “Replica Remove”} -ReplicaServerPort 80 -AuthenticationType Kerberos -CompressionEnabled $true -RecoveryHistory 4 -VSSSnapshotFrequency 1 -AutoResynchronizeEnabled $true
Start-VMInitialReplication -VMName {VMName from “Initialize Data”}
}
}
Im Parent Runbook VHDRename folgt dann die VM Refresh Activity, so dass der VMM die umbenannte VHD zur Kenntnis nimmt. Dazu wird ein VMM PowerShell Skript aufgerufen, welches einen Refresh der VM anstößt. Das VMM PowerShell Skript ist in der VMM Library hinterlegt.
#Refresh
Param(
[String]$VM
)
Read-SCVirtualMachine -VM $VM
Die Pfadangabe unter PowerShell Script innerhalb der Activity sieht folgendermaßen aus.
\srv-1MSSCVMMLibraryScriptsVMM_PowerShell_VHD_Refresh.ps1 -VM {VM Name from “Get VM”}
Danach findet die Eintragung der Custom Property 2 mittels der Update VM Activity statt, so dass die VM beim nächsten Lauf des Runbooks keine Beachtung findet, da die VHD bereits umbenannt ist. Außerdem kann man so leichter bereits bearbeitete VMs identifizieren.
Zum Abschluss muss die VM wieder gestartet werden, falls sie zu Beginn eingeschaltet war. Dies übernimmt die Start VM Activity.
Damit ist das Runbook fertig und kann zum Einsatz kommen, um eine Namenskonsistenz und einfachere Identifizierung der VHD zu gewährleisten.
Bevor das Runbook eingesetzt wird, sollte der Ablauf in einer Testumgebung durchgespielt werden. Des Weiteren deckt das hier vorgestellte Runbook bezüglich der Diskkonfiguration nicht alle Eventualitäten ab. Ebenso beim Errorhandling, daher sind Anregungen und Ergänzungen jederzeit Willkommen.