tos2k
Expert
Expert

CopyVirtualDisk_Task issue (VimSdk BUG)

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 Smiley Wink

Tos2k

0 Kudos
12 Replies
tos2k
Expert
Expert

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.

0 Kudos
tos2k
Expert
Expert

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

0 Kudos
tos2k
Expert
Expert

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

0 Kudos
heyitspablo
VMware Employee
VMware Employee

tos2k,

I just sent dropped you a note,,

-Pablo

Keep up with latest info on vSphere PowerCLI http://blogs.vmware.com/vipowershell - Follow me on Twitter @heyitspablo
0 Kudos
tos2k
Expert
Expert

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

0 Kudos
tos2k
Expert
Expert

As time goes by...

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

Tos2k

0 Kudos
heyitspablo
VMware Employee
VMware Employee

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

Keep up with latest info on vSphere PowerCLI http://blogs.vmware.com/vipowershell - Follow me on Twitter @heyitspablo
0 Kudos
rcardona2k
Immortal
Immortal

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?

0 Kudos
rcardona2k
Immortal
Immortal

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.

0 Kudos
rcardona2k
Immortal
Immortal

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.)

0 Kudos
rcardona2k
Immortal
Immortal

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.

0 Kudos
rcardona2k
Immortal
Immortal

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.

0 Kudos