From: "Daniel P. Berrange" <berrange(a)redhat.com&gt; When starting a transient VM the first thing done is to check for duplicates. The check looks if there are any running VMs with the matching name/uuid. It explicitly allows there to be inactive VMs, so that a persistent VM can be temporarily booted with a different config. There is a race condition, however, where 2 or more clients try to create the same transient VM. The first client will cause a virDomainObjPtr to be added to the domain list, and it is inactive at this stage. The second client may then come along and see this inactive VM, and mistake it for a persistent VM. If the first VM fails to start its transient guest for any reason, then it'll remove the virDomainObjPtr from the list. The second client now has a virDomainObjPtr that it can try to boot, which libvirt no longer has a record of. The result can be a running QEMU process that is orphaned. It was also, however, possible for the virDomainObjPtr to be completely free'd which will cause libvirtd to crash in some scenarios. The fix is to only allow an existing inactive VM if it is marked as persistent. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com&gt; --- src/conf/domain_conf.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 51c4e29..454fbfe 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2171,6 +2171,12 @@ virDomainObjListAddLocked(virDomainObjListPtr doms, vm->def->name); goto error; } + if (!vm->persistent) { + virReportError(VIR_ERR_OPERATION_INVALID, + _("domain is being started as '%s'"), + vm->def->name); + goto error; + } } virDomainObjAssignDef(vm, -- 1.8.3.1