2013/4/23 Dennis Zou (yunzou) <yunzou(a)cisco.com>:
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=466b306b3966f764ccce69c0...
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