Since our VM farm was upgraded to ESXi 5.1.0 backups of Win2K8-R2 VMs have been failing with the following error:
2012-11-14 21:03:30 avvcbimage Error <12015>: Failed to connect to virtual disk VMNAME/VMNAME.vmdk (13) (13) You do not have access rights to this file (Log #1) 2012-11-14 21:03:30 avvcbimage Error <9767>: VixDiskLib_Open( VMNAME/VMNAME.vmdk) returned (13) You do not have access rights to this file (Log #1) 2012-11-14 21:03:35 avvcbimage Error <9768>: Avtar exited with 'code 163: externally cancelled' (Log #1)
However, that solution, setting "disk.EnableUUID" to FALSE and the associated process (shutting down the VM), is unacceptable. It's my impression that this leads to an file-based quiesced snapshot rather than application-based. Since I have quite a few mission-critical systems running, for which obtaining downtimes would be onerous, has a more reasonable solution been proposed or does the 5.1.0a update address the issue (it's not explicitly mentioned)?
In other words, has anyone else encountered this issue and found a reasonable solution?! TIA!
While we wait for a VMWARE solution (no laughing) we opted to disable the VM VSS Snapshot Provider service on systems on which it was installed. That was the only non-disruptive solution we could find, since it forces Avamar to instead use the Microsoft VSS provider. This seems to work just fine, though you should definately test your restores.
I would strongly recommend adding the quiesce_fs flag to the dataset as J.H. describes above rather than setting it using the avvcbimage.cmd flag file. The flag files always override the dataset. What if the default behaviour changes in a later release? It's a lot easier to change the dataset than it is to update or re-deploy every proxy.
Also, there is no need to reset or re-register the proxy (or any client) after changing the flag files. Flag files are loaded and processed at backup runtime.
cpmp
13 Posts
647
0
Posted May 20th, 2013 10:00
While we wait for a VMWARE solution (no laughing) we opted to disable the VM VSS Snapshot Provider service on systems on which it was installed. That was the only non-disruptive solution we could find, since it forces Avamar to instead use the Microsoft VSS provider. This seems to work just fine, though you should definately test your restores.