11:30 a.m.
Ever since a041de15 [Update to comply with internal driver API]
changed the code to use virDomain.id instead of _virDomainObj.id
(qemud_vm.id back then) directly, the domain ID retrieved with
virDomainGetID() is incorrect after virDomainCreate() or
virDomainCreateWithFlags() was called. The API consumer has to look up
the domain anew to retrieve the correct ID.
Copy over the ID in qemuDomainCreateWithFlags() so it's correct for
the existing domain instance, too.
Fixes: a041de15 ("Update to comply with internal driver API")
Reported-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
Signed-off-by: Sascha Silbe <silbe(a)linux.vnet.ibm.com>
Tested-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
---
src/qemu/qemu_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index cda85f6..6929b23 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7100,6 +7100,7 @@ qemuDomainCreateWithFlags(virDomainPtr dom, unsigned int flags)
QEMU_ASYNC_JOB_START) < 0)
goto endjob;
+ dom->id = vm->def->id;
ret = 0;
endjob:
--
1.9.1
12:31 p.m.
On Fri, Jul 15, 2016 at 06:30:32PM +0200, Sascha Silbe wrote:
Ever since a041de15 [Update to comply with internal driver API]
changed the code to use virDomain.id instead of _virDomainObj.id
(qemud_vm.id back then) directly, the domain ID retrieved with
virDomainGetID() is incorrect after virDomainCreate() or
virDomainCreateWithFlags() was called. The API consumer has to look up
the domain anew to retrieve the correct ID.
Err no. The src/remote_driver.c remoteDomainCreate method will
call virDomainLookupByUUID to fetch the updated id. The dom->id
value in the QEMU driver is never used because that virDomainPtr
instance only exists for the life of the virDomainCreate API
call on the server side and is never seen by the client.
Copy over the ID in qemuDomainCreateWithFlags() so it's correct for
the existing domain instance, too.
Fixes: a041de15 ("Update to comply with internal driver API")
Reported-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
Signed-off-by: Sascha Silbe <silbe(a)linux.vnet.ibm.com>
Tested-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
---
src/qemu/qemu_driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index cda85f6..6929b23 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7100,6 +7100,7 @@ qemuDomainCreateWithFlags(virDomainPtr dom, unsigned int flags)
QEMU_ASYNC_JOB_START) < 0)
goto endjob;
+ dom->id = vm->def->id;
ret = 0;
endjob:
--
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
2:04 p.m.
Dear Daniel,
"Daniel P. Berrange" <berrange(a)redhat.com> writes:
On Fri, Jul 15, 2016 at 06:30:32PM +0200, Sascha Silbe wrote:
> Ever since a041de15 [Update to comply with internal driver API]
> changed the code to use virDomain.id instead of _virDomainObj.id
> (qemud_vm.id back then) directly, the domain ID retrieved with
> virDomainGetID() is incorrect after virDomainCreate() or
> virDomainCreateWithFlags() was called. The API consumer has to look up
> the domain anew to retrieve the correct ID.
Err no. The src/remote_driver.c remoteDomainCreate method will
call virDomainLookupByUUID to fetch the updated id. The dom->id
value in the QEMU driver is never used because that virDomainPtr
instance only exists for the life of the virDomainCreate API
call on the server side and is never seen by the client.
You are right; remoteDomainCreate() actually does that, only
remoteDomainCreateWithFlags() copies the ID from the
REMOTE_PROC_DOMAIN_CREATE_WITH_FLAGS response. So on the client side
it's only broken for virDomainCreateWithFlags(), not for
virDomainCreate(). This also means it wasn't a041de15 that broke things
but rather virDomainCreateWithFlags() was broken from the start
(introduced in de3aadaa) for several drivers. This sheds a slightly
different light on the issue; I could even find several commits that
fixed this issue for some of the drivers.
Updated commit message:
=== Begin ===
qemu: fix domain id after domainCreateWithFlags()
Ever since virDomainCreateWithFlags() was introduced by de3aadaa
[drivers: add virDomainCreateWithFlags if virDomainCreate exists], the
domain ID retrieved with virDomainGetID() was incorrect for several
drivers after virDomainCreateWithFlags() was called. The API consumer
had to look up the domain anew to retrieve the correct ID.
For the ESX driver, this was fixed in 6139b274 [esx: Update ID after
starting a domain]. For the openvz driver, it was fixed in fd81a097
[openvzDomainCreateWithFlags: set domain id to the correct value]. The
test driver, the OpenNebula driver (removed in the meantime) and the
vbox driver were already updating the domain ID correctly in
domainCreate().
Copy over the ID in qemuDomainCreateWithFlags() to fix this for the qemu
driver, too.
Fixes: a041de15 ("Update to comply with internal driver API")
Reported-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
Signed-off-by: Sascha Silbe <silbe(a)linux.vnet.ibm.com>
Tested-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com>
=== End ===
The LXC driver looks like it still has the same bug, but I don't have a
suitable test environment for it right now. Not sure about the UML
driver; I couldn't quickly grok when exactly is assigns the id. For the
Xen driver, it looks like IDs are persistent (so
xenapiDomainCreateWithFlags() should be fine), but
xenapiDomainDefineXML() forgots to set the id but isn't. Again, I lack a
suitable test environment.
Do you want me to send a v2 with the updated commit message?
Sascha
--
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr. DE281696641
3055
days inactive
3055
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Sascha Silbe