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: de3aadaa ("drivers: add virDomainCreateWithFlags if virDomainCreate exists") Reported-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com&gt; Signed-off-by: Sascha Silbe <silbe(a)linux.vnet.ibm.com&gt; Tested-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com&gt; Reviewed-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com&gt; --- v1→v2: - Adjusted commit message. remoteDomainCreate() is actually fine since it explicitly queries the ID in a second RPC, only remoteDomainCreateWithFlags() is broken. Found and mentioned several other commits that fixed this for several of the other hypervisor drivers. 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 1820f85..43242e0 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