Hyper-V, Umstellung und Konfiguration von Switch Embedded Teaming (SET)

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.

  1. https://redmondmag.com/articles/2020/03/17/hyperv-switch-embedded-teaming-1.aspx
  2. https://redmondmag.com/articles/2020/03/19/hyperv-switch-embedded-teaming-2.aspx

Da in der Regel auf Hyper-V Hosts VMs aktiv sind, sollten hier einige Vorsichtsmaßnahmen ergriffen werden.

  1. Shutdown aller VMs
  2. Für den Fall, dass eine VM automatisch startet muss diese Aktion ebenfalls deaktiviert werden
  3. Anlegen oder aktivieren eines lokalen Admins, der auch funktioniert Winking smile

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.

image

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.

image

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.

image

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:

Creating V-switches within the hyper-V environment fails

Der folgende Befehl löst dieses Problem:

nvspbind /u “AdapterName” 

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.

Enjoy it, b!

Hyper-V Move-VM schlägt fehlt

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.

image

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.

Get-VMDvdDrive -VMName _vm1.testlab.local | Remove-VMDvdDrive

Ein ISO fügt man übrigens mit dem folgenden Befehl hinzu.

Add-VMDvdDrive -VMName _vm1.testlab.local -Path C:\Windows\system32\vmguest.iso

Enjoy it, b!

Sehr langer Shutdown oder Reboot des Microsoft Hyper-V Server 2016

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.

  1. 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
  2. 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.

image

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.

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!

Firmware Intel Data Center SSDs mit Hyper-V Server und AVAGO RAID Controller

Die Firmware von Intel Data Center SSDs auf einem Microsoft Hyper-V Server (oder auch Windows Server Core) kann über die Eingabeaufforderung (cmd.exe) mit den folgenden Schritten aktualisiert werden.

Herunterladen der aktuellen Firmware, auf einem PC mit Internet-Zugang:

https://downloadcenter.intel.com/de/download/27863/Intel-SSD-Data-Center-Tool?v=t

Entpacken des Intel SSD Data Center Tools vom PC auf den Microsoft Hyper-V Host (unter der Voraussetzung, dass die entsprechenden Berechtigungen existieren).

unzip \Users\<Username>\Downloads\Intel_SSD_Data_Center_Tool_3.0.13_Windows.zip -d \\<Hyper-V-Hostname>\c$\temp\intel-ssd

Ich habe auf allen meinen PCs unzip.exe über ein Batchscript im Pfad liegen, um an der Eingabeaufforderung schnell eine Datei entpacken zu können. Alternativ geht das natürlich auch mit PowerShell.exe ab Windows 10 oder Windows Server 2016 mit Expand-Archive:

Expand-Archive -LiteralPath C:\Users\<Username>\DownloadsIntel_SSD_Data_Center_Tool_3.0.13_Windows.zip -DestinationPath '\\<Hyper-V-Hostname>\c$\temp\intel-ssd\' -Force

image

Wurde das Intel SSD Data Center Tools auf den Host entpackt, wechseln wir in einer RDP Session auf diesen, um das Update vor zu nehmen.

mstsc /f /v:<Hyper-V-Hostname>

Auf dem Hyper-V Host befindet sich im Verzeichnis C:\Temp\intel-ssd das Intel SSD Data Center Tool welches wir nun in der richtigen Version (x64) installieren müssen:

image

Wie so oft hat man bei Intel Software keine Möglichkeit das Zielverzeichnis zu beeinflussen und so haben wir hinterher auf Laufwerk C: im Root die folgenden Verzeichnisse:

  • \Intel
  • \isdct

Das ist zwar nicht schön, aber auch nicht schlimm Winking smile zum eigentlichen Update muss man ins ISDCT Verzeichnis wechseln:

C:\Temp\intel-ssd> cd \isdct

Dort befindet sich isdct.exe womit wir die Firmware der SSDs aktualisieren können, wozu die folgenden Schritte notwendig sind.

Für den Fall, dass die SSDs an einem AVAGO/LSI RAID Controller hängen, muss der folgende Befehl eingegeben werden.

isdct.exe set -system EnableLSIAdapter=true 

image

Ohne diesen Aufruf, erkennt das Tool die SSDs nicht, oder nicht korrekt!

Mit den folgendem Aufruf, können die im System vorhandenen SSDs angezeigt werden, dabei analysiert auch gleich das Intel Data Center Tool ob ein Update der Firmware notwendig ist.

isdct.exe show –intelssd

image

Wichtig hier sind die folgenden Informationen:

  • Firmware : N2010112 (aktuelle Firmware)
  • FirmwareUpdateAvailable : N2010121 (neue Firmware)
  • Index : 0 (Index der SSD, geht bei 4 SSDs von 0 bis 3)

Die eigentliche Aktualisierung erfolgt nun mit diesem Aufruf – Wichtig: Bis jetzt wurden nur Informationen der SSDs gelesen, die Aktualisierung ist ein Schreibvorgang (Stichwort Datenbackup) der laut Intel nicht destruktiv ist (also eigentlich nix passieren kann).

isdct.exe load -intelssd <Index>

Für den Fall, dass wir 4 SSDs (Index 0 bis 3) aktualisieren müssen kann auch das folgende Script verwendet werden.

@ECHO OFF

