Update from 4.0.0 to 4.1.0 - RetrieveProperties method missing?

[kphan1]

We are using a PHP5 SoapClient to connect to the vSphere web service on VMWare ESX 4.0.0 hosts and poll for general information (mainly with the RetrieveProperties method). Recently a customer upgraded to 4.1.0, and we found that we needed to implement some new support for version 4.1.0.

In looking at the online API reference @ http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/ApiReference/vmodl.query.PropertyCollecto..., it is stated that the RetrieveProperties method has been deprecated as of 4.1 and to use the RetrievePropertiesEx method instead.

However, when we attempt to connect to the 4.1.0 host and call the RetrievePropertiesEx method in place of RetrieveProperties, we receive a Soap Fault stating that the RetrievePropertiesEx method is not a valid method of the service. We have since retrieved the WSDL from the host and found that indeed the RetreiveProperties method is not defined, but also more importantly that the RetrievePropertiesEx method (which is suppose to replace it) is not defined either. Is this an issue with the host not having the correct WSDL?

Are there any other methods that can be used in place of RetrieveProperties for version 4.1.0 of the API?

Thank you,

kphan

[stumpr]

Those are defined in the WSDL.

In vim.wsdl (from the SDK 4.1 package):

<operation name="RetrieveProperties">
         <input message="vim25:RetrievePropertiesRequestMsg"/>
         <output message="vim25:RetrievePropertiesResponseMsg"></output>
         <fault name="InvalidPropertyFault" message="vim25:InvalidPropertyFaultMsg"></fault>
         <fault name="RuntimeFault" message="vim25:RuntimeFaultFaultMsg"></fault>
</operation>

<operation name="RetrievePropertiesEx">
         <input message="vim25:RetrievePropertiesExRequestMsg"/>
         <output message="vim25:RetrievePropertiesExResponseMsg"></output>
         <fault name="InvalidPropertyFault" message="vim25:InvalidPropertyFaultMsg"></fault>
         <fault name="RuntimeFault" message="vim25:RuntimeFaultFaultMsg"></fault>
 </operation>

Though you're right, the ESX 4.1 host WSDL is missing those values. However, I used a quick perl script that calls RetrievePropertiesEx to test it. No soap faults, though I found you had to add a RetrieveOptions object as the options argument to the call. The maxObject property of RetrieveOptions is optional, but it still expects the option object value in the serialized XML.

Also note the return type has changed for the RetrievePropertiesEx call.

I also tested using just a plain RetrieveProperties call, no issues there either.

Looks like you just found a bug with the wsdl files on the web server root, but I suspect your error is related to your code not a missing implementation of the soap call. Particularly when you mentioned you're using PHP5 and in the past I've pointed out some of the issues with XML serialization with vanilla soap implementations not aware of the VMware SDK data model (Python suds, PHP nusoap).

[kphan1]

Quote from stumpr: "Looks like you just found a bug with the wsdl files on the web server root, but I suspect your error is related to your code not a missing implementation of the soap call."

I agree, I don't believe the problem is a missing implementation of the method, and the subject line of my original post probably should have been RetrieveProperties method missing from WSDL?

But the error is not in our code. The existing code calls RetrieveProperties on 4.0 hosts without any issues, it is only an issue when connecting to 4.1 hosts. I've downloaded the 4.0 and 4.1 vimService.wsdl and vim.wsdl files and did a general comparison:

$ ll \*/\*.wsdl

-rw-rr 1 user group 545 Jul 29 15:16 4.0/vimService.wsdl

-rw-rr 1 user group 1924904 Jul 29 15:16 4.0/vim.wsdl

-rw-rr 1 user group 545 Jul 29 15:12 4.1/vimService.wsdl

-rw-rr 1 user group 871114 Jul 29 15:12 4.1/vim.wsdl

$ wc -l \*/\*.wsdl

16 4.0/vimService.wsdl

42128 4.0/vim.wsdl

16 4.1/vimService.wsdl

19140 4.1/vim.wsdl

61300 total

The file sizes and line counts for the vim.wsdl file are significantly different from version 4.0 to 4.1; alone this may not mean anything, however, coupled with the fact that we can agree that the RetrieveProperties and RetrievePropertiesEx methods are missing from the 4.1 WSDL, we can probably say that the 4.1 WSDL is not correct.

And while I belive that the PHP5 SoapClient has its problems, we can't really fault it for issuing a SoapFault when I try to call a method that's not there (according to the WSDL).

So for the time being, here's the temporary solution that we've come up with:

a. downloaded the 4.0 vimService.wsdl and vim.wsdl files

