vSphere 6.7 Update 1 und HP EX920 M.2 NVMe

Die im vSphere 6.7 Update enthaltenen VMware NVMe Treiber haben (zurecht) Probleme mit (m)einer HP EX920 M.2 NVMe Consumer SSD.

Da ich „kurzerhand“ eine VMware Umgebung brauchte, musste der Citrix Hypervisor von der guten alten Cloudia 2.0 weichen. Der erste Installationsversuch des vSphere Hypervisors (ESXi) in Version 6.7U1 scheiterte an der Realtek Netzwerkkarte meines ASRock Mainbords. Damit die Installation überhaupt startet, wurden die Net55-r8168 Treiber aus dem Online VIB Depot von v-front.de benötigt: https://vibsdepot.v-front.de/wiki/index.php/Net55-r8168

Nachdem die Installation auf meine „OS-SSD“ (240 GB WD Green M.2 SSD) abgeschlossen war, fand ich im vSphere Web Client leider nur meinen NVMe Adapter „[vmhba2]“ ohne das entsprechende Disk Device. Ein erneutes Prüfen der Speicheradapter brachte die NVMe leider nicht ans Licht aber eine erste Spur ins vmkernel Log:

2019-02-18T08:52:24.841Z cpu0:2098691 opID=2fcc202c)nvme:ScsiDiscover:3837:Namespace 1 not supported.
2019-02-18T08:52:24.841Z cpu0:2098691 opID=2fcc202c)ScsiScan: 756: Unable to scan path vmhba2:C0:T0:L0: Not supported

/var/log/vmkernel.log

Ein wenig Recherche brachte mich dann zu reddit: https://www.reddit.com/r/vmware/comments/a80r3y/issue_with_hp_nvme_drive_in_esxi/

Sollte der ESXi Host bereits laufen und, wie in meinem Fall, die NVMe nur eine zusätzliche Festplatte sein, dann können die Treiber aus dem 6.7 GA Offline Bundle exportiert , auf den Host kopiert und per „esxcli“ installiert werden. Dazu die beiden Ordner

  • vSphere 6.7 Offline\vib20\nvme
  • vSphere 6.7 Offline\vib20\vmware-esx-esxcli-nvme-plugin

auf den Host zum Beispiel in /tmp kopieren und mittels „esxcli software vib install“ installieren:

esxcli software vib install -v /tmp/VMware_bootbank_vmware-esx-esxcli-nvme-plugin_1.2.0.32-0.0.8169922.vib
esxcli software vib install -v /tmp/VMW_bootbank_nvme_1.2.1.34-1vmw.670.0.0.8169922.vib

Wer ebenfalls im HomeLab einen ESXi mit einer nicht unterstützten Realtek NIC in Betrieb nehmen möchte, muss sich vorab ein Custom Image mit der PowerCLI erstellen:

#Depot / Offline Bundle hinzufügen
Add-EsxSoftwareDepot 'E:\Install\vSphere 6.7U1 Offline\update-from-esxi6.7-6.7_update01.zip'

#Prüfen welche Images im Depot liegen
Get-EsxImageProfile | ft -AutoSize

#Neus Image im Depot bereitstellen und den Treiber Support auf "CommunitySupported" festlegen
New-EsxImageProfile -CloneProfile ESXi-6.7.0-20181001001s-standard -Name "Cloudia2.0" -Vendor "jans.cloud" -AcceptanceLevel CommunitySupported

#Realtek Treiber aus Offline Bundle von v-front.de einbinden
Add-EsxSoftwareDepot -DepotUrl E:\Install\net55-r8168\net55-r8168-8.045a-napi-offline_bundle.zip

#Prüfen, ob der Treiber da ist 😉
Get-EsxSoftwarePackage | ? Name -Like "net*" | ft -AutoSize

#Treiber ins Custom Image integrieren
Add-EsxSoftwarePackage -ImageProfile "Cloudia2.0" -SoftwarePackage net55-r8168

#Das ESXi Image Profil als ISO exportieren
Export-EsxImageProfile -ImageProfile "Cloudia2.0" -FilePath 'E:\Install\vSphere 6.7U1 Custom ISO\vSphere_6_7U1_Realtek.iso' -ExportToIso

#Oder auch als Offline Bundle
Export-EsxImageProfile -ImageProfile "Cloudia2.0" -FilePath 'E:\Install\vSphere 6.7U1 Custom ISO\vSphere_6_7U1_Realtek.zip' -ExportToBundle

Offloading der Netzwerkkarte mit PowerShell aktivieren

Ein kleines HowTo um Receive Side Scaling (RSS) sowie sämtliches Offloading der NIC(s) an einem Windows Server zu aktivieren (oder deaktivieren).

Ein Kunde hatte eine leicht vernachlässigte VMware vSphere Umgebung mit dem Stand der ESXi Hosts von 6.0 Update 1. Aufgrund der damals™ auftretenden Netzwerkprobleme, hatte der Kunde sich dazu entschlossen sämtliches Offloading sowie Receive Side Scaling auf den Netzwerkkarten zu deaktivieren. Siehe dazu den VMware KB Artikel 2129176. Nachdem die Umgebung auf einen aktuellen 6.5 Build aktualisiert wurde gab es erneut extreme Netzwerkprobleme. Siehe erneut den VMware KB Artikel 2129176. 😉

Kurzum musste auf diversen Windows Servern die erweiterte Netzwerkkartenkonfiguration angepasst werden. Vorher:

Jetzt folgte ein wenig PowerShell „Magic“:

# Zum Deaktivieren des Offloading sowie RSS alle Werte (-Value) auf "0" setzen
$RegRoot = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}"
$RegItems = Get-ChildItem -Path Registry::$RegRoot -Name
 
