RFC: esx_driver -- vSphere SOAP API (possibly incompatible) upgrade
Hello, so we found an issue in the ESX driver which is pretty easy to solve, but requires an update to the communication with the server. The newer VI API allows for the instanceUuid parameter when searching for VMs, but only since 4.0, but because we do not send any "SOAPAction:" header it behaves as if we used the oldest one. If we add the header "SOAPAction: urn:vim25/4.0" (at least 4.0) it works, but I'm not sure if there are any incompatibilities and whether there is a use case for older clusters that do not support at least this version. If there is a reasonable use case for it (well, anyone saying "here, me, I'd like to keep it") we could change the behaviour based on the version we parse when connecting to the server. But that's an extra bit of mess, although not totally big one. So I would like to know your opinion on this. Adding few people into Cc who found about the issue. Have a nice day, Martin
On Thu, May 07, 2026 at 03:45:03PM +0200, Martin Kletzander wrote:
Hello,
so we found an issue in the ESX driver which is pretty easy to solve, but requires an update to the communication with the server. The newer VI API allows for the instanceUuid parameter when searching for VMs, but only since 4.0, but because we do not send any "SOAPAction:" header it behaves as if we used the oldest one. If we add the header "SOAPAction: urn:vim25/4.0" (at least 4.0) it works, but I'm not sure if there are any incompatibilities and whether there is a use case for older clusters that do not support at least this version.
If there is a reasonable use case for it (well, anyone saying "here, me, I'd like to keep it") we could change the behaviour based on the version we parse when connecting to the server. But that's an extra bit of mess, although not totally big one.
So I would like to know your opinion on this. Adding few people into Cc who found about the issue.
Do you know how the VI API versions compare to vSphere versions? Basically we only care about vSphere >= 7, so if that still works then we're all good. I believe the MTV server you are using may actually be vSphere 7. Rich.
Have a nice day, Martin
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Thu, May 07, 2026 at 03:45:03PM +0200, Martin Kletzander via Devel wrote:
Hello,
so we found an issue in the ESX driver which is pretty easy to solve, but requires an update to the communication with the server.
What is the actual issue that needs this change ?
The newer VI API allows for the instanceUuid parameter when searching for VMs, but only since 4.0, but because we do not send any "SOAPAction:" header it behaves as if we used the oldest one. If we add the header "SOAPAction: urn:vim25/4.0" (at least 4.0) it works, but I'm not sure if there are any incompatibilities and whether there is a use case for older clusters that do not support at least this version.
As Richard says, it would be nice to understand what version 4.0 corresponds to in terms of vcenter releases ? We have not formally specified what vmware versions we target, but if we take our usual approach to limit our liability, we'd probably want to go for compat with something like the N most recent major versions for low values of "N"
If there is a reasonable use case for it (well, anyone saying "here, me, I'd like to keep it") we could change the behaviour based on the version we parse when connecting to the server. But that's an extra bit of mess, although not totally big one.
Or accept a URI parameter to control compatibility level ? With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
participants (3)
-
Daniel P. Berrangé -
Martin Kletzander -
Richard W.M. Jones