Compatibility: VIPerl 1.6 & vSphere SDK for Perl v4: Gotchas/Issues?

[kindlund]

Hi,

Are there any issues with STILL using VIPerl v1.6 with ESX/ESXi v4? So far, it looks like the API really didn't change, but I wanted to know if there were any issues/gotchas with this approach.

Aside from the introduction of the "Credential Store", it doesn't seem worthwhile upgrading to the newer API, unless there were significant bug fixes / issues resolved... after checking the Release Notes, I don't really see any noticeable changes.

Lastly, does VMware intend to ever encrypt the password content in the "Credential Store"? Meaning, when a perl script runs, the SDK prompts the user to "unlock" the credential store, allowing the script to access credentials until the script ends? This is similar to how Apache2 accesses protected private keys, associated with SSL certs.

Thanks,

-- Darien

[stumpr]

Aren't there several new objects and methods in the v4 SDK, even though the namespace is still the same? So I believe you'll be unable to make certain calls without the new v4.

I don't think you have to use the new Credential Store, you can ignore it and use scripts like you did before. However, I haven't explored it in much detail myself yet.

[kindlund]

Okay, but I'm simply interacting directly with ESX/ESXi v4 servers. Aren't the new objects and methods only applicable to vCenter? So, yes, if I were interacting with vCenter, I could see why it would be worthwhile to upgrade... however, if I'm just interacting directly with ESX/ESXi v4, then I don't see the point.

[stumpr]

I'd have to look through the v4 SDK. I really just started using it. Maybe one of the VMware guys can confirm for you.

[kindlund]

Looks like I found at least one issue:

The CopyVirtualDisk_Task call in VIPerl 1.6 does NOT seem to work with ESX/ESXi v4... Here's the error message in hostd.log:

[2009-06-18 21:15:36.421 125F4B90 info 'TaskManager'] Task Created : haTask--vim.VirtualDiskManager.copyVirtualDisk-1852795583
[2009-06-18 21:15:36.504 125F4B90 warning 'VdisksvcPlugin'] Invalid disk type: .

[2009-06-18 21:15:36.504 125F4B90 info 'App'] AdapterServer caught exception: vmodl.fault.InvalidArgument
[2009-06-18 21:15:36.504 125F4B90 info 'TaskManager'] Task Completed : haTask--vim.VirtualDiskManager.copyVirtualDisk-1852795583 Status error
[2009-06-18 21:15:36.504 125F4B90 info 'Vmomi'] Activation [N5Vmomi10ActivationE:0x59f86940] : Invoke done [copyVirtualDisk] on [vim.VirtualDiskManager:ha-vdiskmanager]
[2009-06-18 21:15:36.504 125F4B90 verbose 'Vmomi'] Arg sourceName:
"[datastore1] Agent.Master-45-IE7/Agent.Master-43-IE7.vmdk"
[2009-06-18 21:15:36.504 125F4B90 verbose 'Vmomi'] Arg sourceDatacenter:
'vim.Datacenter:ha-datacenter'
[2009-06-18 21:15:36.504 125F4B90 verbose 'Vmomi'] Arg destName:
"[datastore1] d185e8844e206f18b9e5b51ed8/Agent.Master-43-IE7.vmdk"
[2009-06-18 21:15:36.504 125F4B90 verbose 'Vmomi'] Arg destDatacenter:
'vim.Datacenter:ha-datacenter'
[2009-06-18 21:15:36.505 125F4B90 verbose 'Vmomi'] Arg destSpec:
(vim.VirtualDiskManager.VirtualDiskSpec) {
   dynamicType = <unset>,
   diskType = "",
   adapterType = "busLogic",
}
[2009-06-18 21:15:36.505 125F4B90 verbose 'Vmomi'] Arg force:

[2009-06-18 21:15:36.505 125F4B90 info 'Vmomi'] Throw vmodl.fault.InvalidArgument
[2009-06-18 21:15:36.505 125F4B90 info 'Vmomi'] Result:
(vmodl.fault.InvalidArgument) {
   dynamicType = <unset>,
   faultCause = (vmodl.MethodFault) null,
   invalidProperty = "",
   msg = "",
}

Still trying to track down this issue....

[kindlund]

Okay, looks like the culprit here was that diskType("preallocated") needs to be specified in the VirtualDiskSpec object of destSpec argument in the CopyVirtualDisk_Task.

I guess in the past, when you gave an empty string, it assumed "preallocated"; however, ESXv4 makes no such assumption.

