Archiv der Kategorie: Hyper-V

Hyper-V | Konvertierung virtueller Disks

Veröffentlicht am von
Antwort

Gerade gibt es im Bereich der Virtualisierung recht viel zu tun. Ein zentrales Thema ist dabei die Konvertierung von virtuellen Disks (VHD). Da Broadcom VMware freiwillig aufs Abstellgleis geschoben hat, spielen OpenSource und Hyper-V immer mehr eine wichtige Rolle.

Ich bin schon lange ein Freund von Hyper-V, da damit auch in kleinen Umgebungen virtualisiert werden kann, wenn ohnehin schon eine Windows Server-Lizenz vorliegt. Spätestens seit QNAP und Synology ihre NAS-Systeme mit Prozessoren von AMD und Intel ausstatten und zudem Hauptspeicher von 32 GB und mehr vorhanden ist, spricht nichts dagegen, auch auf einem NAS einen Anwendungsserver zu virtualisieren.

QEMU, hin und zurück

Während sich VHDs von Hyper-V (auch VHDX genannt) unter dem Synology Virtual Machine Manager importieren lassen und dabei zu einer VMDK konvertiert werden, ist bei der Migration einer VM von einer Synology auf einen Hyper-V-Server Handarbeit erforderlich.

Wird eine VM auf einem Synology-NAS exportiert, liegt am Ende des Vorgangs eine OVA-Datei in einem Verzeichnis/Share vor.

Die OVA-Datei ist ein Container, der neben allen Festplatten der VM auch deren Konfiguration in Form einer XML-Datei beinhaltet. Letztere wurde jedoch aus „Sicherheitsgründen” mit der Endung OVF versehen.

Der Importvorgang unter Hyper-V, der im Grunde keiner ist, läuft dabei wie folgt ab:

  1. Erstellen einer VM in Hyper-V mit den passenden Parametern. Hat man sich die Konfiguration nicht gemerkt, kann man ja in der OVF-Datei nachschauen
  2. Kopieren der VHDX in den Ordner “Virtual Hard Disks”
  3. Anhängen der virtuellen Disk (VHDX ) an die VM
  4. Start der VM

Wie kommt man nun aber von der OVA zu einer VHDX -Datei?

Dazu sind die folgenden Schritte notwendig:

image

Hier die einzelnen Befehle und bitte die Namen der Disks anpassen:

::  Entpacken der OVA-Datei mit 7z
7z.exe e w11-test-02.ova

::  Konvertieren der ersten Disk aus der OVA-Datei (welche das Betriebssystem enthaelt) in das vhdx-Format
qemu-img.exe convert w11-test-02-disk1.vmdk -O vhdx -o subformat=dynamic w11-test-02.vhdx

Nachdem Microsoft den Virtual Machine Converter (MVMC) aus unerfindlichen Gründen beerdigt hat, verwende ich neben dem QEMU disk image utility noch Disk2vhd, wenn ich mich nur in der Microsoft-Welt bewege.

Nachdem Microsoft aus unerfindlichen Gründen den Virtual Machine Converter (MVMC) eingestellt hat, verwende ich neben dem QEMU Disk Image Utility noch Disk2VHD, wenn ich mich ausschließlich in der Microsoft-Welt bewege.

Enjoy it, b!

Hyper-V | Windows Server 2022 DHCP Result code 83

Veröffentlicht am von
Antwort

Wird unter Microsoft Hyper-V (Windows Server mit der Hyper-V Rolle) eine virtuelle Maschine mit Windows Server 2022 als Gastbetriebssystem installiert, kommt es häufig vor, dass die IP-Konfiguration nicht von DHCP auf eine statische IP umgestellt werden kann.

Der folgende Screenshot zeigt einen Microsoft Hyper-V Network Adapter in der Server Core Configuration (sconfig).

Unbenannt-1

Die Änderung der IP von DHCP auf eine fest zugewiesene, statische Adresse wird mit folgender Fehlermeldung quittiert und der Adapter verbleibt in der dynamischen Konfiguration.

Unbenannt-2

Lösen läßt sich das Problem über die PowerShell und folgende Befehle.

