Windows Server 2019 Hyper-V: "ConfigStoreRootPath" ändern

[testperson 1.682]

Hi,

 

kurze Frage, ob ich mich bl*d anstelle oder der MS Artikel (https://support.microsoft.com/en-us/help/4488568/cannot-change-configstorerootpath-of-hyper-v-cluster-after-population) ein Update benötigt. Da ich in einem Hyper-V 2019 Cluster die gleiche Fehlermeldung erhalte, gilt "This behavior is by design in Windows Server 2016." wohl auch für 2019? Oder lässt sich der Pfad unter 2019 supported und ohne Downtime des Clusters oder ohne Migration in ein neues Cluster anpassen?

 

Gruß

Jan

 

P.S.: Wir haben kein Problem allerdings sieht es echt nicht schön aus, dass da ein CSV weiterhin den alten Namen trägt. Da haben wir bei der Einrichtung der Cluster bzw. eher von Veeam leider nicht weit genug mitgedacht. :)

[NilsK 2.940]

Moin,

 

exotische Frage  - aber der Beschreibung in dem Artikel nach zu urteilen gehe ich davon aus, dass das immer noch so ist und sich auch nicht ändern wird. Dieses Detail dürfte kaum einen Major-Kunden dazu bringen, dass er Microsoft zur Korrektur auffordert, und wenn es kein solcher Kunde verlangt, wird da bei MS niemand drangehen.

 

Gruß, Nils

 

[testperson 1.682]

Hi Nils,

 

danke für die Antwort. Ich hatte halt Hoffnung, da der Artikel im Dezember 2019 aktualisiert wurde und relativ klar nur auf 2016 abzielt. :) Ein wenig Recherche ergibt, dass es zumindest 2017 noch ein Bug war: https://social.technet.microsoft.com/Forums/azure/en-US/3453b83e-c719-4bdf-a3cb-cc32c5316dfe/change-configstorerootpath-value?forum=winserverhyperv

Zitat

I opened a premier case with Microsoft and it is now closed as a bug. However, a workaround was offered as follows,

• Stop the cluster service on  ALL node
• From one node, open up the registry key
• Click on HKEY_LOCAL_MACHINE and then click on file, then select load hive
• Browse to c:\windows\cluster, and select CLUSDB
• Click ok, and then name it DB
• Expand DB, then expand Resources
• Select the GUID of Virtual Machine WMI
• Click on parameters, on (configStoreRootPath) you will find the value
• Double click on it, and delete it
• Start the cluster service
• Then start the cluster service from all nodes, node by node

In a future update we should be able to reset the value using PowerShell without shutting down the cluster, but for now this works.

 

Hier findet sich auch noch ein wenig zum Thema: https://blog.workinghardinit.work/2018/09/27/live-migration-fails-due-to-non-existent-sharedstoragepath-or-configstorerootpath/

 

Auch wenn der Anblick jedes Mal weh tut, werden wir wohl bis zur nächsten Hardwaregeneration damit leben. Strafe muss halt sein. :)

 

Gruß

Jan

[NilsK 2.940]

Moin,

 

Ist nur eine Einschätzung, die sich auf nichts Belastbares stützt. Rein nach dem Ton des Artikels würde ich aber eher keinen teuren Case dafür eröffnen, wenn ich keinen echten Schmerz damit hätte.

 

Gruß, Nils