VMware {code} Community
deepakmits
Contributor
Contributor
Jump to solution

How can I know which MOR is invalid in queryPerf() query ?

I have one scenario where my queryPerf() is working fine say for 10VMs and I am getting perf data for all the VMs. But now suddenly say 1 vm gets deleted for which also queryPerf() was collecting data . But after deleting this queryPerf() starts giving exception saying InvalidArgumentFault.

So I want to know

1) Is there any way by which I can know which MOR is invalid ?

2)Can I use this query in such a way that even in case of deletion I get the data for other VMs which are not deleted ?

faultCode: ServerFaultCode

faultSubcode:

faultString: A specified parameter was not correct.

querySpec.entity

faultActor:

faultNode:

faultDetail:

InvalidArgumentFault:(BeanDeserializer.java:90)

ERROR 12/01 15:47:27 Stderr 700100 at com.vmware.vim.InvalidArgument.getDeserializer(InvalidArgument.java:120)

ERROR 12/01 15:47:27 Stderr 700100 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

ERROR 12/01 15:47:27 Stderr 700100 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

ERROR 12/01 15:47:27 Stderr 700100 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

ERROR 12/01 15:47:27 Stderr 700100 at java.lang.reflect.Method.invoke(Method.java:597)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.encoding.ser.BaseDeserializerFactory.getSpecialized(BaseDeserializerFactory.java:154)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.encoding.ser.BaseDeserializerFactory.getDeserializerAs(BaseDeserializerFactory.java:84)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.encoding.DeserializationContext.getDeserializer(DeserializationContext.java:464)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.encoding.DeserializationContext.getDeserializerForType(DeserializationContext.java:547)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.message.SOAPFaultDetailsBuilder.onStartChild(SOAPFaultDetailsBuilder.java:157)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1035)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)

ERROR 12/01 15:47:27 Stderr 700100 at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:796)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.client.Call.invokeEngine(Call.java:2784)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.client.Call.invoke(Call.java:2767)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.client.Call.invoke(Call.java:2443)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.client.Call.invoke(Call.java:2366)

ERROR 12/01 15:47:27 Stderr 700100 at org.apache.axis.client.Call.invoke(Call.java:1812)

ERROR 12/01 15:47:27 Stderr 700100 at com.vmware.vim.VimBindingStub.queryPerf(VimBindingStub.java:22855)

0 Kudos
1 Solution

Accepted Solutions
Steve_Jin
Expert
Expert
Jump to solution

Maintaining your VM list should work. The simpler way to work around this would be to query data once for every VM in your vm list.

Even though the queryPerf takes in PerfQuerySpec array, you can always pass in one spec for a vm at a time. You should try/catch the part of code.

BTW, many VI SDK APIs work in a similar way in that it fails once it find problem with one entity. You can always apply the same trick.

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org

View solution in original post

0 Kudos
6 Replies
tos2k
Expert
Expert
Jump to solution

Hi!

Here my thoughts:

1) My first gut feeling was that you possibly maintain a static list over MOR for your VMs. Deleting a VM will force you to manually update this list then.

Of course, such a list would be a bad idea/design anyway.

A solution here would be to load all VMs and check if this list sill contains all of your MORs. Consider that a MOR to one and same VM can change within the lifetime of this VM!

2) When you fetch you MORs dynamically, the the returned list of MORs (for VMs) will not contain a deleted VMs. So possibly you should post some more info/code

Tos2k

deepakmits
Contributor
Contributor
Jump to solution

Thanks for your helpful answer.

Yes this list of MORs is static but only for the time I don't trigger my device discovery code. Once device discovery happens this MORs list gets changes, but the device discovery happens say only with 6hrs interval . In that case if in between VM is deleted, I would want to know which MOR is deleted and then remove that from MOR list and again execute query. If you see any other way it ill be appreciated.

So the issue is how to get that deleted MOR and data for the other not deleted VMs . The exception which this query throws doesn't tell about which MOR/entity is invalid.

Thanks.

0 Kudos
tos2k
Expert
Expert
Jump to solution

Hi!

I would be more carefully with the design of your app! Here the choices you have:

1) trigger the "device recovery code" each time you want to run operations on VMs

-> this will avoid any issues with deleted VMs for all time!

2) Fetch "Remove/Delete" Events on VC

-> this will give you extra code to maintain, but the MORs you are looking for (bad choice, more code, less flexible...)

3) The VI SDK does notprovide if a given MOR still exists. You could possibly use the UUID of the VM, but anyway, this concept will be broken anyway

-> more code, less stability

So no, there is no way to ask VC if a MOR still exists (and is same). My recommendation is to fetch a valid/new list of VMs each time you run som OPs.

Tos2k

0 Kudos
Steve_Jin
Expert
Expert
Jump to solution

Maintaining your VM list should work. The simpler way to work around this would be to query data once for every VM in your vm list.

Even though the queryPerf takes in PerfQuerySpec array, you can always pass in one spec for a vm at a time. You should try/catch the part of code.

BTW, many VI SDK APIs work in a similar way in that it fails once it find problem with one entity. You can always apply the same trick.

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos
deepakmits
Contributor
Contributor
Jump to solution

Thanks for your reply.

Yes, this seems to be the only way out for handling this scenario.

Thanks.

0 Kudos
Steve_Jin
Expert
Expert
Jump to solution

You are very welcome.

Steve JIN Author of VMware VI and vSphere SDK; Creator of open source VI Java API (http://vijava.sf.net); Blogger at http://www.doublecloud.org
0 Kudos