2013/4/23 Dennis Zou (yunzou) <yunzou@xxxxxxxxx>:
> 1.Lost soapAction in http request header
>
> 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.
>
> Then I write a same program use vsphere web service sdk in java and catch
> the http package by wireshark.
>
> By comparing, I found that we lost soapAction field in http request header,
> it seems to like this: SOAPAction: "urn:vim25/5.0”.
>
> I checked the vsphere development document and found some key description as
> following:
>
> When a client application connects to a Web service running on an vSphere
> server (ESX/ESXi or vCenter Server 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.
>
> Client applications convey information about the API version used in the
> SOAP messages that they send to 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.
>
> If you are developing a client application that must support multiple server
> versions at the same time (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.
>
> 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:
>
> if (virAsprintf(&soapAction, "SOAPAction: \"urn:vim25/%s\"",
>
> ctx->service->about->apiVersion) < 0) {
>
> virReportOOMError();
>
> goto cleanup;
>
> }
>
> ctx->curl->headers = curl_slist_append(ctx->curl->headers,
> soapAction);
Well, this is basically a known problem. Ata Bohra proposed a similar
patch a while ago:
https://www.redhat.com/archives/libvir-list/2012-December/msg01390.html
But it seems that this change breaks existing functionality. I didn't
yet investigate this in detail, because the existing functionality is
not affected by the missing header.
> 2.cat not deserialize the String(maybe other primary types are included)
> which as a list
>
> 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:
>
> 2013-04-22 01:57:42.692+0000: 29640: error : esxVI_String_Deserialize:1233 :
> internal error Wrong XML element type 3
This bug is specific to the esxVI_String_Deserialize function and was
fixed in this commit
http://libvirt.org/git/?p=libvirt.git;a=commit;h=466b306b3966f764ccce69c0315990ba44b544a6
So you are working with a code base that is at least 9 months old. I
suggest that you update your libvirt code base.
--
Matthias Bolte
http://photron.blogspot.com
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list