CopyVirtualDisk_Task issue (VimSdk BUG)

[tos2k]

Hi folks. I want to copy a virtual disk via VimSdk 2.5.

For this I connect to the webservice of a ESX 3.5 server, and run the task. Worx fine. BUT: When I do this through a host, that has access to source and target datastore, but which is nothosting the VM the virtual disk belongs to, then, if the VM is powered-on, the host does not recongize that the virtual disk is not locked, when i created a snapshot for the VM via VC before. Tricky, I know.

Anybody that has been into this before?

As the VM is not known on the host that should copy its disk, it is not even possible to refresh the VM. Even refreshing the source datastore the VM resides on does not seem to help.

The error that comes up on the ESX: "General fault caused by file. Device or resource busy" - hm, okay, I understand this, but it is not the truth

Tos2k

[tos2k]

This appears to be a bug in VimSdk. Copying fails with CopyVirtualDisk_Task and CopyDatastoreFile_Task.

It works with the vi client and with vmkfstools from the service console.

I created a SR on this. Stay tuned.

[tos2k]

Okay, I detected that the calls to vmKernel differ:

Call generated through VimSdk:

Apr 24 10:33:10 Hostd: 2008-04-24 10:33:10.340 'TaskManager' 704525 info Task Completed : haTask--vim.FileManager.copyFile-270683

Call generated by the VI client (datastore browser):

Apr 24 10:24:18 Hostd: 2008-04-24 10:24:18.404 'TaskManager' 114696 info Task Created : haTask--vim.FileManager.copy-270484

It seems like copyFile is checking if the delta files are locked, in addtion to the vmdk-file. This is not what it is supposed to do!

Tos2k

[tos2k]

Okay, this thread is about one week old. This is exactly the time I am wainting for feedback from VMware according my SR.

The issue has been researched more detailed within the last days, and it appears that it does not come up for SAN or NFS. I am currently just experiencing troubles for iSCSI shares, where possibly headers/metadata is not refreshed properly at all hosts having access to the share. Even VC comes in trouble when copying snapshoted VMs virtual disks with the VI client...

Tos2k

[heyitspablo]

tos2k,

I just sent dropped you a note,,

-Pablo

[tos2k]

Could not find anything, what did you mean by this? This is really starting to make headaches to me and my team, we have no clue or workaround for this strange and unexpected behaviour...

Tos2k

[tos2k]

As time goes by...

Now we have the ESX 4 and the issue still is unresolved and so applies for ESX 4 too...

Tos2k

[heyitspablo]

Thanks for the heads up - Im going to have our SDK Dev team escalate issue.... might be best if we file a formal TAP SDK SR for this.. Ill send you more info.

Regards,

Pablo

[rcardona2k]

This issue continues to be a problem in ESX Server 3.5 Update 5 and ESX Server 4 Update 1. How is your escalation process working?

[rcardona2k]

Just an update for Tos2k and anyone following this thread. I have escalated this issue through VMware GSS and it is being tracked. The issue has been confirmed for quite a while by SDK support as a problem in ESX 3.5 and 4.0. I'm currently awaiting a timeline for resolution.

[rcardona2k]

Anyone out there affected by the issue described here should communicate their use case and reference SR# 1451408341 as that might help VMware understand how third parties, admins and partners using the public SDK calls are impacted by further delays in the resolution of this issue (posted here by tos2k back in 2008.)

[rcardona2k]

VMware SDK support has notified me that this issue will be resolved in the forthcoming release of ESX 4.0 Update 3. I have no timeframe for when that update is coming. Historically Update 2 was released on 6/10/2010 and Update 1 back on 11/20/2009, so Update 3 is probably sometime later this year.

[rcardona2k]

For anyone tracking this issue, the problem reported by tos2k with CopyVirtualDisk_Task is FIXED in ESX/ESXi 4.1 Update 1.  This is first publically available version of ESX this issue is addressed in.  VMware has promised it is fixed in ESX 4.0 Update 3 to be released soon (no later than March 2011).

It has taken an extraordinarily long time for VMware to fix this SDK issue but the fix is finally available to SDK users.