# Ermitteln des Interface-Indexes des Netzwerk-Adapters
Get-NetAdapter
# Entfernen der IP-Adresse
Remove-NetIPAddress -ifIndex 6 -Confirm:$false
# Vergabe einer neuen, statischen IP-Adresse
New-NetIPAddress -ifIndex 6 -IPAddress 192.168.11.141 '
-PrefixLength 24 - DefaultGateway 192.168.11.1

Sieht dann im Screenshot wie folgt aus.

Unbenannt-3

Enjoy it, b!

Windows 11 Hyper-V VM kann nicht gelöscht werden

Veröffentlicht am von
Antwort

Wenn das Hyper-V Management eine VM anzeigt, die nicht mehr administriert werden kann, dann handelt es sich um übrig gebliebene Fragmente. Wurde die VM z.B. aus dem Dateisystem gelöscht und wie in diesem Fall Hyper-V sogar deinstalliert, so taucht die VM nach einer erneuten Installation von Hyper-V wie ein Zombie wieder auf.

Untitled-1

Das Problem konnte ich auf einfache Weise mit der Eingabeaufforderung (als Administrator gestartet) lösen.

image

Nach einem Neustart des Hyper-V Managements war die VM nicht mehr vorhanden. Das Beenden der vmms.exe war natürlich nicht die feine Art und so empfiehlt es sich, den Rechner neu zu starten, bevor Hyper-V wieder verwendet wird.

Untitled-2

Enjoy it, b!

Löschen eines Hyper-V Checkpoint mit PowerShell …

Veröffentlicht am von
Antwort

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

Hyper-V 18560, Triple Fault

Veröffentlicht am von
Antwort

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.

image

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.

Enjoy it, b!

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

Veröffentlicht am von
Antwort

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!

Synology NAS | Löschen eines Checkpoints unter Hyper-V

Veröffentlicht am von
5

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.

Checkpoint-no-delete

Durch den automatischen Neustart des Hyper-V Hosts blieb der Checkpoint bestehen und konnte nicht über den Hyper-V Manager gelöscht werden.

Checkpoint-no-delete-2

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

Enjoy it, b!

Synology DSM 7 | Nacharbeiten Active Backup 2

Veröffentlicht am von
Antwort

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.

image

Ein wenig mehr Informationen waren dann in diesem Log zu finden.

image

Der manuelle Start des Tasks brachte dazu das folgende Ergebnis.

Untitled

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

Enjoy it, b!

NIC Teaming: Warning 16945 MsLbfoSysEvtProvider

Veröffentlicht am von
3

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.

image

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.

image

Hier nochmals die MAC-Adressen.

  • TEAM Team Ethernet 1 = 0C-C4-7A-41-7B-47
  • NIC Ethernet = 0C-C4-7A-41-7B-47
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) = 0C-C4-7A-41-7B-47

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.

  • TEAM Team Ethernet 1 = 0C-C4-7A-41-7B-45

  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) =
    0C-C4-7A-41-7B-48

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.

image

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.

image

Beheben lässt sich das Problem aber auf die gleiche Weise. Hier nochmals die MAC-Adressen.

  • TEAM Team Ethernet 1 = AC-1F-6B-F6-3E-C1
  • NIC Ethernet = AC-1F-6B-F6-3E-C1
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) = AC-1F-6B-F6-3E-C0
  • NIC Intel Ethernet I210 #2 = AC-1F-6B-F6-3E-C0

image

  • TEAM Team Ethernet 1 = AC-1F-6B-F6-3E-C3
  • NIC Ethernet = AC-1F-6B-F6-3E-C1
  • Hyper-V Virtual Switch vEthernet (_ Network 172.16.32.0) =
    AC-1F-6B-F6-3E-C2
  • NIC Intel Ethernet I210 #2 = AC-1F-6B-F6-3E-C0

Enjoy it, b!

Hyper-V Replication State Critical

Veröffentlicht am von
Antwort

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.

image

Eine Abfrage mit PowerShell stellte die Situation wie folgt dar.

image

Zusätzlich wurde im Hyper-V Manager die folgende Information bereitgestellt.

image

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.

image

image

In diesem Fall waren es gut 5 Stunden. So, läuft wie man heute gerne dazu sagt.

image

image

Enjoy it, b!