I had a brief conversation with Daniel Berrange on IRC this morning regarding race conditions in libvirt's invocation of qemu domains. The preferred approach from qemu's maintainership is using -daemonize at invocation, and then waiting for the process to exit before attempting to connect to the monitor; after this occurs, qemu guarantees monitor availability, so no retry/timeout behavior is necessary. Dan pointed out an issue with this approach: To determine the PID of the qemu instance started, the -pidfile argument to qemu needs to be used with -daemonize. However, -pidfile writes the requested pidfile with qemu's permissions; if the guest were subverted, it could rewrite its pidfile and lead libvirt to kill other, arbitrary processes. Neither changing permissions with -runas rather than prior to invocation nor chown'ing the pidfile from libvirt after creation helps, as qemu keeps a file handle on it open throughout operation (to maintain a POSIX lock on the file). However, a workaround exists, and it meshes well with a security fix which needs to be implemented anyhow: At present, on initial startup or libvirtd restart, we read the PIDs associated with vCPUs from the monitor in virDetectVcpuPIDs(); doing this on libvirtd restart poses a security risk for the reason given above, so we need to have libvirtd record the PIDs on initial startup (before any untrusted code within the guest is ever run) regardless. If we also read the libvirtd pidfile at this same early time (before the guest has been started and thus had an opportunity to run untrusted code) and include its contents when writing out the vCPU PIDs, this would eliminate the issue with pidfile ownership blocking use of -daemonize.