VMware {code} Community
ssandberg
Contributor
Contributor
Jump to solution

Will an app using the 2.5 SDK work with a 2.0 Virtual Center?

I have an application that was written using the 2.0.1 WSDL.

I have been given the requirement to support 2.5. If I get the app working with the 2.5 WSDL will it be able to Login and work with 2.0.x Virtual Center webservices?

0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

Hi,

Any SOAP request constructed using vim.jar (i.e. with namespace vim2Service) works for both ESX3.0.1/VC2.0.1 and ESX3.5/VC2.5

But Any SOAP request constructed using vim25.jar (i.e. with namespace vim25Service) works only for ESX3.5/VC2.5.

So any application which works with ESX3.0.1/VC2.0.1 must also work with ESX3.5/VC2.5.

Seemanki

View solution in original post

0 Kudos
10 Replies
tos2k
Expert
Expert
Jump to solution

Hi!

I feel the need for a compatibility matrix too. Running VimApi2.5 on VC2.0 does completely fail for me (soap exception at login).

Running VimApi2.0 on VC2.5 goes basically fine. I encountered a few compatibility issues where I had to change VirtualDisk to VirtualDevice. Also VirtualDeviceFileBackingInfo seems to be invalid, have not found out yet if VirtualDeviceBackingInfo is a suitable repacement.

Tos2k

ssandberg
Contributor
Contributor
Jump to solution

I also am getting the SOAP exception when attempting to login VimApi2.5 to VC2.0

0 Kudos
ssandberg
Contributor
Contributor
Jump to solution

2.0 app connects and works with 2.0 vc and 2.5 vc.

2.5 app connects and works with 2.5 vc but not with 2.0 vc

0 Kudos
admin
Immortal
Immortal
Jump to solution

Hi,

Any SOAP request constructed using vim.jar (i.e. with namespace vim2Service) works for both ESX3.0.1/VC2.0.1 and ESX3.5/VC2.5

But Any SOAP request constructed using vim25.jar (i.e. with namespace vim25Service) works only for ESX3.5/VC2.5.

So any application which works with ESX3.0.1/VC2.0.1 must also work with ESX3.5/VC2.5.

Seemanki

0 Kudos
tos2k
Expert
Expert
Jump to solution

This is definitely not correct. The following code is running fin for VC2.0 and ESX3 but does not work for VC2.5

VirtualDeviceConfigSpec[] deviceSpecAdd = new VirtualDeviceConfigSpec\[counter\];

foreach (Disk dk in exportedDisks)

{

foreach (String s in dk.DiskFiles)

{

VirtualDisk diskRef = new VirtualDisk();

diskRef.key = dk.Key;

diskRef.controllerKey = dk.Controller.Key;

diskRef.controllerKeySpecified = true;

diskRef.unitNumber = dk.UnitNumber;

diskRef.unitNumberSpecified = true;

Description devInfo = new Description();

devInfo.label = dk.Label;

devInfo.summary = dk.Summary;

diskRef.deviceInfo = devInfo;

VirtualDeviceFileBackingInfo backing = (VirtualDeviceFileBackingInfo)dk.Backing;

backing.datastore = datastoreRef;

backing.fileName = s;

diskRef.backing = backing;

deviceSpecAdd\[counter\] = new VirtualDeviceConfigSpec();

deviceSpecAdd\[counter\].device = diskRef;

deviceSpecAdd\[counter\].operation = VirtualDeviceConfigSpecOperation.add;

deviceSpecAdd\[counter\].operationSpecified = true;

}

}

VirtualMachineConfigSpec newSpec2 = new VirtualMachineConfigSpec();

newSpec2.deviceChange = deviceSpecAdd;

ManagedObjectReference reconfRefAddDisks = null;

try

{

reconfRefAddDisks = service.ReconfigVMTask(vmRef, newSpec2);

}

VC2.5 constantly replies: "Invalid configuration for device '0'". I dont have a clue what could be the reason for this, any help is welcome!!

Tos2k

0 Kudos
tos2k
Expert
Expert
Jump to solution

Okay, it works for me now. The only thing I found was that VC2.0 accepts the following:

> VirtualDeviceConfigSpec[] deviceSpec = new VirtualDeviceConfigSpec[1];

> ...

> VirtualDisk diskRef = new VirtualDisk();

> deviceSpec[0].device = diskRef;

> ...

> VirtualMachineConfigSpec newSpec = new VirtualMachineConfigSpec();

> newSpec.deviceChange = deviceSpec;

> service.ReconfigVMTask(vmRef, newSpec);

where we have to replace VirtualDisk by VirtualDevice for VC2.5

Tos2k

0 Kudos
kelliw
Contributor
Contributor
Jump to solution

According to the Release Notes (http://www.vmware.com/support/developer/vc-sdk/visdk-2.5.0-200711-releasenotes.html#interop ), interoperability is as follows:

Previous releases of the VI SDK, ESX Server, and VirtualCenter Server are still supported, as follows:

  • The VI SDK 2.5 can be used with ESX Server 3.0.x or VirtualCenter 2.0.x systems.

  • The VI SDK 2.0 can be used with ESX Server 3 version 3.5 and VirtualCenter 2 version 2.5. Client applications developed using the VI SDK 2.0 should work, unchanged, with ESX Server 3.5 and VirtualCenter 2.5.

In addition, page 22 of the VI SDK 2.5 Programming Guide may shed some light on working with different versions of the WSDL and the target ESX Server:

Also, the list of deprecations, available in the Release Notes and on this standalone page, may be helpful in moving from 2.0 to 2.5:

Hope this helps.

0 Kudos
jaherr-raritan
Contributor
Contributor
Jump to solution

So the ESX3.5/VC2.5 web server is listening for both namespaces? Would a session created in the ESX3.0.1/VC2.0.1 namespace be able to be reacreated in the ESX3.5/VC2.5 namespace and used for host power operations?

Flow would look like this:

connect using VC 2.0 code

poll

user request shutdown of ESX server

SDK implementor recreates session and managed object reference objects in new namespace from old namespace data

VC 3.5 code used to change power state of ESX server

VC 2.0 session continues with arbitrary code (basically, we can still do whatever we want in the 2.0 world)

Is this possible?

Thanks,

J

0 Kudos
tos2k
Expert
Expert
Jump to solution

Yes in theory, but practically no. Let me explain:

because communcating with ESX3.5 / VC 2.5 happens with the VimApi.VimServic, communicating with older ESX/VC will be implemented by VimService only (without VimApi)

because it (of course) us possible to create an application operating with one or more ESX / VC instances "at once", and though to share data between the different instances and versions.

But to be clearly, as the session is "on the server", and you have to connect seperately per version, even on the same server, you will need at least two sessions (assuming one server supporting both versions).

:smileymischief:

Tos2k

0 Kudos
admin
Immortal
Immortal
Jump to solution

I have a question. Was the problem you were facing related to compiling the code against a particular WSDL or was it related to running it against a server?

The way the API is "supposed" to work is that code written and compiled against the VI API 2.0 WSDL will work without recompiling against a VC 2.5/ESX 3.5/ESX 3i servers (of course it was already running against VC 2.0.x/ESX 3.0.1 servers. If that is NOT the case, that is a bug.

0 Kudos