FOR /L %%a IN (0,1,3) DO (

	ECHO y | isdct.exe load –intelssd %%a

)

Eine abschließende Analyse mit dem Intel SSD Data Center Tool zeigt, dass nun alle SSDs die aktuelle Firmware besitzen.

- Intel SSD DC S3520 Series PHDV723201YD480BGN -

Bootloader : Property not found
DevicePath : LSI10
DeviceStatus : 
Firmware : N2010121
FirmwareUpdateAvailable : The selected Intel SSD contains current firmware as of this tool release.
Index : 0
ModelNumber : INTEL SSDSC2BB480G7
ProductFamily : Intel SSD DC S3520 Series
SerialNumber : PHDV723201YD480BGN

- Intel SSD DC S3520 Series PHDV723201K1480BGN -

Bootloader : Property not found
DevicePath : LSI5
DeviceStatus : 
Firmware : N2010121
FirmwareUpdateAvailable : The selected Intel SSD contains current firmware as of this tool release.
Index : 1
ModelNumber : INTEL SSDSC2BB480G7
ProductFamily : Intel SSD DC S3520 Series
SerialNumber : PHDV723201K1480BGN

- Intel SSD DC S3520 Series PHDV717503PB480BGN -

Bootloader : Property not found
DevicePath : LSI6
DeviceStatus : 
Firmware : N2010121
FirmwareUpdateAvailable : The selected Intel SSD contains current firmware as of this tool release.
Index : 2
ModelNumber : INTEL SSDSC2BB480G7
ProductFamily : Intel SSD DC S3520 Series
SerialNumber : PHDV717503PB480BGN

- Intel SSD DC S3520 Series PHDV717501MN480BGN -

Bootloader : Property not found
DevicePath : LSI7
DeviceStatus : 
Firmware : N2010121
FirmwareUpdateAvailable : The selected Intel SSD contains current firmware as of this tool release.
Index : 3
ModelNumber : INTEL SSDSC2BB480G7
ProductFamily : Intel SSD DC S3520 Series
SerialNumber : PHDV717501MN480BGN

So, nun sind wir fertig … den Server noch Rebooten und das war es dann.

Enjoy it, b!

Hyper-V VM Windows Server 2016 hängt beim Shutdown oder Reboot

Beim letztem Patchday musste ich feststellen, dass ein Windows Server 2016, der als VM auf einem Hyper-V Host lief, keinen Shutdown oder Reboot durchführen konnte. Die VM blieb einfach hängen.

Meine erste Vermutung war ein Problem mit dem Pagefile beim Shutdown und so schaute ich mir die Konfiguration des Servers an.

image

Gemäß der Standard-Einstellung hat sich das Betriebssystem dazu entschieden, dass Pagefile auf Laufwerk D: zu legen. Nach Änderung auf Laufwerk C: (wie im folgendem Bild zu sehen) konnte die VM problemlos herunterfahren oder auch durchstarten.

image

Sollte ich Zeit haben, muss ich mir die Sache genauer anschauen. Aber der Workaround oben hat schon einmal geholfen.

Enjoy it, b!

Hyper-V Linux VM Boot Problem

Für einen aufwendigeren Test hatte ich mir unter Hyper-V eine Linux VM (Generation 2 mit CentOS 7.4) konfiguriert, mit der Absicht deren Disk für eine Reihe weiterer VMs zu verwenden … analog zum SysPrep von Windows.

Der Boot einer neuen VM mit der kopierten Linux VHDX ging aber sofort, mit der folgenden Meldung daneben.

image

Die Lösung des Problems ist, wenn man die notwendigen Schritte kennt nicht sonderlich schwer. Eigentlich haben wir ein Problem mit dem Bootloader von Linux.

Im ersten Schritt schalten wir die VM über das Hyper-V Management aus und fügen im Anschluss (wenn die VM aus ist) ein Linux ISO hinzu. Danach verändern die Boot Reihenfolge so, dass die VM von der DVD (sprich dem ISO Image startet).

image

Die Änderung erfolgt unter Change Hardware/Firmware/Boot order im Hyper-V Management und sollte das DVD-Laufwerk an erster Stelle haben.

  1. DVD Drive
  2. Hard Drive
  3. Network Adapter

Nun wird die VM wieder eingeschaltet und es erfolgt ein Boot von der DVD. Innerhalb des Boot-Menüs erfolgt dann die Auswahl Select Troubleshooting / Rescue a CentOS system.

image

Linux erkennt nun die vorhandene Installation und mounted diese unter /mnt/sysimage

Damit liegt unser Boot-Verzeichnis unter /mnt/sysimage/boot/efi/EFI und wir können das mit Hilfe der folgenden Schritte reparieren.

# Wechsel in das EFI Verzeichniss
cd /mnt/sysimage/boot/efi/EFI
# "Weg-Kopieren" des Boot files
cp -r centos/ boot
# ODER ALTERNATIV bei Ubuntu
cp -r ubuntu/ boot
mv fbx64.efi grubx64.efi

Nun fahren wir das Linux System wieder runter …

shutdown

… schalten die VM aus und ändern erneut die Boot-Reihenfolge unter Change Hardware/Firmware/Boot order im Hyper-V Management damit nun die VHD an erster Stelle steht.

  1. Hard Drive
  2. DVD Drive 
  3. Network Adapter

Damit startet mein CentOS ohne Probleme.

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!