Still checking other compatibility issues...

[stumpr]

Good info

[kindlund]

So I tried the new Perl v4 SDK, and everything was going smoothly... until I tried backwards compatibility with ESX 3.5 U4...

Apparently, when executing the CopyVirtualDisk_Task, ESX 3.5 U4 doesn't properly recognize the "preallocated" VirtualDiskType, as evidence in these logs:

"/vmfs/volumes/496253ae-ac4c49ac-8e87-001a64c651b8/Testing.VM/Agent.Master-43-IE7-flat.vmdk" : open successful (29) size = 17179869184, hd = 0. Type 3
[2009-06-19 17:46:17.535 'BaseLibs' 16384 info] DISKLIB-VMFS : "/vmfs/volumes/496253ae-ac4c49ac-8e87-001a64c651b8/Testing.VM/Agent.Master-43-IE7-flat.vmdk" : closed.
[2009-06-19 17:46:17.535 'VdisksvcPlugin' 16384 warning] Invalid desination disk format 'preallocated'
[2009-06-19 17:46:17.562 'BaseLibs' 16384 info] DISKLIB-VMFS : "/vmfs/volumes/496253ae-ac4c49ac-8e87-001a64c651b8/Testing.VM/Agent.Master-43-IE7-flat.vmdk" : open successful (6) size = 17179869184, hd = 18000881. Type 3
[2009-06-19 17:46:17.562 'BaseLibs' 16384 info] DISKLIB-DSCPTR: Opened [0]: "Agent.Master-43-IE7-flat.vmdk" (0x6)
[2009-06-19 17:46:17.567 'BaseLibs' 16384 info] DISKLIB-LINK  : Opened '/vmfs/volumes/496253ae-ac4c49ac-8e87-001a64c651b8/Testing.VM/Agent.Master-43-IE7.vmdk' (0x6): vmfs, 33554432 sectors / 16384 Mb.
[2009-06-19 17:46:17.567 'BaseLibs' 16384 info] DISKLIB-LIB   : Opened "/vmfs/volumes/496253ae-ac4c49ac-8e87-001a64c651b8/Testing.VM/Agent.Master-43-IE7.vmdk" (flags 0x6). A9FF08C
[2009-06-19 17:46:17.567 'BaseLibs' 16384 info] DISKLIB-LIB   : Invalid type (0)
[2009-06-19 17:46:17.567 'BaseLibs' 16384 info] DISKLIB-LIB   : Failed to clone : One of the parameters supplied is invalid (1).
[2009-06-19 17:46:17.567 'VdisksvcPlugin' 16384 warning] Failed to clone disk : One of the parameters supplied is invalid (1).
[2009-06-19 17:46:17.570 'BaseLibs' 16384 info] DISKLIB-VMFS : "/vmfs/volumes/496253ae-ac4c49ac-8e87-001a64c651b8/Testing.VM/Agent.Master-43-IE7-flat.vmdk" : closed.
[2009-06-19 17:46:17.570 'TaskManager' 16384 info] Task Completed : haTask--vim.VirtualDiskManager.copyVirtualDisk-3805
[2009-06-19 17:46:23.366 'ha-eventmgr' 1703949 info] Event 2080 : User root logged out

So, unless a VMware representative can chime in here, I'm thinking the moral of this lesson is:

If you want full disk copy support and you need to write code that works on BOTH ESX 3.5 U4 and ESX 4, then you must deal with this "preallocated" hack... meaning, supply VirtualDiskType("preallocated") for ESX 4 and the empty string VirtualDiskType("") for ESX 3.5 U4 and below....

You know, I'd really which VMware would develop some sort of internal "unit testing" on their APIs, so that when they roll-out new versions of ESX, they can run these automated tests, in order to spot these nuances.

Heck, I could send them the basis code for these unit tests, since I've had to write this already....

[kindlund]

So, apparently the CopyVirtualDisk_Task for ESX 3.5 U4 and below is buggy, as referenced in this post:

http://communities.vmware.com/message/1015081

It's a shame it isn't fixed...

[jnhall · Accepted solution]

VIPT 1.6 is intended to be compatible with the 4.0 release of the API. There may be issues due to changes with the API itself but for the most part, VIPT just uses the API as it exists.

[kindlund]

Okay, yeah, I think ESX 3.5 and ESX 4 have slightly different ways of implementing the API; however, aside from the Copy task issue, I haven't run into any other issues.