Löschen eines Hyper-V Checkpoint mit PowerShell …

… 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.

image

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'

image

# 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

Enjoy it, b!

Synology Active Backup for Business | Hyper-V PowerShell-Module

Die Sicherung von virtuellen Maschinen (VM) mit Synology Active Backup for Business, die auf einem Microsoft Hyper-V Server oder Windows Server Core betrieben werden, setzt die Existenz des Hyper-V PowerShell-Modules voraus.

image

Ist dieses nicht vorhanden, schlägt die Konfiguration in Active Backup fehl und das PowerShell-Modul muss auf dem Host nachinstalliert werden.

image

Der erste Befehl zeigt, ob das Modul vorhanden ist oder nicht.

# current status of the modules on this Hyper-V server
Get-WindowsFeature *hyper-v*

Mit diesem Aufruf wird das fehlende Modul unter PowerShell installiert.

# install the Hyper-V PowerShell module
Install-WindowsFeature -Name Hyper-V-PowerShell

Danach funktioniert auch die Aufnahme des Hyper-V Hosts in das Management von Synology Active Backup for Business.

image

Enjoy it, b!

Hyper-V: Scheduled Checkpoint

Wenn Hyper-V (in diesem Fall war es die Version 2016), also Microsoft Hyper-V Server 2016 mit einem Checkpoint hängt, dann ist das Problem meistens der Hyper-V Virtual Machine Management Service.

Sichtbar wird das Problem durch folgende Anzeige im Hyper-V Management.

image

und Alternativ zum Status Deleting Checkpoint – Scheduled kann auch der Status Creating Checkpoint – Scheduled erscheinen, obwohl im Hyper-V Management keine Checkpoints angezeigt werden.

Die Lösung für das Problem ist ein Neustart des Hyper-V Virtual Machine Management Service, eventuell laufende VMs sind davon nicht betroffen und damit kann die Maßnahme ohne Downtime während des Betriebs durchgeführt werden.

:: cmd.exe/net.exe
net stop "Hyper-V Virtual Machine Management" && net start "Hyper-V Virtual Machine Management"
# PowerShell
Restart-Service -Name "Hyper-V Virtual Machine Management" -Verbose

Nach einem Neustart des Service ist alles wieder in Ordnung und die Meldung irgendwelcher Scheduled Checkpoints ist verschwunden.

image

Enjoy it, b!

Hyper-V failed to enable replication

Diese Meldung deutet auf ein Problem mit der Version der Virtuellen Maschine (VM) beim Einrichten einer Hyper-V Replica hin.

image

 

Was ist denn die Version einer VM genau?

Mit Windows Server 2012R2 wurden VMs der Generation 2 ermöglicht, eine Version der VMs trat aber bisher explizit nicht in Erscheinung, obwohl sie schon vorhanden war. Erst seit Windows Server 2016 ist es möglich die Version der VM im Hyper-V Manager als Spalte anzeigen zu lassen und darüber hinaus beim Erstellen der VM konkret die Version vor zu geben.

An einer Version, hängen Features von Hyper-V wie zum Beispiel die Möglichkeit eine VM in den Hibernation-Mode zu schicken. Daher muss ein Hyper-V Host die Version einer VM, die auf ihm ausgeführt werden soll auch unterstützen. Welche Version das ist, kann mit dem PowerShell-Befehl Get-VMHostSupportedVersion, ab Windows Server 2016 herausgefunden werden.

image

Get-VMHostSupportedVersion

Ob die Version in der Hyper-V MMC (Hyper-V Manager) angezeigt wird oder nicht, hängt vom verbundenen Hyper-V Host und nicht von der Version des Hyper-V Managers ab. Die folgende Abbildung zeigt das Hyper-V Management unter Windows 10 Build 1903 (neuer geht es aktuell nicht mehr) und einen dahinter liegenden Microsoft Hyper-V Server 2012R2.

image

Die nächste Abbildung das gleiche Hyper-V Management und einen damit verbunden Hyper-V Server 2016, inklusive der Möglichkeit die Configuration Version an zu zeigen.

