Dear Daniel, "Daniel P. Berrange" <berra...@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 <mhart...@linux.vnet.ibm.com> Signed-off-by: Sascha Silbe <si...@linux.vnet.ibm.com> Tested-by: Marc Hartmayer <mhart...@linux.vnet.ibm.com> Reviewed-by: Marc Hartmayer <mhart...@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list