> Currently the ESX driver uses only functions and objects from the
> vSphere API 2.5 (at least it should). This allows it to deal with
> older ESX server versions down to 3.5. What you're trying to do now is
> using functions added in a newer vSphere API, don't you? I assume that
> all the field
2012/12/31 Ata Bohra :
> Please hold off reviews on this post. I've been testing and analyzing some
> other piece of code (the one that do not need connection headers to include
> urn:vim25 namespace), but I observed that this namespace include causes lot
> of other issues such as:
> 1. It breaks e
Please hold off reviews on this post. I've been testing and analyzing some
other piece of code (the one that do not need connection headers to include
urn:vim25 namespace), but I observed that this namespace include causes lot of
other issues such as:1. It breaks existing APIs due to ordering is
Append curl headers with "SOAPAction" header to populate
serviceContent object entities which are otherwise missing.
---
src/esx/esx_vi.c |2 ++
src/esx/esx_vi_generator.input |3 +++
2 files changed, 5 insertions(+)
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
index 99c
It seems with current SOAP header the call to retrieve "serviceContent" object
does not populate all available references (for instance: ovfManager). The host
exposes details of these Managed Object References (MoBs) if header is appended
with "SOAPACtion" field.
Ata E Husain Bohra (1):
ESX: app
