VMware {code} Community
tpcool
Enthusiast
Enthusiast

vSphere PropertySpec not accepting the type DistributedVirtualSwitch, DistributedVirtualPortgroup and VmwareDistributedVirtualSwitch

Hi,

I am preparing a property spec, to get the properties of DVS, DV Port group, and VMWare DVS, but somehow it doesn't allow me to set the property spec for this type.

Any ideas on why it is not accepting the DVS type?

I get the following error:

<soapenv:Fault><faultcode>ServerFaultCode</faultcode><faultstring>The request refers to an unexpected or unknown type.</faultstring><detail><InvalidTypeFault xmlns="urn:vim25" xsi:type="InvalidType"><argument>DistributedVirtualSwitch</argument></InvalidTypeFault></detail></soapenv:Fault>

Java code:

propertySpec = new PropertySpec();

propertySpec.setAll(Boolean.TRUE);

propertySpec.setType("DistributedVirtualSwitch");

propertySpecList.add(propertySpec);

// same with other types

Documentation: (see attached) clearly mentions that we can specify these types in the property spec.

Appreciate if anyone has any inputs in this matter.

I am using the vim25 Axis2 wsdl2Java generated stubs. I am not sure if this has anything to do with the error, but mentioning just in case.

Thanks for your time.

Reply
0 Kudos
12 Replies
lamw
Community Manager
Community Manager

DVS is a new object that was introduced with the new vSphere released, you mentioned you're using the vim25 stubs, you need to be using 4.0 stubs and I assume that it would be named vim4?

=========================================================================

William Lam

VMware vExpert 2009

VMware ESX/ESXi scripts and resources at:

VMware Code Central - Scripts/Sample code for Developers and Administrators

If you find this information useful, please award points for "correct" or "helpful".

Reply
0 Kudos
tpcool
Enthusiast
Enthusiast

Thanks for your response. I think the stubs should still be named vim25

Even the vim.wsdl and vimService.wsdl indicate the namespace as vim25. Excerpt included below.

-


<definitions targetNamespace="urn:vim25"

+ xmlns="http://schemas.xmlsoap.org/wsdl/"+

+ xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"+

+ xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"+

+ xmlns:vim25="urn:vim25"+

+ xmlns:xsd="http://www.w3.org/2001/XMLSchema"+

>

<definitions targetNamespace="urn:vim25Service"

+ xmlns="http://schemas.xmlsoap.org/wsdl/"+

+ xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"+

+ xmlns:interface="urn:vim25"+

>

+ <import location="vim.wsdl" namespace="urn:vim25" />+

-


I am not sure why the server is rejecting the data. Is there anyway we can look at the logs on the server side, to diagnose the problem?

Reply
0 Kudos
admin
Immortal
Immortal

Looks like you are using an older server, and not 4.0

The older servers do not know about these new objects. Try running it with a new server.

Reply
0 Kudos
stumpr
Virtuoso
Virtuoso

Iamw, strangely the new stubs use the same namespace vim25. Smiley Happy I was a little surprised myself.

Reuben Stump | http://www.virtuin.com | @ReubenStump
Reply
0 Kudos
admin
Immortal
Immortal

The same namespace is to make it easy for cleint programs to run with older and newer versions of the servers with out having to know the server version.

Reply
0 Kudos
tpcool
Enthusiast
Enthusiast

We are running the newer version of the vCenter server (4.0.0 Build 162856) (see attached pic)

I could create and view the DVS instances from vSphere client. I could also see these in the MO browser.

We are running an evaluation version of the license though. I am not sure if there are any restrictions in PropertySpec in the eval license case

Is there anyway to take a look at the logs on the vCenter?

Reply
0 Kudos
admin
Immortal
Immortal

You can view the logs In the vSphere client.

View -> Administration -> System Logs

Reply
0 Kudos
tpcool
Enthusiast
Enthusiast

Looks like these logs only show what was triggered from the client.

I couldn't see logs that got generated as a result of the invocation of RetreiveProperties operation.

I am blocked. It would be nice if anyone can give a try on his/her end, just to see if it is working.

Thanks

Reply
0 Kudos
tpcool
Enthusiast
Enthusiast

I have another question on the same lines.

When the client connects to the server, does it need to explicitly set the version somewhere? For example, does the server need to know if it is communicating with old vim25 clients or new vim25 clients (which can work with new types)

I just ran the propertycollector with the "ALL" properties for "Datacenter"

It did not return any of the new properties that were defined as of 4.0. For example it did not return datastoreFolder, networkFolder etc.

This make me to think if the client needs to set any parameters when it connects to server.

I hope I am clear.

Appreciate any response in this matter.

Reply
0 Kudos
static_void
Contributor
Contributor

Hi tpcool,

I am facing the same problem as you. I need to query "networkFolder" properties from Datacenter object, but unable to do so.

I am sure I am using new API version 4.0.

In a updated programming guide I found that these new types are not listed in "valid values for ManagedObjectRefernce type property" (page 47).

Have you found any workaround for this issue?? guys at VMware , can you please help us regarding this issue?

Thanks & Regards

sachin.

Reply
0 Kudos
tpcool
Enthusiast
Enthusiast

As silly as it might sound, the actual issue was with WSDL.

I had an old beta version of WSDL (and hence old stubs) on the client, and the server thinks that it is an old client, and hence it doesn't send/expose the new MOs and attributes. These old WSDLs belong to 4.0 for sure, but looks like they are beta version.

To get accurate results, use the same as WSDL as that of the server and geneate stubs from those WSDLs

You can get the server WSDLs in this way

https://myhost/sdk/vim.wsdl

https://myhost/sdk/vimService.wsdl

I am able to use "networkFolder" both in the property spec and traversal spec (setPath)

Reply
0 Kudos
static_void
Contributor
Contributor

Thanks a lot for ur help...

I will give it a try and get back to you..

Reply
0 Kudos