VxRail: LCM von VxRail 7.0.520 oder 7.0.521 zeigt Fehler an: Zeitüberschreitung bei Reparatur des vSAN-Festplattenobjekts

Auf der Registerkarte Updates der VxRail LCM-Benutzeroberfläche vCenter-Plug-in wird Folgendes angezeigt: 

Error message: 
VxRail Update ran into a problem...
Failed to retrieve the existing value of the vSAN disk object repair timeout.

Auf dem VxRail Manager wird das Symbol /var/log/mystic/lcm-web.log zeigt:

2024-09-27T15:19:21.429Z <7ff91b9f32f61676bfb7758d9af41713> lcm [ERROR] <94> ComponentUpgradeService.java performComponentUpgrade() (323): Component VMWARE_ESXI upgrade failed due to Failed to retrieve the existing value of the vSAN disk object repair timeout..
2024-09-27T15:19:21.429Z <7ff91b9f32f61676bfb7758d9af41713> lcm [INFO] <94> LCMServiceImpl.java handleUpgradeException() (1812): handling upgrade exception.
2024-09-27T15:19:21.429Z <7ff91b9f32f61676bfb7758d9af41713> lcm [INFO] <94> LCMServiceImpl.java handleUpgradeException() (1817): Error from vc or node upgrade, sync the composite file
...
2024-09-27T15:19:21.467Z <7ff91b9f32f61676bfb7758d9af41713> lcm [ERROR] <94> LCMServiceImpl.java handleUpgradeException() (1855): failed to upgrade: VXRAIL_COMPOSITE-7.0.531-28777448_for_7.0.x.zip,
 with exception:
com.vce.lcm.exception.LCMInternalException: Failed to retrieve the existing value of the vSAN disk object repair timeout.
        at com.vce.lcm.core.upgrade.ComponentUpgradeService.performComponentUpgrade(ComponentUpgradeService.java:336)
        at com.vce.lcm.api.LCMServiceImpl.performBatchUpgrade(LCMServiceImpl.java:2152)
...
024-09-27T15:19:21.514Z <7ff91b9f32f61676bfb7758d9af41713> lcm [INFO] <94> VirtualApplianceUpgradeParameterStatusHandler.java notifyError() (102): Notify errors for upgrade bundle UpgradeBundleProfile{name='VXRAIL_COMPOSITE-7.0.531-28777448_for_7.0.x.zip', description='null', sizeInKBytes='15664544', bundleFileName='VXRAIL_COMPOSITE-7.0.531-28777448_for_7.0.x.zip', version='7.0.531', build='28777448', targetHardwareInfo='', targetModelInfo='com.vce.commons.vcm.state.CompositeManifestFile$TargetModelInfo@3901ec9', replaceTargetInfo='com.vce.commons.vcm.state.CompositeManifestFile$ReplaceTargetInfo@16a5c26c', targetNicModelInfo='com.vce.commons.vcm.state.CompositeManifestFile$TargetNicModelInfo@2949e0b9', removeUpgradeVIB='false', forceInstall='false', skipList='[]', upgradeTime='0', rebootFlag='false', isUpgradeComponent='false', totalEstimated='100668', totalUsed='54511', minimumVxRailVersion='7.0.010', patchType=''}, upgradeStep UPGRADE, upgradeTarget UpgradeTarget{ComponentType=VXRAIL_COMPOSITE, name='esxxxx.domain.country', isPipelineTask='false'}, action Retrieve the value of the vSAN disk object repair timeout., message Failed to retrieve the existing value of the vSAN disk object repair timeout.

Zusätzliche Fehlerdetails helfen bei der Identifizierung des betroffenen Hosts und des zusätzlichen Symptoms Too many pending operations:

