Blog
Tuesday, 13. July 2021

vSphere 7 Update 2 führt zu Verbindungsverlust von SD Workaround

Anna
Teamleitung Website & Content

Aktualisieren Sie vSphere 6.7 auf vSphere 7, könnte Ihnen aufgefallen sein, dass die Verbindung zum SD Karten Workaround unterbrochen wurde. Dieses Phänomen tritt auf, wenn Sie vSphere auf einer SD-Karte installiert haben. Wir gehen in diesem Artikel auf das besagte Phänomen ein und helfen beim Troubleshooting.

Problemstellung
Sie führen das vSphere 7 Update 2 auf einer SD-Karte aus und merken, dass die Verbindung zur SD-Karte abgebrochen wurde und der ESXi-Host seine Arbeit einstellt. Der Zugriff auf die SD-Karte und die Systempartition wird nicht mehr gewährleistet. Zwar funktionieren alle virtuellen Maschinen weiterhin, jedoch können sie nicht mehr herunter- oder hochgefahren werden und die Durchführung von Migrationen ist ebenfalls nicht mehr möglich. Wie gehen Sie nun vor?

Wie wir wissen, erreicht der ESXi Host rund 100% der CPU Leistung. Auch haben alle VMs einen recht großen Einfluss auf die generelle Serverperformance. Dass wir mit vermeintlich defekten VMs arbeiten können, steht außer Frage. Die einzige Option zum jetzigen Zeitpunkt ist der “hard reset” des Servers und den Neustart der VMs auf einem anderen ESXi Host.

Mainzer Datenfabrik - vSphere 7 Update 2 führt zu Verbindungsverlust von SD Workaround

Überprüfen Sie nun die Fehlerprotokolle, wird Ihnen folgende Information begegnen:

