<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> 1.Lost soapAction in http request header<o:p></o:p> When I tried to retrieve the property of storage.perDatastoreUsage under specify virtual machine and got a invalidProperty error but other properties(e.g. summary.storage, guest) under the same virtual machine are ok.<o:p></o:p> Then I write a same program use vsphere web service sdk in java and catch the http package by wireshark.<o:p></o:p> By comparing, I found that we lost soapAction field in http request header, it seems to like this: SOAPAction: "urn:vim25/5.0”.<o:p></o:p> I checked the vsphere development document and found some key description as following:<o:p></o:p> <a name="1104165">When a client application connects to a Web service running on an vSphere server (ESX/ESXi or vCenter Server </a>system), the server detects the version of the API that was used to develop the client and makes available only those operations supported by the client. <o:p></o:p> <a name="1104166">Client applications convey information about the API version used in the SOAP messages that they send to a </a>vSphere server. These SOAP messages include a versionID in the soapAction attribute. The details are handled transparently by the SOAP toolkit and the client proxy code. The server adjusts its behavior based on the client’s version information, exposing the API version that the client supports to the client. <o:p></o:p> <a name="1104193">If you are developing a client application that must support multiple server versions at the same time </a>(ESX/ESXi 5.0 and ESX/ESXi 3.x, for example), you must obtain information about the API versions that are supported on the server and provide logic in your code to use or not use features, based upon the version information.<o:p></o:p> Finally, I added the soapAction field into http request header and got a correct result. So I added some lines in function esxVI_Context_Connect() at src/esx/esx_vi.c as following:<o:p></o:p> if (virAsprintf(&soapAction, "SOAPAction: \"urn:vim25/%s\"",<o:p></o:p> ctx->service->about->apiVersion) < 0) {<o:p></o:p> virReportOOMError();<o:p></o:p> goto cleanup;<o:p></o:p> }<o:p></o:p> ctx->curl->headers = curl_slist_append(ctx->curl->headers, soapAction);<o:p></o:p> <o:p> </o:p> <o:p> </o:p> 2.cat not deserialize the String(maybe other primary types are included) which as a list<o:p></o:p> when I tried to retrieve the property of config.network.pnic under hostsystem and got an error in virsh.log which goes like as following:<o:p></o:p> 2013-04-22 01:57:42.692+0000: 29640: error : esxVI_String_Deserialize:1233 : internal error Wrong XML element type 3<o:p></o:p> Then I debug my program and find that bug lays where deserialize resourcePoolSchedulerDisallowedReason which is a member of PhysicalNic and has a string[] type.<o:p></o:p> I catch the soap message by wireshark and find that this xml element has no child ,it seems like as following:<o:p></o:p> <resourcePoolSchedulerDisallowedReason>hardwareUnsupported</resourcePoolSchedulerDisallowedReason<o:p></o:p> But the libvirt program still parses it as if it has children, I think this is key point that leads to this bug.<o:p></o:p> Now I fix my program by setting this member as ignore in esx_vi_generator.input.<o:p></o:p> Maybe you want to investigate and fix this bug.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Regards,<o:p></o:p> <o:p> </o:p> Dennis<o:p></o:p> <o:p> </o:p> </div> </body> </html>