
Error “The cluster group could not be found” in Virtual Machine Manager
VIRTUAL MACHINE MANAGER TweetIn diesem Artikel wird beschrieben, wie eine Failed VM in Virtual Machine Manager repariert werden kann. Dieses Troubleshooting, auch als “Notes from the field” bekannt, sollte auch aufzeigen wie ein Problem in VMM analysiert werden kann… Zur Situation: Bei einer von VMM verwaltete Virtual Machine wurde jeder Job / jede Änderung abgebrochen.
Eine solche Situation kann zum Beispiel dann vorkommen, wenn eine clustered VM (HAVM) in Hyper-V exportiert und auf einem anderen Cluster Node wieder importiert wird. Beim erneuten Hinzufügen in den Failover Cluster wird allerdings automatisch eine neue ID erstellt. Wird VMM bei einer solchen Aktion ausgelassen, kommt die #CLUSTER-INVARIANT# Information zum Zug, darüber kann VMM eine bekannte VM eindeutig zuweisen. Leider funktioniert dies bei Export / Import (noch) nicht…
Im Job-Log wurde folgende Fehlermeldung ausgegeben:
Error (12711)
VMM cannot complete the WMI operation on server MyDamagedVM.intra.server-talk.eu because of error: [MSCluster_ResourceGroup.Name=”dced5bf8-493b-49b7-8295-ee079d008b1f”] The cluster group could not be found.
(The cluster group could not be found (0x1395))Recommended Action
Resolve the issue and then try the operation again.
Die Virtual Machine wird in Virtual Machine Manager mit dem Status Failed dargestellt. Ist die VM gestartet, läuft diese zwar uneingeschränkt weiter, allerdings könne in VMM keine Aktionen mehr ausgeführt werden, selbst die Funktion “Repair” schlägt fehl…
Da VMM sämtliche Informationen in einer SQL Database speichert, kann es vorkommen dass ein Attribut (noch) nicht aktualisiert wurde. Mit einem “Refresh virtual machine configuration” in der Failover Cluster Console können viele Probleme adressiert werden. Dies wäre auch die bevorzugte Lösung für ein solches Problem. In PowerShell sieht das entsprechende cmdlet wie folgt aus:
PS> Import-Module FailoverClusters
PS> Get-ClusterResource -c "hst-hyperv" | where {$_.ResourceType.Name -eq "SCVMM MyDamagedVM Configuration"} | Update-ClusterVirtualMachineConfiguration
Das Problem lässt sich allerdings nicht mit einem Refresh lösen, der fehlerhafte Status bleibt. Um einen Fehler in VMM zu analysieren sammelt man sogenannte “Traces”. Kollege Jonathan Jordan im Artikel “SVMM Tracing made easy!” auf seinem Blog beschrieben.
00005619 44.84210205 [2344] 0928.09D8::08/13-14:15:53.110#04:WsmanAPIWrapper.cs(968): WSMAN: URL: [http://hst-hyperv03.intra.server-talk.eu:80] Verb: [GET], resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/mscluster/MSCluster_ResourceGroup?Name=dced5bf8-493b-49b7-8295-ee079d008b1f]
00005620 44.84257126 [2344] 0928.09D8::08/13-14:15:53.110#04:WsmanAPIWrapper.cs(544): HostSessionCache: elements for [S-1-5-21-560624862-1488677923-1988559177-2101-hst-hyperv03.intra.server-talk.eu]: [100]
00005621 44.88131332 [2344] 0928.09D8::08/13-14:15:53.157#04:ResourceGroup.cs(141): MSCluster_ResourceGroup Get http://schemas.microsoft.com/wbem/wsman/1/wmi/root/mscluster/MSCluster_ResourceGroup?Name=dced5bf8-493b-49b7-8295-ee079d008b1f failed : [5013]
00005622 44.88223267 [2344] 0928.09D8::08/13-14:15:53.157#04:ResourceGroup.cs(141): Microsoft.Carmine.WSManWrappers.WSManException: VMM cannot complete the WMI operation on server hst-hyperv03.intra.server-talk.eu because of error: [MSCluster_ResourceGroup.Name=”dced5bf8-493b-49b7-8295-ee079d008b1f”] The cluster group could not be found.
00005623 44.88223267 [2344]
00005624 44.88223267 [2344] Resolve the issue and then try the operation again.
Den Traces zufolge können keine vorgängigen Probleme oder Fehler entnommen werden, welche detaillierter Aufschluss zur Ursache geben könnten. Das heisst, entweder besteht effektiv ein Problem mit der Virtual Machine Cluster Resource, oder die VMM Database hat ein Problem. Wie kann man dieses Problem nun also lösen?
VMM Database
Da VMM eine SQL Database nutzt, können Attribute auch manuell angepasst werden. Dazu muss allerdings der VMM Server gestoppt werden indem der Service “Virtual Machine Manager” gestoppt wird, um Inkonsistenz der Datenbank zu vermeiden. Dafür kann zum Beispiel ein Command Prompt als Administrator geöffnet und “net stop VMMService” ausgeführt werden. Um den Status der VM wieder zurückzusetzen, kann im SQL Server Management Studio folgendes SQL Query abgesetzt werden. Wichtig!! Änderungen an der VMM Datenbank erfolgen auch eigenes Risiko. Es sollte immer ein funktionierendes Backup existieren, respektive vor der Änderung erstellt werden.
UPDATE VirtualManagerDB.dbo.tbl_WLC_VObject SET ObjectState = '0' WHERE ObjectState = '107'
oder
UPDATE VirtualManagerDB.dbo.tbl_WLC_VObject SET ObjectState = '0' WHERE Name = 'MyDamagedVM'
Danach kann der VMM Service wieder gestartet werden. Die VM wird nun wieder als “Running” dargestellt. Doch hält dieser Status auch was er darstellt?
Nein… Dieser Zustand ist nur von kurzer Dauer, nach dem nächsten Update wird der Status wieder auf “Failed” geändert. Also “zurück auf Feld 1”.
Virtual Machine Cluster Resource Group
Es scheint als ob VMM doch Recht hat und ein Problem mit dem Cluster Resource Group Name besteht. Daher sollte mal die ID der HAVM von der Cluster Konfiguration mit dem Wert der VMM Datenbank verglichen werden. Die Informationen vom Cluster werden in der Registry jedes Nodes gespeichert. Im Hive “HKLM\Cluster\Groups\” gibt es eine ID für jede Resource. Für die FailedVM in diesem Beispiel sieht dies dann wie folg aus
Key: HKLM\Cluster\Groups\dced5bf8-493b-49b7-8295-ee079d008b1f
In der VMM Datenbank wird diese Information in der Tabelle “tbl_WLC_VMInstance” unter “VMResourceGroupID” festgehalten. Vergleicht man die beiden ID’s sieht man, dass diese Werte unterschiedlich sind.
Dies zeigt der falsche Wert welcher in der SQL Datenbank gespeichert ist ('dced5bf8-493b-49b7-8295-ee079d008b1f'
):
im Vergleich zum korrekten Wert in der Failover Cluster Konfiguration ('8627d3b2-09a7-4338-ad0a-bb4bb3e1fbe2'
):
Um diesen “MSCluster_ResourceGroup.Name” anzupassen, kann im SQL Server Management Studio (mit gestoppten VMM Server) folgendes SQL Query abgesetzt werden:
UPDATE VirtualManagerDB.dbo.tbl_WLC_VMInstance SET VMResourceGroupID = '8627d3b2-09a7-4338-ad0a-bb4bb3e1fbe2' WHERE VMResourceGroupID = 'dced5bf8-493b-49b7-8295-ee079d008b1f'
Mit dem SQL Query wurde der Fehler in der VMM Datenbank behoben:
Nachdem der VMM Service wieder gestartet wurde, wird die VM unter Umstände noch immer als Failed dargestellt. Mit der richtigen Cluster Resource Group Funktioniert nun aber die “Repair” Funktion.
Weitere Informationen
- Microsoft TechNet: Backing Up and Restoring the VMM Database
- Microsoft TechNet: Update-ClusterVirtualMachineConfiguration
- English Version as PDF: Error “The cluster group could not be found” in Virtual Machine Manager
- TechNet Blog: Issues with migrating a Virtual Machine from one cluster to another
Shortlink: https://www.server-talk.eu/?p=2352