Host-based backup of Microsoft Hyper-V VMs.
alpha39
Lurker
Posts: 1
Liked: never
Joined: Jan 28, 2016 12:00 am
Full Name: alpha39
Contact:

Re: Win 2012 R2 Cluster Failed VSS_WS_FAILED_AT_PREPARE_SNAP

Post by alpha39 »

I have found a potential solution for this that worked on two different Hyper-V VMs.

Both Server 2008 + Exchange 2010.

Restart services in this order (order seems to be important for some reason):
1. Com+ Event System
2. Hyper-V Volume Shadow Copy Requestor
3. Volume Shadow Copy

Then rerun Veeam application aware backup.

Whether this fix lasts or not, I'm not sure since they are just running for the first time correctly right now. If it breaks again after some time I'll just make a script to execute those steps right before the Veeam backup runs.

Hope this helps someone, been banging my head on this one for awhile.
Shralok
Enthusiast
Posts: 51
Liked: 5 times
Joined: Aug 29, 2012 5:36 pm
Full Name: Shralok
Contact:

Re: Win 2012 R2 Cluster Failed VSS_WS_FAILED_AT_PREPARE_SNAP

Post by Shralok »

Due to all of our issues with Veeam + Hyper-V + NetApp we had opened a support case with both Veeam and NetApp. This was the outcome, paraphrased from the Veeam engineer I worked with:

"NetApp HW provider doesn't allow concurrent snapshot creation within HV cluster, even when snapshots are initiated on different hosts and for different CSVs.
What it means is that you can have only one snapshot operation running within cluster at once - and there is no concurrency.
NetApp documentation mentions only 2 VSS snapshot creations within a single host. What it should say is that with NetApp HW provider you can run only one snapshot creation per whole cluster.
Basically this limitation means no scalability, and if HV infrastructure is huge (lots of hosts in the cluster and CSVs) this limitation becomes rather extreme and there is no real use for NetApp hardware VSS provider."

We've since moved back to the "Microsoft CSV Shadow Copy Provider" and have not had a single error.
threesixty
Lurker
Posts: 1
Liked: 1 time
Joined: Apr 07, 2011 9:38 am
Full Name: threesixty Services
Contact:

Re: Win 2012 R2 Cluster Failed VSS_WS_FAILED_AT_PREPARE_SNAP

Post by threesixty » 1 person likes this post

Just a quick post with an update which hopefully might help someone experiencing the same issue.

We had been experiencing the VSS_WS_FAILED_AT_PREPARE_SNAPSHOT error on our new Exchange 2016 VM running on Server 2012 R2 on a 2012 R2 Hyper-V failover cluster. Whenever the job was run with application aware processing enabled it would fail, running without the option would succeed each time but without obviously the truncation of the logs, which we needed.

Initially we though we just needed to be on the latest copy of Veeam 9.5 to support Exchange 2016, but even after upgrading we still had the same issue. We have several other VMs being backed up successfully on the same cluster including a 2012 R2 server which had SQL server installed and application aware processing enabled.

Having read through many of the previous posts in this and other threads we came across a rather strange fix which worked in our scenario.

Our VM had multiple VHDX files stored on different LUNs, the primary LUN where the machines' OS drive and the config was stored had a folder structure Share-Name\VM-Name\Virtual Hard Disks\VHDX_file

After checking through the event logs logs on the host which held the VM there was a Hyper-V-VMMS Event ID 16370 entry with the following message...

'VM-Name' cannot create the storage required for the checkpoint using disk C:\ClusterStorage\Share-Name\VM-Name_D.vhdx: General access denied error (0x80070005). (Virtual machine ID XXXXX)

It seemed odd that the message would reference the file relating to the D drive of the VM rather than the primary OS drive which was on a different LUN. The one thing we did notice was that the VHDX file was actually placed in the root of the share since it was the only item on the LUN. Checking our other VMs none of the other VHDX files were in the root of any of our LUNS.

For us the fix was to create a folder (in our case called Virtual Hard Disks) on the share and store the VHDX file within the folder. Low and behold after doing that the job ran successfully with application aware processing enabled.

So for those who may find this page, if you are running a Hyper-V CSV and you have multiple LUNs for different drives on the VM, might be worth checking if any of those VHDX files have been dumped in the root of the shared folder.
Post Reply

Who is online

Users browsing this forum: No registered users and 21 guests