Seit einigen Tagen gibt es im Azure Portal einen neuen Dialog für das Löschen von Viruellen Maschinen. Dieser bietet nun endlich die Möglichkeit, beim Löschen der VM auch alle ihre „Anhängsel“ wie Disks, NICs und public IPs mit zu löschen:
Aus meiner Sicht ist das – vor allem für die Nutzer, die sich mit Masse auf das Portal abstützen – eine tolle Sache, um Leichen im System zu vermeiden. Was hier noch fehlt (vor allem für kleine Testumgebungen) wäre das Löschen von Backups, virtuellen Netzen und anderen Resourcen, aber es ist ein Anfang!
Vor einiger Zeit (muss mehrere Jahre her sein) habe ich ein paar Azure Automation PowerShell Runbooks auf GitHub und hier veröffentlich, um VMs Zeit- und Tag- gesteuert starten und stoppen zu können und um heruntergefahren, nicht-deallokierte VMs zu deallokieren. Diese basierten auf AzureRM PowerShell Cmdlets / Modulen und einer etwas komplizierten Herangehensweise. Ich habe die Runbooks nun massiv überarbeitet, so dass diese erstens das neuere Az Modul verwenden und auch vom Aufbau her wesentlich einfacher sind. U.a. verwenden die Runbooks jetzt lokale Deutsche Zeit und sind robuster bei der Schreibweise der Tags (Groß-/Kleinschreibung).
Ihr findet diese Runbooks wie immer in meinem GitHub Repo, konkret genau hier:
Weil es die Tage bei einem meiner Kunden wieder mal ein Thema war, möchte ich es hier nun mal im Detail beleuchten. Und zwar geht es um die Anforderung, Virtuelle Maschinen in Azure starten und stoppen zu können, ohne beispielsweise die VM löschen zu können oder ihre SKU zu verändern. Natürlich gibt es den „Virtual Machine Contributor“ als built-in Role, aber diese darf eben deutlich zu viel.
Wie geht man nun an das Thema heran? Zunächst muss man zwei Dinge in Erfahrung bringen:
Den Namen des Resource-Providers um den es geht
Die Operationen auf diesem Provider, die man erlauben oder verbieten möchte
Nichts neues, aber da es mir heute wieder über den Weg gelaufen ist: Wenn man mittels Hyper-V Manager eine VM von einem Host auf einen anderen live verschieben, dann gibt es im Wesentlichen zwei mögliche Protokolle: CredSSP und Kerberos.
CredSSP ist in der Anendung grundsätzlich einfach, hat aber einen entscheidenden Nachteil: Man muss interaktiv (!) an dem Host angemeldet sein, von dem man die VM (weg) verschieben will. Andernfalls bekommt man einen hübschen Fehler:
Der Fehlertext lautet:
Fehler beim Herstellen einer Verbindung mit dem Host “DERHOSTNAME”: Die Anmeldeinformationen, die dem Paket übergeben wurden, wurden nicht erkannt. (0x8009030D).
Failed to establish a connection with host “THEHOSTNAME”: No credentials are available in the security package (0x8009030E)
Insbesondere auf Core-Servern bleibt hier also nur eine Möglichkeit: Man muss auf Kerberos umstellen! Dazu jedoch müssen sich die Server, zwischen denen man verschieben möchte, für das Protokoll “cifs” und “Microsoft Virtual System Migration Service” vertrauen.
Das könnte man jetzt im ActiveDirectory manuell konfigurieren – aber spätestens bei einer zweistelligen Anzahl an Hosts ist das eine sehr mühsame Klickerei. Also warum nicht PowerShell bemühen? Ich habe mir dazu schon vor einer ganzen Weile ein recht kurzes Skript geschrieben, was jeden der aufgeführten Host gegen jeden anderen berechtigt bzw. die Kerberos-Delegierung einrichtet.
Hier das Skript im Textlaut. Viel Spaß damit!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$Domain='domain.local'# Actually not needed anymore, but who knows...
Import-Module ActiveDirectory
# Put the NetBIOS names of your hosts here$HyperVHosts="HOST1","HOST2","HOST3","HOST4","HOST5"ForEach($Host1in$HyperVHosts){ForEach($Host2in$HyperVHosts){If($Host1-ne$Host2){"Delegating from $Host1 to $Host2..."
Get-ADComputer $Host1| Set-ADObject -Add @{"msDS-AllowedToDelegateTo"="Microsoft Virtual System Migration Service/$($Host2).$($Domain)","cifs/$($Host2).$($Domain)","Microsoft Virtual System Migration Service/$Host2","cifs/$Host2"}
Get-ADComputer $Host1| Set-ADAccountControl -TrustedForDelegation:$false-TrustedToAuthForDelegation:$true}}}
$Domain = 'domain.local'
# Actually not needed anymore, but who knows...
Import-Module ActiveDirectory
# Put the NetBIOS names of your hosts here
$HyperVHosts = "HOST1","HOST2","HOST3","HOST4","HOST5"
ForEach($Host1 in $HyperVHosts)
{
ForEach($Host2 in $HyperVHosts)
{
If($Host1 -ne $Host2)
{
"Delegating from $Host1 to $Host2..."
Get-ADComputer $Host1 | Set-ADObject -Add @{"msDS-AllowedToDelegateTo" = "Microsoft Virtual System Migration Service/$($Host2).$($Domain)", "cifs/$($Host2).$($Domain)", "Microsoft Virtual System Migration Service/$Host2", "cifs/$Host2"}
Get-ADComputer $Host1 | Set-ADAccountControl -TrustedForDelegation:$false -TrustedToAuthForDelegation:$true
}
}
}
Auch wenn die Tatsache selbst nicht neu ist möchte ich den folgenden Fakt etwas genauer beleuchten, da immer mehr Unternehmen Hyper-V für produktive Virtualisierungszwecke verwenden.
Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.
Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).
Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):
Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.
Glücklicherweise kündigt sich das bereits vorab an:
Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.
Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.
Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:
Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!
(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)
Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!
Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:
(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)
