… da der Hyper-V Manager die Option zum Löschen nicht anbietet.
Nachdem erfolgreichen Upgrade einer VM von Windows Server 2012 R2 auf Windows Server 2022 konnte ich hinterher die erstellten Checkpoints (Snapshots nicht löschen). Der Hyper-V Manager wollte mir diese Möglichkeiten nicht anzeigen.
Da ich über ein ähnliches Problem schon in Verbindung mit dem Synology Active Backup for Business gestolpert war, dachte ich mir es wieder mit PowerShell zu probieren.
# Zuerst lassen wir uns die vorhandenen SnapShots / Checkpoints anzeigen Get-VMSnapshot -VMName 'Name der VM'
# Löschen eines dedizierten Checkpoints Get-VMCheckpoint –VMName 'Name der VM' -Name "SonosGT …" | Remove-VMCheckpoint
Ich wollte gleich alle Checkpoints loswerden und habe dazu analog den Befehle wie schon bei Active Backup for Business verwendet.
# Löschen des Active Backup Snapshots Get-VMSnapshot -VMName 'Name der VM' | Remove-VMSnapshot
Es gibt Probleme, die erwischen einen auf dem falschen Fuß. Während der Einführung und Konfiguration von Synology Active Backup for Business musste ich feststellen, dass eine wichtige VM noch auf einem Windows Server 2012 R2 Hyper-V Host lief. Das tat sie seit Jahren sehr zuverlässig und vfel damit in die Kategorie “never touch a running system …”
Synology Active Backup for Business benötigt aber mindestens die Hyper-V Version 6 der VM oder besser und damit einen Hyper-V Host der mindestens mit Windows Server 2016 oder höher läuft. Damit war notgedrungen eine Neuinstallation des Servers notwendig, da ich in diesem Fall auf den kostenlosen Microsoft Hyper-V Server 2019 zurückgreifen wollte.
Vor dem Upgrade dachte ich mir das bestimmt ein Updates des BIOS sinnvoll wäre, das auf dem Server verwendete war von 2014 und Supermicro hat für dieses Board nochmals 2021 ein neues BIOS bereitgestellt. Damit also zuerst den Microsoft Hyper-V Server 2019 installiert und gleich im Anschluss das BIOS aktualisiert. Für den Server war das eine so große Neuerung, dass er mir den konfigurierten SET weggeworfen hat und den Ethernet-Adapter 2 als Nummer 3 präsentierte. Kein Thema, ließ sich alles fixen.
Der Import der einzigen darauf verbliebenen VM (die zwar Generation 2, aber mit Version 5.0 lief) funktionierte funktionierte ebenfalls ohne Probleme, aber der Start wollte nicht gelingen und nach ca. 2min befand sich die VM wieder im ausgeschalteten Zustand.
Zuerst hatte ich das BIOS im Verdacht, aber eine neu eingerichtete VM mal schnell mit OpenSuse installiert, funktionierte ohne Probleme und auch die Hyper-V Replika zu dem anderen Windows Server 2019 Hyper-V Host lief ohne Probleme. Was also tun?
Ein Blick in das Eventlog offenbarte die beiden folgenden Events.
Critical 03/18/2022 20:13:12 Hyper-V-Worker 18604 None 'mt-app-1' has encountered a fatal error but a memory dump could not be generated. Error 0x2. If the problem persists, contact Product Support for the guest operating system. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447B)
Critical 03/18/2022 20:13:12 Hyper-V-Worker 18560 None 'mt-app-1' was reset because an unrecoverable error occurred on a virtual processor that caused a triple fault. If the problem persists, contact Product Support. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447A)
Der Fehler wurde zwar schon 2019 mit dem Update KB4497934 behoben, dass hatte aber noch nicht den Weg auf den neu installierten Hyper-V Host gefunden und damit musste ich auf den Workaround zur Änderung des MAC Address Ranges greifen, was mit einem Aufruf in PowerShell recht einfach funktioniert.
Die folgende Abbildung zeigt den alten Adress-Bereich.
Für die Änderung muss man wissen wie eine MAC-Adresse überhaupt aufgebaut ist. Die ersten drei Oktette, also 11-22-33 oder in diesem Fall 00-15-5D sind dem jeweiligem Hardware-Hersteller zugeordnet, hier also Microsoft. Wenn nun der Bereich geändert werden soll, ist es am einfachsten das 4te Oktett zu inkrementieren.
# Anzeigen des aktuellen MAC-Adress Pools auf dem Hyper-V Host Get-VMHost | Select ComputerName, MacAddressMinimum, MacAddressMaximum | ft
# Konfiguration eines neuen MAC-Adress Bereichs auf dem Hyper-V Host, das 4te Oktett wurde von 23 auf 24 geändert Set-VMHost -MacAddressMinimum 00155D24AE00 -MacAddressMaximum 00155D24AEFF
Danach habe ich der VM den Netzwerk-Adapter entfernt und im Anschluss gleich wieder reinkonfiguriert. Danach startete mein Sorgenkind ohne Probleme.
Vor einiger Zeit startete ein Hyper-V Server neu, während ein Backup-Task des Synology Active Backup for Business aktiv war.
Active Backup for Business, sichert unter Hyper-V virtuelle Maschinen (VMs) dadruch, dass ein Checkpoint / SnapShot auf dem Hyper-V Server erstellt und aus diesem die VM konsistent gesichert wird.
Durch den automatischen Neustart des Hyper-V Hosts blieb der Checkpoint bestehen und konnte nicht über den Hyper-V Manager gelöscht werden.
Um den Checkpoint zu entfernen musste ich explizit PowerShell verwenden. Unter PowerShell heißt der Checkpoint dann auch wieder Snapshot (Microsoft wird das hoffentlich im Windows Server 2022 korrigieren).
# Löschen des Active Backup Snapshots Get-VMSnapshot -VMName 'Name der VM' | Remove-VMSnapshot
Neben dem in diesem Blog beschrieben Problem mit dem Hyper-V PowerShell-Module und Synology Active Backup for Business, bin ich auf ein weiteres Problem nach dem Upgrade auf DSM 7 gestoßen.
Zuvor muss ich aber klarstellen, dass die Probleme nicht explizit durch das Upgrade verursacht wurden, sondern durch die ebenfalls neue Version von Synology Active Backup.
Active Backup for Business und die “geänderten Blöcke” einer VM
Mit dieser Fehlermeldung konnte ich zuerst einmal Garnichts anfangen.
Ein wenig mehr Informationen waren dann in diesem Log zu finden.
Der manuelle Start des Tasks brachte dazu das folgende Ergebnis.
Im deutschen Synology-Forum habe ich dann ein ähnliches Problem mit VMware gefunden, allerdings aus dem Jahr 2018. Die Lösung war das Vergrößern des virtuellen Datenträgers (VHD) der VM, in diesem Fall von 96GB auf 100GB.
Interessant war dabei, dass alle anderen VMs ohne Probleme gesichert wurden. Lediglich diese VM machte mit der Fehlermeldung oben Probleme. Ob der Grund die noch verwendete Generation 1 war, oder möglicher Weise die initiale Erstellung der VHD kann ich aktuell nicht nachvollziehen. Die Erweiterung auf 100GB konnte das Problem lösen und das Backup funktionierte wieder wie vor dem Upgrade.
Um die Größe der VHD einer Generation 1 VM zu ändern, muss diese heruntergefahren werden. Danach kann mit dem Hyper-V Manager oder PowerShell die Änderung erfolgen.
# Erweitern des virtuellen Datenträgers einer VM Resize-VHD -Path "D:\Virtual Machines\BaseVHDX.vhd" -SizeBytes 100GB
Wird auf einem Windows Server (egal ob 2012R2, 2016 oder 2019) ein Lbfo-Team erstellt, schreibt das Betriebssystem nach einem Neustart die folgende Meldung (Warning) in das System-Eventlog.
Ein Blick auf alle vorhandenen MAC-Adressen zeigt, dass hier Adressen doppelt vergeben worden sind. Das erstellte Team (hier Team Ethernet 1) besitzt die gleiche MAC-Adresse wie einer der für das Team verwendeten Adapter.
Das Problem beheben wir damit, dass alle Adapter die eine gleiche Adresse haben abgeändert werden. Dabei ist es sinnvoll MAC-Adressen des Teams und des Hyper-V Virtual Switches zu ändern, anstatt die MAC der NIC zu überschreiben. Dort ist diese nämlich fest hinterlegt, im Team und im Hyper-V Switch jedoch nicht.
Das kann man über die GUI erledigen, oder falls ein Windows Server Core vorliegt mit PowerShell.
# Ändern der MAC-Adresse des Teams "Team Ethernet 1" Set-NetAdapter -Name "Team Ethernet 1" -MacAddress "0C-C4-7A-41-7B-45"
# Ändern der MAC-Adresse des Hyper-V Switches "vEthernet (_ Network 172.16.32.0)" Set-NetAdapter -Name "vEthernet (_ Network 172.16.32.0)" -MacAddress "0C-C4-7A-41-7B-48"
Nach der Änderung sieht die Vergabe der MAC-Adressen wie folgt aus und die Warnung 16945 wird beim nächsten Neustart nicht mehr ins Eventlog geschrieben.
Update zum Windows Server 2019:
Auf einem Windows Server 2019 hatte ich folgendes Verhalten, dort wurden die MAC-Adressen im Wechsel verteilt. Der Hyper-V Switch kollidierte mit MAC-Adresse des der ersten NIC, das Team mit der MAC-Adresse der zweiten NIC.
Beheben lässt sich das Problem aber auf die gleiche Weise. Hier nochmals die MAC-Adressen.
Nach dem Update einiger Hyper-V Hosts wollte die, für einige VMs eingerichtete Hyper-V Replication nicht mehr starten. Der Replication Health stand auf Critical und das Übliche, über das Menü des Hyper-V Manager verfügbare Resume Replication funktionierte nicht.
Eine Abfrage mit PowerShell stellte die Situation wie folgt dar.
Zusätzlich wurde im Hyper-V Manager die folgende Information bereitgestellt.
Das Problem war, dass ein Resync der Hyper-V Replication notwendig war. Dieser aber über den Hyper-V Manager nicht zur Verfügung stand, also in der GUI nicht angeboten wurde.
Die Lösung stellt hier, wie so oft unter Windows, PowerShell bereit. Hier besteht explizit die Möglichkeit einen Resync der VM anzustoßen.
# Hyper-V Replication, resync einer einzelnen VM Resume-VMReplication -VMName 'mt-app-2.testlab.local' -Resynchronize
Sollten mehrere VMs von dem Problem betroffen sein, können alle mit dem gleichen Health State über die Kombination der folgenden Befehle zu einem Resync bewegt werden.
# Hyper-V Replication, resync aller VMs eines Hosts im Zustand "critical" Get-VMReplication | Where-Object { $_.Health -eq 'Critical' } | Resume-VMReplication -Resynchronize
Bei einem Resync geht einiges an I/O über die Leitung und abhängig von der Größe der VMs kann das durchaus einige Zeit in Anspruch nehmen.
In diesem Fall waren es gut 5 Stunden. So, läuft wie man heute gerne dazu sagt.
Seit Windows Server 2016 bietet Hyper-V die Möglichkeit des Switch Embedded Teaming (SET). Dieser Blog beschreibt die Umstellung eines Hyper-V Hosts (Windows Server 2019) von normalen Teaming auf SET.
Da in der Regel auf Hyper-V Hosts VMs aktiv sind, sollten hier einige Vorsichtsmaßnahmen ergriffen werden.
Shutdown aller VMs
Für den Fall, dass eine VM automatisch startet muss diese Aktion ebenfalls deaktiviert werden
Anlegen oder aktivieren eines lokalen Admins, der auch funktioniert
Im ersten Schritt werden alle mit dem zu lösenden Team verbundenen Virtual Switches auf Internal oder Private Network umgestellt, nur dann lässt sich ein bestehendes Team löschen.
Die Umstellung ist temporär und damit verlieren die darauf laufenden VMs ihre Verbindung ins Netzwerk und werden darum wie in Punkt 1 oben geschrieben am besten heruntergefahren.
Der PowerShell Befehlt Get-NetLbfoTeam, zeigt die vorhandenen Teams an.
Beide Teams (also Team Ethernet 1 und Team Ethernet 2) werden nun gelöscht und zu einem SET verbunden.
# Löschen eines Teams Remove-NetLbfoTeam -Name "Team Ethernet 1" Remove-NetLbfoTeam -Name "Team Ethernet 2"
# Löschen aller Teams Get-NetLbfoTeam | Remove-NetLbfoTeam
Hier sollte klar sein, dass damit auch die Netzwerkverbindung zum Hyper-V Host verloren geht. Ist ein DHCP-Server vorhanden, werden die Adapter von diesem neue Adressen bekommen, ansonsten kann nun nur noch der Zugriff über die Konsole oder ein ILO-Board erfolgen. Siehe hier Punkt 3 oben, wir brauchen dann einen funktionierenden lokalen Administrator.
Das SET wird nun über diesen Befehl eingerichtet.
# Konfiguration eines SET Switch embedded teams New-VMSwitch -Name "_ Network 172.16.16.0" -NetAdapterName "Ethernet","Ethernet 2","Ethernet 3","Ethernet 4" -EnableEmbeddedTeaming $true -AllowManagementOS $true
Was nicht wirklich gut aus der Microsoft Dokumentation von New-VMSwitch hervorgeht, ist die Beschreibung von –EnableEmbeddedteaming.
Bei mehr als einem Adapter, wird automatisch –EnableEmbeddedTeaming $true verwendet, bei nur einem Adapter –EnableEmbeddedTeaming $false. Soll also ein SET gebaut werden, der zu Beginn nur einen Adapter besitzt und irgendwann erweitert wird, dann muss unbedingt –EnableEmbeddedTeaming $true verwendet werden.
-AllowManagementOS $true ist notwendig, damit auch der Hyper-V Host den Adapter verwenden kann, wir also mit einem konvergierten Adapter arbeiten. Nur dann kann eine IP-Adresse darauf gebunden werden.
Danach kann mit sconfig wieder die korrekte / alte IP des Adapters gesetzt werden und im Hyper-V Manager steht dieser dann wie folgt zur Verfügung.
Damit sind wir fertig, leider nein … es können nämlich eine Reihe von Dingen schief gehen!
Bei einigen, nicht bei allen Umstellungen habe ich die folgende Meldung erhalten.
External Ethernet adapter ‚Intel(R) 82574L Gigabit Network Connection‘ is already bound to the Microsoft Virtual Switch protocol.
Dadurch lässt sich der Adapter nicht in das SET aufnehmen und bedarf einer zusätzlichen Behandlung. Wahrscheinlich auch mit PowerShell möglich, habe ich aber ncspbind den Vorzug gegeben.
Das Tool ist in dem folgenden KB-Artikel beschrieben:
Wenn ich mir nicht sicher bin, ob meine Adapter noch sauber funktionieren, gibt es die Möglichkeit diese komplett zurück zu setzen. Mit komplett meine ich komplett!!!!
netcfg –d
Danach hilft nur noch die Anmeldung über das ILO-Board und ein durchgeführter Neustart des Servers, nun kann ebenfalls der SET konfiguriert werden.
Mit einem Scanner, wie zum Beispiel dem Advanced IP-Scanner lassen sich IPs in einfach auffinden. Das Tool, habe ich bei solchen Umstellungen immer parat.
Eigentlich ist das ein alter und bekannter Fehler. Das Verschieben einer VM unter Hyper-V schlägt fehl. In diesem Fall bin ich mit Powershell auf das Problem gestoßen. Nur das die Fehlermeldung nicht besonders sprechend ist.
Das Problem war einfach, dass ich Integration Services Setup Disk an der VM gemounted hatte.Genau genommen ist das auch keine Disk sondern ein ISO, dass sich auf jedem Hyper-V Host im Verzeichnis \Windows\System32\vmguest.iso befindet. Da dieses ISO sowohl am Quell- als auch am Ziel-Server vorhanden ist, kommt es hier zu einem Problem. Dismount von der VM und der Spuk ist vorbei, die Migration klappt. Der VMM von Microsoft hat hier übrigens das gleiche Problem.
Die Lösung ist also, dass mit der VM verbundene ISO zu entfernen. Mit PowerShell kann man das über den folgenden Befehl erfolgen.
In den Windows Server 2016 haben sich je eine Reihe von Eigenheiten eingeschlichen, die mir immer wieder Probleme bereiten. Kürzlich hatte ich mit dem Microsoft Hyper-V Server 2016, wieder das Problem, dass einige Hosts für den Shutdown sehr lange benötigt haben. Mit sehr lange meine ich, bis zu einigen Stunden!
Daher habe ich mir das Problem genauer angeschaut und dabei die Lokation des Pagefiles als Auslöser ausmachen können. Damit kann die in diesem Blog beschriebene Lösung auch hier zum Einsatz kommen. Da der Microsoft Hyper-V Server keine Benutzeroberfläche hat, muss das Pagefile über WMIC neu konfiguriert werden.
Anzeige des aktuell konfigurierten Pagefiles.
wmic pagefile list full
Umstellung auf ein nicht durch das Betriebssystem konfiguriertes Pagefile.
wmic computersystem where name=”%computername%” set AutomaticManagedPagefile=False
Konfiguration des Pagefiles auf Laufwerk C: mit einer Startgröße von 16GB und einer maximalen Größe von 32GB. Soll das Pagefile mit einer festen Größe angelegt werden, dann ist es notwendig InitialSize und MaximalSize auf den gleichen Wert zu setzen.
wmic pagefileset where name=”C:\\pagefile.sys” set InitialSize=16384,MaximumSize=32768
Die Änderungen werden erst nach einem Neustart des Servers durch WMIC angezeigt, hier sollte man sich also nicht beirren lassen. Insofern WMIC keine Fehlermeldungen zurück gibt, ist die Konfiguration korrekt erfolgt.
Abschließend habe ich mir die Frage gestellt, wieso das Problem eigentlich auftritt. Ich kann dieses Verhalten nämlich nicht bei allen Hyper-V Hosts mit der Version 2016 feststellen. Microsoft selbst liefert in einer Reihe von Artikeln und Blogs Empfehlungen zur Dimensionierung von Pagefiles. Für Hyper-V Systeme, kann man das kurz abfassen.
Geht dem Host der Speicher aus, und ist eine VM mit dynamisch allokiertem Speicher unterwegs dann erfolgt ein Paging in der VM und nicht auf dem Host
Es genügt, dass der Host einen Kernel- oder von mir aus noch Active-Dump schreiben kann. Kernel-Dumps habe ich bisher, auch bei sehr großen Systemen (1TB … und mehr) keinen größer als 20GB gesehen und damit war er für eingehende Analysen immer ausreichend
Darum habe ich auf kleinen Hyper-V Hosts (32GB RAM und 64 bzw. 72GB Systemlaufwerk) keine Probleme gehabt und auch auf zwei meiner größeren Systeme mit 128GB RAM und einem 256GB großem Systemlaufwerk, ist das Problem nicht aufgetreten.
Lediglich auf mehreren Hosts mit 256GB RAM und einem 72GB großen Systemlaufwerk, bin ich auf dieses Problem getroffen und habe es wie oben beschrieben gelöst. Dabei ist verständlich, dass das Betriebssystem bei 256GB Hauptspeicher das Pagefile auf ein Laufwerk mit hinreichend viel Platz legt und es dadurch zu dem Verhalten kommen kann.
Windows SBS and Essentials Blog 