Hot add is not supported for this disk - 6.0.0.153

[micwe]

Hello
I have upgraded my entire ESXI host to last build ESXI 5.0
And Install new Veeam backup on VM win2008 r2 with last veeam build - version 6.0.0.153 (clean install not upgrade)

After setting up new copy and replica job in veeam - all job finish with Warning - Hot add is not supported for this disk, failing over to network mode...
In my old veeam backup V5 and esxi4.0 host environment all job completed Successful

I search on this forum about this error but didn't come up with reference to veeam build - version 6.0.0.153
I came across this KB ID: 1442 that reference to my problem
http://www.veeam.com/kb_articles.html/KB1442
But after applying error still comes up "Hot add is not supported for this disk, failing over to network mode..."
How can I solve this issue and use the Virtual Appliance option

Thanks
Micwe

[foggy]

Micwe, there are a number of limitations (put by VMware vStorage API) that prevent hot add mode to be used in some cases. Please refer to this KB article
for complete list (this is covered in our release notes, btw). Hope this helps. If you cannot find any matching reasons, please open a support case for investigation. Thanks!

[lobo519]

Not to hijack this thread but:

I do have this issue one of my replication jobs and I believe it is due to this reason:

"With HotAdd transport, full backup of a virtual machine fails when multiple disks have the same name, as they could if they are on different datastores."

I have a second replication job that is configured the same way and also has the above naming problem but does not give the Hot add failing to network warning.

Is it using hot add or is it actually failing to network mode??

I found some documentation on VMware's site that shows how to rename a vmdk file - will that break the replication job??

[Gostev]

No failover warning means that it is using hot add.
Renaming disk will not "brake" the job, but that disk will likely need to be replicated over entirely.

[lobo519]

Any thoughts as to why sometimes it works?

[Gostev]

No idea - this is not our code...

[spalmer]

I had this exact same issue and it is now resolved - the root cause was the target proxy was on a datastore with a 1MB block size, but it was trying to hotadd a disk larger than 256 GB. By moving the target proxy (storage vmotion) to a datastore with an 8 MB block size the warnings dissappeared (note: hotadd would fail for all disks of the VM, even those smaller than 256GB just because there was at least 1 disk that was larger than the block size limitation). Hope this helps.

[Vitaliy S.]

Yes, this (block size mismatch) is one of the limitations for Virtual Appliance (aka Hot Add) mode, upgrading to vmfs 5 file system should solve this issue too since it has the same block size no matter of datastore size.

[Gostev]

Pretty sure that "upgrading" to VMFS5 will not change block sizes, instead you need to create new VMFS5 LUN and migrate your VMs there. There are a few VMFS5 capabilities that you will lose when upgrading existing datastores to VMFS5.

[jeancharles]

Hi,
If you want to see the differences between VMFS3 upgraded to 5, and new VMFS5:
http://blogs.vmware.com/vsphere/2011/07/new-vsphere-50-storage-features-part-1-vmfs-5.html

[loren10]

I solved this issue with hotfix "veeam_backup_6.0.0.158.hf1_setup.exe"
Regards

[tomas.olsen]

Hello everyone, I have just upgraded a few esx hosts from vsphere 4.1 to vsphere 5.0.
I upgraded vmware tools and hardware of all my vm's as well. except the virtual center server which was a virtual machine.
At the same time, I also upgraded Veeam from 5.0.230 to 6.0.0.153.
everything worked like a charm. All my vm's backed up just fine.

Today I upgraded my virtual center server with vmware tools and new virtual hardware.
The first time my scheduled backup ran, all my vms failed with the same error as specified here.

I tried the patch, but it doesnt seem to work for me. My datastores is still vmfs 3.46.

[tomas.olsen]

Hello again,

Problem solved for now.
The trick was to migrate the Veeam virtual machine configuration files and the virtual machine system disk to a datastore that was formatted with VMFS 5. I ran the backup again, and all machines was successfull. In my environment the veeam management server is also the proxy.

I suspect that the same thing applies if you have deployed multiple proxies since the hot-add will be done to the proxy and not the management server. If you just use dedicated proxies for backup it might not be important that the management server is located on vmfs5 datastores but this is just my guess and have not been testet.

So in my experience this has to do with when the virtual center is upgraded with new virtual hardware and vmware tools, you need to make sure that the virtual veeam server configuration files and system disk need to be located on a vmfs5 datastore.

[Gostev]

Hi Tomas - this is a great finding, thank you very much for taking time to share this with the community!

[tomas.olsen]

You are welcome Gostev,

Let me know if you need further info in case you want to investigate this more thoroughly.

Happy new year to all of you !!