foreach ($RegItem in $RegItems) {
    if ($RegItem -ne "Properties" -and $RegItem -ne "Configuration") {
        $RegPath = $RegRoot + "\" + $RegItem
        if ($(Get-ItemProperty -Path Registry::$RegPath | Select-Object -ExpandProperty "ProviderName") -eq "VMware, Inc." -and $(Get-ItemProperty -Path Registry::$RegPath | Select-Object -ExpandProperty "DriverDesc") -eq "vmxnet3 Ethernet Adapter"){
            Set-ItemProperty -Path Registry::$RegPath -Name "*IPChecksumOffloadIPv4" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*LsoV1IPv4" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*LsoV2IPv4" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*LsoV2IPv6" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*RSS" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*TCPChecksumOffloadIPv4" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*TCPChecksumOffloadIPv6" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*UDPChecksumOffloadIPv4" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*UDPChecksumOffloadIPv6" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "OffloadIpOptions" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "OffloadTcpOptions" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "OffloadVlanEncap" -Value "1" -Force
        }
    }
}

Die evtl. große Frage: Was macht das Script? Generell recht simpel:

  1. Der Netzwerk-Adapter Zweig der Registry wird festgelet (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}). Siehe dazu die Microsoft Docs: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors
  2. Es werden alle Unterschlüssel des Registryzweiges ausgelesen und nacheinander in einer foreach-Schleife durchlaufen.
  3. Im Zweig gibt es neben den interessanten Schlüsseln „0000“ bis „00xy“ noch die uninteressanten Schlüssel „Propertiers“ sowie „Configuration“. Diese werden „aussortiert“.
  4. Der aktuelle Registry-Pfad wird gebaut und auf das Vorhandensein des Keys „ProviderName“ mit dem Wert „VMware, Inc.“ und „DriverDesc“ mit dem Wert „vmxnet3 Ethernet Adapter“ geprüft. (Wir befinden uns ja bei VMware, daher VMXnet3 und VMware Inc.)
  5. Zum Schluss werden die entsprechenden für das Offloading verantwortlichen Reg-Keys mit den passenden Werten geschrieben.

Und voilà:

Da wir uns hier ja im VMware Bereich befinden und es glücklicherweise die PowerCLI von VMware gibt, machen wir uns diese zu Nutze, um das Script auf allen Windows Systemen auszurollen:

$vCenterServer = "Name des VCenter Servers / der VCenter Appliance"
$Cred = Get-Credential
 
Get-Module -ListAvailable VMWare* | Import-Module
 
Connect-VIServer -Server $vCenterServer
 
foreach($VM in Get-VM | Where { $_.Guest -Like "*:Microsoft Windows Server*" }) {
    Write-Host $VM.Name
    Copy-VMGuestFile -VM $VM -Source C:\Install\Scripts\Offloading.ps1 -Destination C:\install\Scripts\Offloading.ps1 -LocalToGuest -GuestCredential $Cred -Force
    Invoke-VMScript -VM $VM -ScriptText C:\Install\Scripts\Offloading.ps1 -ScriptType Powershell -GuestCredential $Cred
}

Erneut, die Frage: Was ist passiert?

  1. Der FQDN des VCenters wird eingelesen, danach wird das Kennwort für einen entsprechenden Windows Benutzer in den VMs abgefragt und schließlich die verfügbaren VMware PowerShell Module der PowerCLI werden aufgelistet und geladen. Die PowerCLI gibt es übrigens >hier<.
  2. Es wird sich mit dem VCenter verbunden.
  3. Erneut geht es in eine foreach-Schleife in der alle Virtuellen Maschinen gesucht werden, die als Gast ein Windows Server OS ausführen.
  4. Völlig unspektakulär wird der VMName ausgegeben.
  5. Vom lokalen Client, auf dem die PowerShell ausgeführt wird, wird das Script C:\Install\Scripts\Offloading.ps1 (siehe oben) in die Gast VM an selbige Stelle kopiert. Dabei werden die anfangs eingegeben Credentials genutzt. „-Force“ wird benutzt, falls das Script schon dort liegen sollte.
  6. Zum Schluss wird das soeben kopierte Script in der virtuellen Maschine ausgeführt.

That’s it. 🙂

Device Cleanup – Unbekannte Geräte löschen

Unbekannte Geräte im Gerätemanager mit dem Device Cleanup Tool enfernen.

Bei einem Kunden werden derzeit eine Vielzahl an Terminalservern bzw. „neuerdings“ Remotedesktop-Session Hosts von VMware vSphere auf Hyper-V konvertiert. Um nicht alle unbekannten VMware Geräte im Gerätemanager von Hand löschen zu müssen, hat Uwe Sieber Gott sei Dank ein super Tool geschrieben: Device Cleanup Tool

Device Cleanup Tool
Device Cleanup Tool

Wer schon einmal von Hand im Gerätemanager die entsprechenden Devices entfernt hat, wird diese Arbeit alles andere als geliebt haben und sich wahnsinnig über dieses Device Cleanup Tool freuen. Das Tool wird einfach als administrativer User gestartet. Danach reicht ein Klick auf „Devices -> Select All“ sowie „Devices -> Remove selected“.

Generell kann ein Blick auf die Seite von Uwe Siebert nicht schaden, da er eine Menge an sehr guten Tools hat!

Des Weiteren würde ich soweit möglich auf eine V2V (Virtual to Virtual) oder auch P2V (Physical to Virtual) Migration verzichten. Wenn es sich absolut nicht vermeiden lässt, kann man so natürlich relativ schnell alte Hardware ablösen und das „gewohnte“ System auf neuer Hardware abbilden.