Guest Cluster Backups Clarity- VHDSet Disks - ConfigStoreRootPath

[GSLJake]

Dear All,

I've been building and backing up HyperV and VMWare Clusters with Veeam for a good few years now, and one of my favourite configs grew a problem since Microsoft Changed Shared Disks post Server 2016. I've read a lot online about the problems backing up Guest Clusters with Veeam, and the KB's that resolved the issue, and reading that people seemed to still have the issue outstanding, and that so many users seeming to misunderstand the problem (this included myself) . Having also chatted with Veeam support who also needed time (thanks very much!! Veeam support IS GREAT!!! )

I felt that it was worthy of explanation maybe helping others.

The problem is compounded by misconceptions and misunderstandings. So working with Veeam 12 -

1) - Snapshotting a HyperV VM that is using shared disks gives an error. And the Error can vary!
--This DOES NOT mean that snapshotting VHDSets is not supported (as several people have said)- it means there is no current provision through the GUI for HyperV Collections or HyperV Group Management.

Group Management is required to snapshot machines that share common VHDSets. This functionality is built into Veeam. There is no need to fix this issue at the Cluster or Hypervisor level.

2) The KB's from Veeam aren't quite accurate enough in their explanation of the problem to give you the understanding of what's going on. For instance if you forget to elevate the commands in powershell, they will just fail, giving warnings that make you think the commands won't work. And - moreso - the folder naming of the solution isn't the way an engineer would do it IMHO.

3) Using web resources to try and fix the problem leads you to the KB's but also other Microsoft articles that lead you to a merry dance.

4) Some may think you need to set the value in the guest cluster - you don't. This value is set on one of your Main cluster nodes and counts for Cluster member nodes.

5) You don't need to alter the commands - so much as correct to the best approach.

So ______________

Veeam can backup VHDSets, To do this it needs to be able to create a HyperV Collection to backup the the shared resources. It cannot do this in a standard configuration because when most people build a cluster they do not set a value that needs to be seen by both cluster nodes so it can create snapshots that span the nodes. As they should because you'd want your cluster availability to spread through to your guest cluster availability.

In one of your Cluster Shared Volumes, an area seen through the mount points by all nodes create a folder. I'd personally call this folder ConfigStoreRootPath - which is the name of the variable. If you do this - you will KNOW in the future and so will others that this is an important location for function.

Elevate Powershell run as admin and type in the command

Code: Select all

Get-ClusterResource "Virtual Machine Cluster WMI" | Get-ClusterParameter ConfigStoreRootPath

This will show that the ConfigStoreRootPath is not set or is set incorrectly. In my case the value was missing. We need to create or correct it.

Then Type

Code: Select all

$path = "C:\ClusterStorage\Volume1\ConfigStoreRootPath" 

This would be correct for anyone who has been sensible and created a folder in the first CSV mountpoint for Volume 1 as I mentioned about. If you need to use a different locations make sure its on a CSV and can be seen by all the nodes. Working as a Domain Admin did not give me any permissions errors although I had to OK UAC to create the folder in the root of the CSV.

Then Type Still as admin

Code: Select all

Get-ClusterResource "Virtual Machine Cluster WMI" | Set-ClusterParameter -Name ConfigStoreRootPath -Value $path

This sets the path of ConfigStoreRootPath to the value you gave to the $Path String. Namely its folder location.

Then Run the first command again - and wham you can see the variable has been set.

Now - when Veeam goes to setup the HyperV Collection for which it needs to create the snapshots - it will have the location to store the information required.

This is well slack on Microsofts Part. Not to be able to see the groups or collections at GUI level is just poor. HyperV is so powerful and reliable and "free" I don't consider VMware anymore I am afraid, and when you ad KVM etc to the mix ... anyway...I hope this helps someone! I wish I'd have had this info.

[Mildur]

Hello Jake

Thank you for this summary.
And thank you for the nice feedback. I will share it with support management

2) The KB's from Veeam aren't quite accurate enough in their explanation of the problem to give you the understanding of what's going on. For instance if you forget to elevate the commands in powershell, they will just fail, giving warnings that make you think the commands won't work. And - moreso - the folder naming of the solution isn't the way an engineer would do it IMHO.

Could you maybe share which kb is missing explanation? Or did you have already used the feedback button on the kb article to share this feedback with our KB team?

Best,
Fabian