How can I change the ConfigStoreRootPath in a Hyper-V Failover Cluster?

[sarnold]

We have an existing Windows Server 2019 Failover Cluster with 3 nodes and a SAN. The SAN is getting quite old (6 years in production) and we're preparing to replace it with an all flash SAN. We'll add the SAN as a new iSCSI disk, then add this disk as a new Cluster Shared Volume (CSV). Once everything has moved off the old SAN CSV to the new SAN CSV, we'll remove the previous SAN from the Cluster (remove the old CSV) and remove the old SAN iSCSI connections from the host. We're then going to evict one node at a time and add in a new Windows Server 2022 server (since we can have OSs one major release apart in the same cluster) and once all 3 are replaced, we'll be fully upgraded with no downtime.

However...one massive potential problem I'm now reading about is with the ConfigStoreRootPath. We had previously set this years ago so that Veeam can perform backups. It's been working ever since. However, the path for this is on the current SAN. This seems like a massive problem because apparently the ConfigStoreRootPath cannot be changed once it's set.

If I'm understanding this correctly, is my only option to migrate all of the VM storage over to the new flash SAN, and have this massive 20ish TB old rotational disk SAN just sitting in the rack for 128KB of meta data that can't be moved? There HAS to be a better way...please tell me someone's moved this before successfully without entirely rebuilding their cluster...

[Mildur]

Hi Sarnold

I'm not sure if there is a supported way. Microsoft themselves are telling us "It's not possible".
Veeam also provides this information in our KB: https://www.veeam.com/kb2194

But I found a really old topic with workarounds. No guarantee that it will work.
Please note, Veeam's customer support cannot provide technical support for third party products like HyperV and especially not issues related to unsupported changes.

Best,
Fabian

[sarnold]

For anyone who finds this down the road, what I ended up doing is rather silly, but it worked. This is the *very* rough steps I took in order to essentially give the same CSV name to the new SAN:

•Started with all VMs on original SAN with a CSV of CSVOriginalName
•Added the new SAN and created a volume using half the available space and attached it to the cluster as CSVTempName
•Moved the VM storage (live) from CSVOriginalName to CSVTempName
•Copied the metadata directory from CSVOriginalName to CSVTempName (the directory that the ConfigStoreRootPath is looking for)
•Removed CSVOriginalName from the cluster and decommissioned the original SAN

At this point, the original CSV name is freed up and it can be assigned and added to the cluster.

•Created a second volume on the new SAN using the other half of the available space and called it CSVOriginalName
•Moved the VM storage (live) from CSVTempName to CSVOriginalName
•Copied the metadata directory from CSVTempName to CSVOriginalName
•Removed CSVTempName from the cluster and deleted the volume
•Extended the remaining CSVOriginalName volume to the required size now that the CSVTempName volume is gone

That brought us to having the exact same name and path of the CSV, but on the new SAN, and the value of the ConfigStoreRootPath never had to change. This method only worked because we had additional space to work with on the new SAN since it was significantly larger than the old one. Otherwise there'd be constant shuffling of volume sizes between the two volumes as you went.

I hope this helps someone!