The difference is that the usual UUID is supposed to be unique per host
and instanceUuid should be unique across the whole cluster. One could
think of them as HUID and CUID (as the first "U" does apparently mean
something else in the Broadcom world). That _would_ be fine for our
scenario. However, that piece of information turns out to be false as
well and the UUID we were using (`config.uuid`, or in VMX the
`uuid.bios`) can be the same in two machines on the same host.
Fortunately the `FindByUuid()` function can also search for VMs based on
their `instanceUuid`, dictated by the so far omitted third parameter.
Unfortunately that parameter is not parsed (or at least properly) before
vSphere API 4.0 (the documentation says 2.0, but we are not using that
namespace and 4.0 is the lowest we can target), which we are not
specifying in the server returns a 500 HTTP error if we use the
`instanceUuid` parameter.
So this patch adds the `SOAPAction: urn:vim25/4.0` header to the cURL
requests which makes that `FindByUuid()` function work even with the
`instanceUuid` set, but without any extra labor.
After that this patch also changes all UUIDs to be parsed from the
`config.instanceUuid` (or `vc.uuid` in the VMX, but there's a fallback
to the old `uuid.bios`) and adjusts tests accordingly.
To give users (and management applications) the possibility to revert
back to the previous (legacy) behaviour a new URI query parameter is
introduced, called `legacy_uuid` which, if set to `1`, still keeps the
code working as it did before this patch.
Last, but not least it changes the parameter to aforementioned function
to be true (unless the legacy behaviour is requested, of course) and
henceforth all searching ought to be done with the more unique ID.
Resolves: https://redhat.atlassian.net/browse/RHEL-174300
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Martin Kletzander
ac2d865eda