image

Ähnlich verhält es sich in PowerShell, beim Anlegen einer VM. Das für Windows Server 2012R2 und älter zu verwende Hyper-V PowerShell-Modul, unterstützt den Parameter Version nicht, die VM muss also ohne diesen erstellt werden, bekommt aber trotzdem eine Version zugewiesen.

image

image

# Entladen des Hyper-V Modules
Remove-Module Hyper-V

# Import des aktuellen Hyper-V Modules
Import-Module Hyper-V

# Erstellen einer VM der Generation 2 mit Version 5.0
New-VM -ComputerName skye.whisky.local -VMName Linux -Generation "2.0" -Version "5.0"

Legt man nun auf einem Hyper-V Server 2016 oder neuer eine VM mit der Version 5.0 an, so ist die “kompatibel” mit Hyper-V 2012R2 und es kann auch eine Hyper-V Replica eingerichtet werden.

image

Import-Module Hyper-V -RequiredVersion 1.1

Get-VM -ComputerName nevis.whisky.local -VMName "_caolila.whisky.local" | fl Name, Generation, Version

Ein Version-Downgrade ist zum heutigen Stand nicht möglich, hier ist also Vorsicht geboten.

Enjoy it, b!

Hyper-V und der Saved-State einer VM

Neulich bekam ich eine VM auf einem Hyper-V Host (Windows Server 2012R2) in die Finger, welche sich aus dem Save-State partout nicht mehr starten lies.

image

Es erschien immer die folgende Fehlermeldung.

image

Nach ein wenig Social-Engineering, habe ich herausgefunden das am Wochenende ein BIOS-Update auf dem Hyper-V Host eingespielt wurde. BIOS Updates auf Servern können manchmal gravierende Änderungen mit sich bringen. Hier war es so, dass der Host gegenüber den Betriebssystem Veränderungen an der CPU bereitstellte und diese für alle gesicherten (Saved-State) VMs den Start verhinderten, die VMs welche hingegen sauber heruntergefahren wurden, starteten im Anschluss wieder ohne Probleme.

Daher, sollte mal das BIOS des Hyper-V Hosts aktualisiert werden, darauf achten das alle VMs sauber heruntergefahren wurden und sich nicht in einem Saved-State verharren. In diesem ist es nämlich nicht möglich, Änderungen an der Konfiguration der VM wie z.B. dem Prozessor Kompatibilitätsmodus einzustellen.

Natürlich, die Lösung …. war das Löschen des Saved-States!

image

Glücklicher Weise wurde die VM erst am Wochenende in diesen Zustand gebracht und so gingen keine noch nicht geschriebenen Daten verloren. Alternativ hätte man auch den Versuch unternehmen können, nochmals das alte BIOS (falls vorhanden) zu flashen, was ich mir aber vom Hersteller des Servers bestätigen lassen würde. Diese Vorgehensweise ist nämlich nicht immer supported.

Enjoy it, b!

Windows 10 Fall Creators Update 1709 und das Hyper-V Management klappt nicht mehr…

Nach der Installation, bzw. dem Upgrade auf das Windows 10 Fall Creators Update (1709) konnte auf zwei Systemen das Hyper-V Management meine Hosts nicht mehr erreichen. Ich bekam immer Meldung, RPC Server is unavailable, bzw. der RPC Server ist nicht verfügbar.

Nach ein wenig Suche und dem Vergleich mit einem anderen Windows 10 System, ohne das Upgrade, fiel mir auf das einige der für die Verbindung notwendigen Firewall-Regeln, nicht (mehr) aktiv waren.

image

Diese habe ich wieder aktiviert …

image

… und dann hat es auch wieder hingehauen, mit dem Hyper-V Management.

Noch ein kleiner Tipp am Rande, das Aktivieren der Firewall-Regeln als GPO stellt sicher, dass auch nach einem Upgrade diese auf jeden Fall wieder geöffnet werden.

Enjoy it, b!