On 04/12/2018 07:13 AM, Daniel P. Berrangé wrote:
> On Wed, Apr 11, 2018 at 04:10:03PM -0400, John Ferlan wrote:
>> Before we generate the command line for qemu, if the domain about to
>> be launched desires to utilize the VM Generation ID functionality, then
>> handle both the regenerating the GUID value for backup recovery (restore
>> operation) and the startup after snapshot as well as checking that the
>> genid value that's about to be placed on the command line doesn't
>> duplicate some other already running domain.
>> Signed-off-by: John Ferlan <jfer...@redhat.com>
>> src/qemu/qemu_driver.c | 22 +++++++---
>> src/qemu/qemu_process.c | 110
>> src/qemu/qemu_process.h | 1 +
>> 3 files changed, 126 insertions(+), 7 deletions(-)
>> + /* Now let's make sure the genid this domain has is not duplicitous
>> + * with something else running. */
>> + if (virDomainObjListForEach(driver->domains, qemuProcessCheckGenID, vm)
>> < 0)
>> + return -1;
> Is this really required ? AFAIK, the gen ID merely has to be unique within
> the scope of the installed guest disk image, not amongst all VMs that exist.
> If it was the latter, the check we're doing is pretty weak because it only
> considers one host, not VMs on every other host. IMHO this check is not
> desirable because it adds mutex contention against every guest, into the
> start up path and other code paths too.
Well it wasn't 100% clear from what I read whether it would be required.
I may have misread something along the way too with how/why the value
was being used with Active Directory and perhaps a cloned domain using
(or needing) some mechanism to distinguish between the two.
Still, in rereading the MS GenID paper again uniqueness between two
domains doesn't seem to be required (which is fine by me - I didn't like
the code either) since the AD issues seem to be time based to rolling
back using a snapshot.
libvir-list mailing list