cancel
Showing results for 
Search instead for 
Did you mean: 

BESR 2010 scheduled VMware conversion jobs fail due the numerical name change in the .v21 files

I have two physical servers, each runs on ESX4, one holds my VMGuest OS Windows 2008 R2 Fileserver/Domain Controller and the other holds my VMGuest Windows 2008 R2 Exchange 2010 Server.
I have a third server running Windows 2008 R2 Server that runs the following processes/apps:
VCenter server, VMware client and VM Host update server, Backup Exec 12.5 for tape backups and BESR 2010 server for image backups and VM Conversions.

The VM'd OS servers each also have BESR 2010 installed and configured.

Each of the physical servers are configured with their datastore exally portioned that allows either physical machine to run both VM'd OS's (FileSrv and ExchSrv) so with this in mind we are making a nightly full Image backup of each of the VM'd servers off to a storage point on the VCenter server each night and then in turn each is to be converted to ESX bootable VMDK files over to it's own opposite server physical server so that should either server encounter physical problems then both VM'd OS's would be able to run on the remaining good server as of last bood image backup.

We have made this process work previously and so it should work now.

We have found that the nightly scheduled VM Conversion which should run based solely on the .sv2i file created  each night will not run because of the numerical name change that happens to the .v2i files each night an new image backup is completed for either the FileSrv or ExchSrv VM'd guests...

Error reported in the BESR 2010 log:

Error EC8F1F48: The 'Vmware VMDK' conversion process could not be completed.
 Error EC8F1FDB: Unable to create virtual disk. This could be due to one of the following reasons:
- Destination path does not exist.
- Insufficient disk space.
- Invalid credential or permissions on destination path.
- Network errors. (UMI:V-281-3215-8008)
Details:
Source: Backup Exec System Recovery

The UMI:V-281-3215-8008 error takes me to a page where Symantec reports that they're "Working" on the problem...!

Anyone have any ideas or info?