<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> <br>> Currently the ESX driver uses only functions and objects from the<br>> vSphere API 2.5 (at least it should). This allows it to deal with<br>> older ESX server versions down to 3.5. What you're trying to do now is<br>> using functions added in a newer vSphere API, don't you? I assume that<br>> all the fields and functions you're talking about, that require the<br>> SOAPAction header, were added in vSphere API 4.0 or later.<br>> <br>> Is it documented somewhere that you need to pass the SOAPAction header<br>> to the server in order to access vSphere API > 2.5 features?<br>> <br>> But the real problem could be the serialization order. If this is<br>> really different between vSphere API 2.5 and 4.x than we need to<br>> decide this at runtime and also extend the generator to know bot<br>> orderings. This can become very ugly.<br><BR>After going back n forth on options, I found that limiting header modification to one-two functions may not hurt that bad. This is what I am doing at the moment: inside the desired function:<BR>1. instantiate the a new header (curl_slist *header) and populate it with desired fields.<BR>2. Replace priv->primary->curl->header with new header (preserving the old one)<BR>3. As part of cleanup revert back old header item to priv->primary->curl. <BR> <BR>This way I was able to limit the impact of API version change to a routine, else it was getting real messy to make it certain that nothing existing will break elsewhere. <BR> <BR>Thanks!<BR>Ata<br> <br>> > Thanks !<br>> > Ata<br>> ><br>> >> From: ata.husain@hotmail.com<br>> >> To: libvir-list@redhat.com<br>> >> CC: ata.husain@hotmail.com<br>> >> Subject: [PATCH] ESX: append CURL headers to fix serviceContent entities<br>> >> Date: Tue, 25 Dec 2012 16:44:23 -0800<br>> ><br>> >><br>> >> Append curl headers with "SOAPAction" header to populate<br>> >> serviceContent object entities which are otherwise missing.<br>> >> ---<br>> >> src/esx/esx_vi.c | 2 ++<br>> >> src/esx/esx_vi_generator.input | 3 +++<br>> >> 2 files changed, 5 insertions(+)<br>> >><br>> >> diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c<br>> >> index 99c1eb1..a379183 100644<br>> >> --- a/src/esx/esx_vi.c<br>> >> +++ b/src/esx/esx_vi.c<br>> >> @@ -322,6 +322,8 @@ esxVI_CURL_Connect(esxVI_CURL *curl, esxUtil_ParsedUri<br>> >> *parsedUri)<br>> >> * approx. 2 sec per POST operation.<br>> >> */<br>> >> curl->headers = curl_slist_append(curl->headers, "Expect:");<br>> >> + curl->headers = curl_slist_append(curl->headers,<br>> >> + _("SOAPAction: \"urn:vim25\""));<br>> >><br>> >> if (curl->headers == NULL) {<br>> >> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",<br>> >> diff --git a/src/esx/esx_vi_generator.input<br>> >> b/src/esx/esx_vi_generator.input<br>> >> index 22c114e..236dcb3 100644<br>> >> --- a/src/esx/esx_vi_generator.input<br>> >> +++ b/src/esx/esx_vi_generator.input<br>> >> @@ -1008,6 +1008,8 @@ object ServiceContent<br>> >> ManagedObjectReference clusterProfileManager<br>> >> o<br>> >> ManagedObjectReference complianceManager<br>> >> o<br>> >> ManagedObjectReference localizationManager<br>> >> o<br>> >> + ManagedObjectReference storageResourceManager<br>> >> o<br>> >> + ManagedObjectReference guestOperationsManager<br>> >> o<br>> >> end<br>> >><br>> >><br>> >> @@ -1073,6 +1075,7 @@ object UserSession<br>> >> DateTime lastActiveTime<br>> >> r<br>> >> String locale r<br>> >> String messageLocale r<br>> >> + Boolean extensionSession<br>> >> o<br>> >> end<br>> >><br>> >><br>> >> --<br>> >> 1.7.9.5<br>> >><br>> ><br>> > --<br>> > libvir-list mailing list<br>> > libvir-list@redhat.com<br>> > https://www.redhat.com/mailman/listinfo/libvir-list<br>> <br>> <br>> <br>> -- <br>> Matthias Bolte<br>> http://photron.blogspot.com<br><BR> </div></body>
</html>