So Veeam failed me big time (2016/19 Cluster, backing up 2012R VM cluster)

[spgsit5upport]

I had it all working perfectly fine when using 2012R2 HV hosts and VM cluster running 2012R2
OK, perfectly is a big word, it kind of got there towards end of life (of my hardware) when MS eventually managed (with the the fixes) to get Cluster working without hiccups
But even then Cluster Aware Updating was a no go, as I could never get the timings right, so it would actually work (most of the time Veeam kept some VM locked, so could not be moved, hence the whole thing was failing)
Never bothered to adjust it fully, done updates by hand (only 2 hosts, so no issue)

Once I had to swap the hardware, I decided to go with newest shining 2019. Surprise, no direct update path, needs to go via 2016

So introduced 2016 host, moved all VMs to it, removed 2012R2 hosts, upgraded ClusterFuncional Level, at which point I could add 2019 host

So now I have half finished cluster (due to other issues, that I am waiting for resolution)

But in a meantime, I changed shared disks on my VM clusters from vhdx to required vhds

Only to find that it all that makes ZERO difference, as Veeam cannot deal with it anyway (at least till guest VM cluster is still on 2012R2)
Which I simply cannot understand, we backup from OUTSIDE and not inside of the guest

Had a really awfully dealt with case open (03383024), all for nothing.

So all in all less than happy, as it stands I cannot have these VMs backed up, hence I needed to "invent" a different strategy

Seb

[nmdange]

Only to find that it all that makes ZERO difference, as Veeam cannot deal with it anyway (at least till guest VM cluster is still on 2012R2)

Unfortunately this is actually a limitation in Hyper-V, so isn't specific to Veeam. Backing up guest cluster with VHD Sets requires the guest OS to be on 2016.

[Rick.Vanover]

Hey Seb - sorry to hear that you are having a rough go. Of course not to override the support case, but it may be worth considering the agents for the guests.

[spgsit5upport]

Sure, worth considering different software all together!

If Veeam so so dependent on OS in what it can actually do (read: be useful at all for its main purpose - BACKUP), then it is no longer my first choice for "backup", sorry!

[csydas]

If Veeam so so dependent on OS in what it can actually do (read: be useful at all for its main purpose - BACKUP), then it is no longer my first choice for "backup", sorry!

I mean, that's not exactly fair -- MS has some very goofy restrictions based on their personal desire to move customers to easily supported configurations. HyperV has always been a pain with version compatibility, and with 2016+ this has only gotten worse. I'd be amazed if Windows Server Backup was able to do this at the image level.

Hyper V isn't VMware; the guests are exposed far more to the host with the Shadow Copy process, and that means that versions matter. Like, it's really bad that you're stuck in a bum situation like this, but this is how Microsoft requires it to be done.

[Mike Resseler]

Seb,
Sorry to read that we are not longer the first choice for backup. But please note that to be able to use the native backup API integration of Hyper-V 2016 everything has to be at the right level. Otherwise we would need to revert back to the old method of protecting VMs which means injecting our own driver on the host (something that MSFT never liked but used to be the only option). Now they have a mechanism that they support, but the building blocks need to be in place. And that is something which is not only for Veeam...

[spgsit5upport]

Which is exactly what is totally mad. You are at mercy of MS to bugger things as they please.

But what was worse was the fact that your support did not have a clue!

[Mike Resseler]

Seb,
Unfortunately the way hypervisor backups (and now cloud backups) is through official API's and SDK's. This is with VMware, Hyper-V, Azure, AWS, ... So we need to work with those for support and for many other reasons.

Concerning your support case. I started reviewing it, and will continue the next days and will discuss this with support management. At Veeam, support is something which we consider one of the best in the industry. We have received numerous awards for it, and our scores are always high. But mistakes can happen, and things can go wrong. By telling us that you are not happy with it (and specifically, why not and what went wrong) can make us better. This is not a standard marketing message, we actually discuss these with the management each time over and over again. Otherwise I doubt we would become so big in 10+ years.

Obviously, that doesn't make you happy and I apologize for it.

[Gostev]

Which is exactly what is totally mad. You are at mercy of MS to bugger things as they please.

If you are so unhappy with platform-specific limitations of host-based backup, why not just switch to agent-based backup? This one is not dependent on the underlying platform in any way, and is available directly in Veeam Backup & Replication.

[Mike Resseler]

Hi Seb,
As promised. We looked into the support case.
First: I know you think we shouldn't do it but we have no choice of using the API's and SDK's of Microsoft. The guest operating system should be Windows 2016. So this is a limitation of the hypervisor platform.

Second: We are aware this is known, and we apologize that support didn't provide you with the documentation to point this out, as they should have done. And as you already see above (response by Gostev) support should have also given you the alternative (agents) for overcoming such platform limitations.

Our agent backups can handle this situation. By the way, this is also one of our benefits of the newly introduced instance licensing which allows you to use your current licensing to move it to either VMs or agents depending on the needs of your hypervisor. Whatever you need to use at any given moment, the instance licensing allows you to do this.

Again, our apologies for the items that went wrong. I hope you consider using the agents to solve your problem

Thanks
Mike