cat-scvmm

Error “The cluster group could not be found” in Virtual Machine Manager

VIRTUAL MACHINE MANAGER

In 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

Failover Cluster , Hyper-V , SCVMM

, , , , ,

About the Author

Michel Luescher is a solution architect in the worldwide Datacenter & Cloud Infrastructure Center of Excellence (CoE) at Microsoft Corporation based out of Zurich, Switzerland. Primarily, Michel is focused on hybrid cloud solutions (Hyper-V, System Center and Microsoft Azure). In addition Michel is speaker, blogger and author of several books.

Leave a Reply.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Prozessoren und deren Herausforderungen mit Hyper-V Windows Failover Cluster mit VMware