– Jan's Cloud – online Gedankenstütze ;)

7. November 2018

Offloading der Netzwerkkarte mit PowerShell aktivieren

Filed under: PowerShell,VMware,Windows Server — Schlagwörter: , , , , , — Jan Mischo @ 10:27

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 simepl:

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

21. November 2017

Device Cleanup – Unbekannte Geräte löschen

Filed under: Hyper-V,VMware,Windows Server — Schlagwörter: , , , , , , , — Jan Mischo @ 08:54

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.

 

16. Oktober 2017

VMware Virtual Guest Tagging unter Hyper-V umsetzen

Wie kann Virtual Guest Tagging unter Hyper-V umgesetzt werden?

Häufig wird Virtual Guest Tagging für Firewalls / Router oder andere Netzwerk-Appliances (Load Balancer, Application Delivery Controller, …) benötigt. Da es unsererseits erste konkrete Pläne zum Ablösen der VMware Umgebung durch Hyper-V gibt, brauchen wir Virtual Guest Tagging unter Hyper-V für unsere gehosteten Netscaler Appliances.

In einer VMware Umgebung lässt sich relativ simpel Virtual Switch Tagging (VST), External Switch Tagging (EST) und Virtual Guest Tagging (VGT) umsetzen. In den meisten Fällen wird es unter VMware auf VST hinauslaufen. Unter Hyper-V wird das VLAN üblicherweise direkt an der virtuellen Netzwerkkarte der VM getagged. In der GUI gibt es leider keine Möglichkeit, Virtual Guest Tagging unter Hyper-V umzusetzen. Hyper-V bringt dafür aber ein entsprechenden PowerShell CMDlet mit: Set-VMNetworkAdapterVlan.

Set-VMNetworkAdapterVlan -VMName <Name der VM> -Trunk -AllowedVlanIdList "1200-1299" -NativeVlanId 1200
Set-VMNetworkAdapterVlan -VMName <Name der VM> -Trunk -AllowedVlanIdList "1200,1300,1400" -NativeVlanId 1200
Set-VMNetworkAdapterVlan -VMName <Name der VM> -Trunk -AllowedVlanIdList "1200-1210,1300,1400" -NativeVlanId 1200

Sofern der Netzwerker keine VLANs auf dem Uplink Trunk vergessen hat, kann auch schon das Tagging in der Gast-VM erfolgen.

Hyper-V in Guest tagging / virtual Guest tagging

Hyper-V in Guest tagging / virtual Guest tagging

28. Mai 2015

ESXTop zeigt hohe DAVG/cmd und negative KAVG/cmd unter vSphere 5.5 Update 2 (5.5.0 2718055)

Filed under: VMware — Schlagwörter: , , , , , , , , , — Jan Mischo @ 12:56

Aufgrund von kleineren Performanceproblemen mit verschiedenen VMs auf unterschiedlichen Hosts im Cluster fielen mit ESXTop ungewöhnliche Werte für DAVG und KAVG auf.

VMWare hohe KAVG DAVG

VMWare hohe KAVG DAVG

 

 

 

 

Nach einem Support Call bei VMWare wurde ich auf den KB Artikel 2096171 aufmerksam gemacht. Hier handelt es sich also nicht um das gesuchte Problem sonder lediglich nur um einen „Schönheitsfehler“ der bei VMWare bekannt ist und schon länger auf eine Lösung wartet.

 

Ein kleiner Exkurs zu ESXTop und Visual ESXTop: http://www.yellow-bricks.com/esxtop/

Older Posts »

Powered by WordPress