Restoring VM using transport type=SAN - missing operating system

[schrammd]

Several issues I'm noticing. Environment 7.5.0.4 on Win 2008R2 X64. vCenter 4.1, ESX running 4.0. Account used for backups has all required permissions/role to restore.

VMs back up @175MB/sec to disk. Restores run about 15MB/sec, not hitting the LAN, but SAN to SAN. I don't understand this at all. But, after restoring and getting a status 0, the VM has no bootable OS. Found this link http://www.symantec.com/docs/TECH173567 but it references BackuExec, which we are not running obviously, and I also get floods of "clear lazy zero" messages in the console. There is no way to select "none" for the vCenter server either, so it appears you cannot bypass and go direct to the ESX.

Now, if the issue really is with the API, WTH hasn't VMware fixed it YET? It seems ridiculous to expect us to restore 100GB VMs over the LAN via the vCenter machine. I tried this wit 7.5.0.3 before putting .4 on it, made no diff.

It appears those clear lazy zero messages, and the work involved tracking it, really bogs the vCenter server down too. Simply floods the event log. I've tried telling it to do thin provisioning as well as "orginal", neither get me an OS after a "successful" restore.

[RLeon]

This part from the Nbu VM guide might be relevant; the option can be found in one of the steps in the VM restore menu:

Thick Provision Eager Zeroed
Configures the restored virtual disks in the thick format. Restores the populated
blocks and immediately initializes vacant blocks with zeros (eager zeroed).
Creation of the virtual disks may take more time with this option. However, if
the restore occurs over a SAN, the eager zeroed feature may speed up the
restore by reducing network communication with the vCenter server.

Another one about SAN restore speed problem:

For the SAN transport mode, the job may be slow when you restore to a vCenter Server.
For greater speed, designate a VMware restore ESX server as the
destination for the restore.
A restore by means of the SAN transport mode may be slow in other circumstances.
The following VMware article provides details:
"Best practices when using SAN transport for backup and restore":
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1035096

If you follow the link, you will find that it is also saying that you can solve many problems if you stick to NBD mode for restores, instead of SAN mode.
A VMware thing, apparently.
Not much has changed in 5.x.

[RLeon]

Also, unlike ESX 4.x, it is now even more difficult in ESX 5.x where SAN mode restore directly to a managed ESX host doesn't work anymore. You could still do it if the ESX is unmanaged though:

http://www.symantec.com/business/support/index?page=content&id=TECH180679

[thesanman]

I agree; I gave up after spending way too much time and now use NBD and at least get the VM back!

[schrammd]

We are 4.x (for now). The problem we have with NBD is there is a firewall inbetween us and limited to 100Mb, so that blows for any sizeale VMs. Heck, it takes 2 days just to back up the templates when we run those jobs.

That eager zero thing is a real drag. I tried setting the key in the reg called "NoEagerlyScrub" but it did nothing for those. The throughput "might" have been a little better, but vCenter server still running full tilt while the restore ran, presumably with all the overhead of the zeroing.

I am waiting for firewall ports to be opened to the ESXs so I can at least try that. Why would vmware decide to forgo what seems like a novel approach to rapid recovery of big VMs?

thanks