2024-09-27T15:18:29.011Z <7ff91b9f32f61676bfb7758d9af41713> lcm [INFO] <374> BatchUpgrade.java updateVsanClomTimeoutValueBeforeUpgrade() (881): Obtaining the existing vSAN Clom timeout value for th
e host : esxxxx.domain.country
...
2024-09-27T15:18:33.070Z <7ff91b9f32f61676bfb7758d9af41713> lcm [WARN] <374> ScriptServiceImpl.java runLocalScript() (507): [/etc/vmware-marvin/scripts/lcm/scripts/update-vsan-clom-repair-timeout.p
y@localhost]: <stderr> Traceback (most recent call last):
  File "/usr/lib/vmware-marvin/marvind/temp/3741351928508979296.tmp", line 154, in <module>
    main()
  File "/usr/lib/vmware-marvin/marvind/temp/3741351928508979296.tmp", line 149, in main
    get_timeout_value(options)
  File "/usr/lib/vmware-marvin/marvind/temp/3741351928508979296.tmp", line 133, in get_timeout_value
    result = advanced_sys_settings.List(False, VSAN_PROPERTY)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/pyVmomi/VmomiSupport.py", line 706, in <lambda>
    self.f(*(self.args + (obj,) + args), **kwargs)
  File "/usr/lib/python3.11/site-packages/pyVmomi/VmomiSupport.py", line 512, in _InvokeMethod
    return self._stub.InvokeMethod(self, info, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/pyVmomi/ManagedMethodExecutorHelper.py", line 74, in InvokeMethod
    result = self.mme.ExecuteSoap(moid=moid,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/pyVmomi/VmomiSupport.py", line 706, in <lambda>
    self.f(*(self.args + (obj,) + args), **kwargs)
  File "/usr/lib/python3.11/site-packages/pyVmomi/VmomiSupport.py", line 512, in _InvokeMethod
    return self._stub.InvokeMethod(self, info, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/pyVmomi/SoapAdapter.py", line 1397, in InvokeMethod
    raise obj # pylint: disable-msg=E0702
    ^^^^^^^^^
pyVmomi.VmomiSupport.vmodl.fault.SystemError: (vmodl.fault.SystemError) {
   dynamicType = <unset>,
   dynamicProperty = (vmodl.DynamicProperty) [],
   msg = 'A general system error occurred: Too many outstanding operations',
   faultCause = <unset>,
   faultMessage = (vmodl.LocalizableMessage) [],
   reason = 'Too many outstanding operations'
}

Ein Codeproblem in VxRail-Version 7.0.520 und 7.0.521 verursacht esxcli Hostbefehle können im Laufe der Zeit hängen bleiben. Die Abfrage in den Protokollen gibt Folgendes zurück:

reason = 'Too many outstanding operations'

Dies führt zu einem LCM-Fehler, der Upgradeprozess kann keinen VSAN-Konfigurationswert abrufen über esxcli.
 

Eine dauerhafte Lösung für dieses Problem befindet sich in VxRail-Version 7.0.531. Versionshinweise finden Sie unter Dell VxRail 7.0.x – Versionshinweise | Dell USA (Kundenanmeldung erforderlich)

Der Nutzer muss die hostd management service auf dem ausgefallenen Node, bevor das VxRail LCM-Upgradeskript neu gestartet wird. Dadurch werden die ausstehenden Anfragen gelöscht und das Upgrade kann fortgesetzt werden.

/etc/init.d/hostd restart

Weitere Informationen zum Neustart des ESXi hostd service, beziehen Sie sich auf den Broadcom-Artikel Neustarten der Management-Agents in ESXi. 

Wenn Unterstützung beim Überprüfen der Protokolle, Identifizieren des betroffenen Hosts oder Neustarten des Service erforderlich ist, wenden Sie sich an den Dell Support.

Wenn STIG angewendet wurde, lesen Sie den Artikel VxRail: Falsche Dateiberechtigungen für einige Bibliotheken während des Upgrades auf 7.0.400 mit STIG als mögliche Ursache für diesen Fehler