For windows 2008 VMs, you need to change a parameter in the vmx of the VM.
"disk.enableuuid" should be set to "false" in the vmx file of the VM.
To do that..
1.Unregister the VM
2. Modify the paramter in the vmx file
3.register the VM back
4. Now take a backup
i have the same problem with a Windows 2008 VM using 40 GB Thin provisioned disk and the disk.EnableUUID is already set to TRUE.
It needs to be set to FALSE to work. The default value is TRUE.
i've got the same problem with all vms (suse 11, windows 2008r2, windows 2003, centos6) no matter if the flag is set or not
Hello, we see the same problem with Windows 2008 R2 and Windows 2012 in our test lab. There is a new KB 2035736 (http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035736) describing this bug, which recommends disk.EnableUUID=false as a workaround.
However, I thing that setting disk.EnableUUID to "false" is NOT an adequate workaround! If I'm right, by disabling disk UUIDs you turn off application consistent VSS snapshots, which might be an issue if you require application consistent backups. For example, we cannot consider VDP as a production-ready backup solution without it.
Does somebody know if VMware works on a fix of this bug?
Correct me if I'm wrong, but I believe you can still get an application consistent backup with disk.enableUUID set to 'false'. The Windows 2008 SDK has an executable called vshadow.exe (one for 64bit, one for 32bit versions) that can be called from a freeze script in the backupscripts.d folder in your VMware Tools folder. This will make Windows initiate Microsoft's VSS and freeze I/O while a snapshot is made instead of VMware's. I went around in circles with this back when I was a vRanger user and they had horrible documentation. No one with VMware or Quest Software could tell me how to make it work and I figured this out on my own.
Here's a link to my blog post on how I fixed it in vRanger. The steps should be about the same in this scenario except you don't need to delete the disk.enableUUID line from the VM config. If this helps I may write another blog post on how to do this for VDP. http://www.bluemunkey.com/?p=106
I've tested this on two of my VMs and it's working. Event logs tell me MS SQL is freezing I/O and I can see the VSS agent start and stop. It also tells me that a backup has been competed and transaction logs are being truncated for the SQL server.
I wonder when VMware and backup software developers are going to figure this out and just include this in their documentation. disk.enableUUID = true has rarely worked for me and usually after an upgrade of either vSphere or 3rd party backup software everything breaks.
I'll probably be writing a tutorial on this tonight or tomorrow. I will post it here.
Hi slusamson, thanks for the tip, it looks like a possible workaround. However, as we don't need urgent upgrade to vSphere 5.1 and VDP, I'll wait for official fix from VMware. I hope that this issue has a decently high priority for VMware because Win2008 R2 is probably the most frequent server version of Windows today.
Here's a post on a fully functional workaround if anyone needs it. http://www.bluemunkey.com/?p=338
I'm not holding my breath that VMware will fix this. I've had issues with this since 2010 under vSphere 4.1 with 3rd party software (vRanger Pro).
I do think I figured out what broke my backups in the process of all of this. I'm pretty sure that upgrading the VM version to the latest for 5.1 changed the setting for "disk.enableUUID" back to "true".
I will probably stay with VDP as the deduplication is pretty awesome so far.
I can confirm that this work around is great. Aquiesce and SQL backups work fine with the freeze script.
Still find it fairly astounding that this bug/feature is still here in 5.1...
If you stop and then disabled the VMware Snapshot Provider the backup will work. It should use the Microsoft VSS. We noticed this when one of our Server08R2 servers didnt have the VMware Snapshot Provider installed and it was being backed up. We also confirmed that even if it is installed VMware does not show up as a VSS Writer.
Again, stop and disable the VMware Snapshot Provider or choose not to install, and the backup should work.
I would be careful disabling that service. Someone may correct me if I'm wrong, but I believe disabling the VMware Snapshot Provider service will prevent VSS from running when a snapshot is made. This essentially the same as setting disk.enableUUID to false. As a result, quiescing will be disabled and you will not have an application-consistient backup of the VM.
I know in vSphere 4.1 there was an issue where this service was not installed correctly when VMware Tools was installed. The fix was to uninstall the service by modifying the VMware Tools install and then reinstalling it. I never could get that to work and ended up back on the fix I wrote about on my blog.
I tried disabling the service and running a backup job on a VM that I had not done the freeze script fix on and it does indeed let the job run and complete with no errors, but the Windows event logs don't show any VSS activity. I added the freeze script and now it does.
Whichever method you use, a freeze script that kicks off VSS will be necessary to get an application-consistent backup. If that is not a requirement, then LMHSysAdmins' fix will save a bunch of time, as well as a VM reboot and allow a file-system consistient backup.
We opted to use the method by slusamson only we did not change the disk.enableUUID to false. We only disabled the VMware Snapshot Provider and then applied the backup script according to the blog. After a VDP backup we were able to see the I/O freeze and the application events where it decleared a database as backed up.
By only disabling the VMWare snap service and applying the scripts this would save a reboot of the VM, and can be completed in uptime.
Good work slusamson on writing this up.
I think I'm missing something more basic, I can't get VDP to backup any VM regardless of the OS. I always get the E10055 error at about the same time, either 14% or 16%. I've tried the disk.Enableuuid-false tried disabling the service but same error. If I watch in the vsphere client console window I can see the snapshot being taken and deleted but then it errors out. Do I need to give vCenter access to the the volumes containing the VMs? Currently only my ESX hosts have access to those volumes. Any thoughts? Haven't seen anything helpful in this regard in the admin guide