Backup & Recovery

I have crate Backup Job in vSphere Data Protection

1 VM ... Server 2008 R2 ... 1 thin virtual Disk 40GB ... the Backup Job fails with Error message ->

E10055:failed to attach disk

Anybody same Problem or Idea ?

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

Hi,

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.

anyone?

It needs to be set to FALSE to work.  The default value is TRUE.

Thanks

//Magnus

Dear snekkalapudi,

     i have the same problem by vdp backup the vm, could you help ?

  I backup all the windows(win2k3,win2k8) vm ,have the same problem "E10055,failed to attach disk" ,

and i have try by your solution ,but not yet !

Eagle

Hi tried the referenced blog method, modified, using diskshadow, but it doesn't look like my freeze file is getting called - or at least running succesfully, though it runs when I kick it off manually. I read the article here: http://blogs.vmware.com/vsphere/2013/02/vmware-announces-vdpa.html. Sucks cause it probably means we'll never get application consistent backups in VDP :smileysad:. I'm running a farily up to date 5.1 ESXi Essentials Plus. Do you think they may have broken the feature that calls freeze to force us towards VADP? Just checking, I don't need to modify the VDP bakup job created with the wizard right? Expectation is that freeze will be called if it's present?

contents of C:\Program Files\VMware\VMware Tools\backupscripts.d\freeze.bat:

del *.cab -- delete yesterday's snapshot
C:\Windows\System32\diskshadow -s c:\shadowScript.txt

contents of c:\shadowScript.txt

add volume c:
add volume f:

create

got the diskshadow scripts working. Key was not having anything else in the backupscripts.d folder, which is burried down at the bottom of that KB.

jb

##freeze.bat##
del c:\windows\metadata\backup.cab
C:\Windows\System32\diskshadow -s c:\windows\shadowScript.txt

date /t >> c:\windows\metadata\callme.txt
time /t >> c:\windows\metadata\callme.txt

##shadowScript.txt##
delete shadows all
reset
set context persistent

add volume c: alias new1
add volume g: alias new2
set metadata c:\windows\metadata\backup.cab

create

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?

Thanks

Martin

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.

Thanks,

Martin

No problem.

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

Thanks!

Sorry....I am getting a little confused.....

1. I went to the KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035736 but I could not find where the disk.EnableUUId parameter was.

2. And is this bug only for Win 2008 R2 ? Nobody faced this on Win7 and/or Windows 2003 64bit ?

- If this was the case, maybe some of my other VMs have otehr issues as well.

- I kinda cheapo to run Acronis and other "application servers" on Win7

3. Are there any "official" workarounds that can be done without powering down the VMs ?

4. Are there any "official" workarounds that can be done when VMs ar powered up, but later rebooted ?

5. Is there anyway to test which VMs are affected ? I really do not wish to test by running backup on every VM right now....

You will have to shutdown the VM to that.

1. Shutdown the VM

2. Right click and Edit Setting

3. Select Options tab

4. Select General under Advanced & you can see "Configure parameters" button enabled.

5. Click the button and set the parameter

I found the settings only in the Powered down VMs running Win2008R2.

Can this be done on Power Up VMs and only reboot later ? it is impossible to predict when I will be able to shutdown some of the servers....

Thanks...darn.....Back to using non VDP then....

I mean..

You can set the parameter by editing the vmx file on a powered ON VM but the setting will take effect only after a reboot

Hmmmm...thats sounds like a probably idea...

I'll go read up on how to edit vmx file...

thanks

It should also become effective after migrating a VM to a different host, because it will unregister and then register the vmx on the new host.

This way you should be able to the change without a reboot.

Well, the Windows 2008 R2 "failed to attach disk" problem seems to be  finally fixed in VDP 5.1.10 according to KB 2035736. Quickly tested in our lab  and backups no longer fail. Hopefully they are also VSS  application-consistent ;-) Thank you, VMware.

Do we need to change the parameter back to true in the config-file to get proper backups?