b. changed how the SoapClient is created

Before:

$soapClient = new SoapClient('https://4.1.0.hostIp/sdk/vimService.wsdl');

After:

$soapClient = new SoapClient('/local/path/to/4.0.0/vimService.wsdl', array('location' => '4.1.0.hostIp'));

Basically, we're still having the SoapClient load the 4.0 WSDL but connecting to a 4.1 host. This works. The services on the 4.1 hosts are still there, but because the WSDL located on the host is incorrect, if we load that WSDL, we can't access that functionality.

At this point I think it is VMWare's responsibility to review the 4.1 WSDL and correct any problems with it and make that a downloadable patch for 4.1 hosts.

[stumpr]

Bear in mind I don't work with the team responsible for the SDK, you should follow up with a bug report on your end. I'll likely reach out internally as well.

I had assumed you were using local WSDL files, it sounds like that will correct the issue until the WSDL is fixed on the installation base for ESX 4.1. Bear in mind for most users, they do not use ESX WSDL files, they typically use a wsdl compiler to interact with the SDK. No offense intended to your code base

[kphan1]

No offense was taken. I just wanted to clarify since I think that my subject was a bit unclear.

And as a matter a fact, I owe you a bit of thanks -- if you hadn't looked at my post and helped to affirm that there were issues with the WSDL, I might still be spinning my wheels trying to figure out how to address the problem. But as it is, our exchanged helped me come up with a solution that works for the time being (albeit a bit hackish). So I do appreciate your time :).

I will open a bug report as you suggested and hopefully a new WSDL will be out soon and I can go back into our codebase and refactor it to use the newer methods as recommended.

Thanks,

kphan

[tekknokrat]

Might you point out the bug report describing the issue and possible workaround?

Thanks for your time,

tekknokrat

[Steve_Jin]

I don't think the method is missing. The open source VI Java API (http://vijava.sf.net) relies on this method to get all the properties.

Steve Jin, author of VMware VI and vSphere SDK http://www.doublecloud.org

[digitalaudioroc]

I just ran into this attempting to query a 4.1 ESXi server here.  I don't know if the fact that it's ESXi affects this or not, but I manually downloaded the vim.wsdl using wget and verified that it is in fact missing any trace of RetrieveProperties* methods:

grep RetrieveP vim.wsdl
         <element name="RetrieveProductComponents"  type="vim25:RetrieveProductComponentsRequestType" />
         <element name="RetrieveProductComponentsResponse">
   <message name="RetrieveProductComponentsRequestMsg">
      <part name="parameters" element="vim25:RetrieveProductComponents" />
   <message name="RetrieveProductComponentsResponseMsg">
      <part name="parameters" element="vim25:RetrieveProductComponentsResponse" />
      <operation name="RetrieveProductComponents">
         <input message="vim25:RetrieveProductComponentsRequestMsg" />
         <output message="vim25:RetrieveProductComponentsResponseMsg" />
      <operation name="RetrieveProductComponents">

Any ideas?

Tom

[stumpr]

I'd have to verify it, but from the earlier posts and yours the problem is the WSDL files on the ESXi host itself.  If you use the WSDL files from the SDK packages, you won't have this issue.

This explains why the Java, Perl and other toolkits are not encountering this error, but why you'd have issues with a non-VMware SOAP package that pulls directly from ESXi is raising these errors.

I would try to include the WSDL as part of the tool instead of attempting to load it at runtime from the ESXi host.  I'm assuming that against vCenter this isn't an issue, or it likely would have come up before.  However, it should probably be tested against vCenter as well.

[stumpr]

So I went and verified this against vSphere 4.1.

If you fetch the wsdl from vCenter ( https://<vc>/sdk/vim.wsdl ), the RetrieveProperties* definitions are defined.

If you fetch the wsdl from ESXi ( https://<esxi>/sdk/vim.wsdl ), the RetrieveProperties* definitions are NOT defined.

The wsdl files provided in the SDK packages are defined.

As a work around, it would probably be best to include the WSDL from the SDK packages when you are trying to connect to ESXi, or perhaps include them in the script file.

[digitalaudioroc]

Thanks stumpr!  That's exacly what I needed to know.  The code I'm writing is in fact intended primarily for running a vCenters or stand-alone ESX servers.  We were really just trying to use an ESXi for testing.  I'd be interested to know if the wsdl is correct on a stand-alone 4.1 ESX (not ESXi).

Thanks again!

Tom

[wzhou]

I am currently out of the office until Tuesday April 12th. If you require immediate assistance please contact my manager Chris Leslie (cleslie@cirba.com)