[root@ESXihost-02:~] cat /var/log/vmkernel.log
[scsiCorrelator] 159156536237us: [vob.scsi.scsipath.pathstate.dead] scsiPath vmhba32:C0:T0:L0 changed state from on
[APDCorrelator] 159156536280us: [vob.storage.apd.start] Device or filesystem with identifier [mpx.vmhba32:C0:T0:L0] has entered the All Paths Down state.
[APDCorrelator] 159160830951us: [esx.problem.storage.apd.start] Device or filesystem with identifier [mpx.vmhba32:C0:T0:L0] has entered the All Paths Down state.
[scsiCorrelator] 159300836592us: [esx.problem.storage.connectivity.lost] Lost connectivity to storage device mpx.vmhba32:C0:T0:L0. Path vmhba32:C0:T0:L0 is down. Affected datastores: "BOOTBANK1", "BOOTBANK2", "LOCKER-608ae29b-4ead423d-c7c6-9cb65488f908".
[APDCorrelator] 159296538357us: [vob.storage.apd.timeout] Device or filesystem with identifier [mpx.vmhba32:C0:T0:L0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
[APDCorrelator] 159300836802us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [mpx.vmhba32:C0:T0:L0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
[scsiCorrelator] 159560024050us: [vob.scsi.scsipath.remove] Remove path: vmhba32:C0:T0:L0
[scsiCorrelator] 159600111736us: [vob.scsi.scsipath.add] Add path: vmhba32:C0:T0:L0
[scsiCorrelator] 159600245116us: [vob.scsi.scsipath.pathstate.on] scsiPath vmhba32:C0:T0:L0 changed state from dead
[root@ESXihost-01:~] cat /var/log/vmkernel.lo
VMW_SATP_LOCAL: satp_local_updatePath:856: Failed to update path "vmhba32:C0:T0:L0" state. Status=Transient storage condition, suggest retry
ScsiPath: 8058: Cancelled Cmd(0x45b918514a40) 0x12, cmdId.initiator=0x4538cae9bcb8 CmdSN 0x45097 from world 0 to path "vmhba32:C0:T0:L0". Cmd count Active:0 Queued:1.
WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "mpx.vmhba32:C0:T0:L0" state in doubt; requested fast path state update...
ScsiDeviceIO: 4315: Cmd(0x45b918514a40) 0x12, cmdId.initiator=0x4538cae9bcb8 CmdSN 0x45097 from world 0 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer. Cmd count Active:1

Das NMP-Gerät „mpx.vmhba32:C0:T0:L0“ gibt uns die Information, dass die SD vom System nicht mehr verfügbar ist.

[root@ESXihost-01:~] cat /var/log/vmkernel.log | grep -i alert
ALERT: hostd performance has degraded due to high system latency
ALERT: hostd performance has degraded due to high system latency
ALERT: hostd performance has degraded due to high system latency
ALERT: hostd performance has degraded due to high system latency
ALERT: Bootbank cannot be found at path '/bootbank'
ALERT: hostd performance has degraded due to high system latency

VMware gab zunächst an, dass es sich wohl um ein Herstellerproblem handelt. Jedoch haben wir herausgefunden, dass es auf ein VMware Problem zurückzuführen ist. Die Indizien sprechen hier für ein Fehler des vmkusb-Treibers.

Um das zu überprüfen, haben wir den Treiber durch folgende aktualisierte Vibs ersetzt:

  • Broadcom-ELX-lpfc_12.8.329.1-1OEM.700.1.0.15843807_17657023.zip
  • fc-enablement-component_700.3.7.0.5-1_17477831.zip
  • hpessacli-Komponente_5.10.45.1-7.0.0_17771110.zip
  • ilo-driver_700.10.7.0.6-1OEM.700.1.0.15843807_17481969.zip
  • sutComponent_700.2.8.0.20-0-signed_component-17782108.zip

Bis die Systemänderungen allerdings zum Tragen kommen, kann hier und da auch einige Zeit vergehen. Die Lösung des Problems scheint es zu sein, die ESXi Hosts mit einem vSphere 7 Update 1 neu zu installieren. Es sind zwar vereinzelt dieselben Probleme mit vSphere 7 U1 aufgetreten, jedoch deutlich seltener. Derzeit ist diese Option wohl die einzige, die das Problem “längerfristig” in den Griff bekommt.

Melden Sie sich in der ESXi-Host-Konsole an und führen folgendes Skript aus:

[root@ESXihost-01:~] esxcfg-rescan -d vmhba32
Rescan complete, however, some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds

oder alternativ:

[root@ESXihost-01:~] esxcfg-rescan -d vmhba32
Error while rescanning adapter vmhba32. Error was Unable to scan VMkernel SCSI subsystem for old devices.  Scan already in progress
[root@ESXihost-01:~] esxcfg-rescan -d vmhba32
Error while rescanning adapter vmhba32. Error was Unable to scan VMkernel SCSI subsystem for old devices.  Scan already in progress
[root@ESXihost-01:~]   esxcfg-rescan -d vmhba32

Vermutlich müssen die Skripte einige Male durchgeführt werden, bis sie zum gewünschten Ergebnis kommen und fehlerfrei beendet werden. Sie erkennen den erfolgreichen Ausgang an der Protokollausgabe, dass “mpx.vmhba32:C0:T0:L0” im rw-Modus gemounted wurde.

Tritt jedoch das Problem weiterhin auf, sollten Sie die Management Agents mit folgendem Befehl neu starten:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart
Mainzer Datenfabrik - vSphere 7 Update 2 führt zu Verbindungsverlust von SD Workaround

Sie sollten nun jetzt die Möglichkeit haben, Ihre VMs auf einen anderen EXSi Host zu migrieren und neu zu starten. Hier besteht jedoch ebenfalls die Gefahr, dass das SD Workaround Problem weiterhin bestehen bleibt. VMware empfiehlt an dieser Stelle, die RamDisk zu aktivieren. Existiert derzeit noch keine RamDisk, sollte sie neu erstellt und konfiguriert werden. Nutzen Sie dafür nachfolgenden Befehl:

esxcli system settings advanced list -o /UserVars/ToolsRamdisk

Wichtig: Setzen Sie die Int Value entweder manuell von 0 auf 1 oder verwenden Sie diesen Befehl:

esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1

Verwenden Sie mehrere ESXi Hosts, ist die manuelle Einrichtung sehr zeitintensiv. Um dies zu Zentralisieren verwenden wir nachfolgendes Skript von Luciano Patrão, welches überprüft, ob eine RamDisk existiert. Wenn die Überprüfung negativ ausfällt, wird automatisch eine RamDisk erstellt und aktiviert.

################################################
# Created by: Luciano Patrão                   #
# Date: 21-05-2021                             #
#                                              #
# Create ToolsRamdisk and Set to True          #
# Workaround for vSphere 7 Update 2 issue      #
################################################

###### Credentials and vCenter connection ######

$user = "CenterUSER"
$pwd = "Password"
$vCenter = 'vCenterIP'

Connect-VIServer $vCenter -User $user -Password $pwd

### vCenter Server Name(FQNP)
$vCentName = [system.net.dns]::GetHostByAddress($vCenter).hostname
################################################

cls
#####

$Output=@()
$Cluster = Get-Cluster "Infrastructure-Cluster"
$Hosts = $Cluster | Get-VMHost | where {$_.PowerState -eq "PoweredOn"} | Sort
$Vars = "UserVars.ToolsRamdisk"

Foreach ($ESXi in $Hosts) {

  $Setting = $ESXi | Get-AdvancedSetting | Where  {$_.Name -like "UserVars.ToolsRamdisk"}
  $ESXcli = Get-EsxCli -V2 -VMHost $ESXi

  If ($Setting.Name -notlike $Vars ) {
    Write-host "ToolsRamdisk was not found in Host ==> $ESXi. Creating..."  -ForegroundColor DarkRed
    $Args = $ESXcli.system.settings.advanced.add.CreateArgs()
    $Args.option = “ToolsRamdisk”
    $Args.description = “Use VMware Tools repository from /tools ramdisk”
    $Args.type = “integer”
    $Args.intdefault = “0”
    $Args.min = “0”
    $Args.max = “1”
    $Args
    $ESXcli.system.settings.advanced.add.Invoke($Args)

    $Output+= "ToolsRamdisk created on the Host ==> $ESXi"
  }
  Else  {
    Write-host "UserVars ToolsRamdisk record already exists in this Host ==> $ESXi. Continuing... "  -ForegroundColor DarkBlue
  }

  If ($Setting.Value -eq $false)  {

    Write-host "Tools Ramdisk is Disable in Host ==> $ESXi. Enabling setting... "  -ForegroundColor Red
    $ESXi | Get-AdvancedSetting -Name “UserVars.ToolsRamdisk” | Set-AdvancedSetting -Value “1” -Confirm:$false
    $Output+= "Tools Ramdisk was Enabled on the Host ==> $ESXi"
  }
  Else  {
    Write-host "Tools Ramdisk already Enable in Host ==> $ESXi. Continuing... "  -ForegroundColor DarkGreen
  }
}

$ThisDate = Get-Date -format dd_MM
$Path=$PSScriptRoot
$RamdiskFile = "$Path\RamdiskFile_$vCentName-$ThisDate.txt"
$Output | Out-File $RamdiskFile | Format-Table -Property * -AutoSize
Invoke-Item $RamdiskFile

Disconnect-VIServer -Server $vCenter -Force -Confirm:$false

Letztlich ist nie auszuschließen, dass das Problem vollumfänglich gelöst werden kann. Hier müssen verschiedene Teams hinter vSphere, VMware und Co. reagieren und Bugs fixen. Was wir jedoch festgestellt haben, dass verschiedene Aktionen die Problemauslösung triggern:

  • Aktualisieren von VM VMware Tools.
  • Bereitstellen der OVA/OVF-Appliance auf diesen ESXi-Hosts.
  • VMs mit meinem Veeam Tool sichern
  • Bei Verwendung von vCloud Director auf diesen ESXi-Hosts lösen die Aufgaben und Prozesse in der vCD das Problem schneller aus.

Als Überbrückung, bis der Bug seitens VMWare gefixt wurde, können wir nur empfehlen, alle ESXi Hosts mit vSphere 7 U2 neu zu installieren.

Interesse geweckt?

Unsere Expert:innen stehen Ihnen bei allen Fragen rund um Ihre IT Infrastruktur zur Seite.

Kontaktieren Sie uns gerne über das Kontaktformular und vereinbaren ein unverbindliches Beratungsgespräch mit unseren Berater:innen zur Bedarfsevaluierung. Gemeinsam optimieren wir Ihre Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!

Taunusstraße 72
55118 Mainz
info@madafa.de
+49 6131 3331612
Bürozeiten
Montag bis Donnerstag:
9:00 - 17:00 Uhr MEZ

Freitags:
9:30 - 14:00 Uhr MEZ
Wir sind Ihre SQL Expert:innen!
Noch Fragen? - Wir haben immer die passende Antwort für Sie!