mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-22 20:45:18 +00:00
d047b2d983
Failure to attach to a domain during 'virsh qemu-attach' left the list of domains in an odd state: $ virsh qemu-attach 4176 error: An error occurred, but the cause is unknown $ virsh list --all Id Name State ---------------------------------------------------- 2 foo shut off $ virsh qemu-attach 4176 error: Requested operation is not valid: domain is already active as 'foo' $ virsh undefine foo error: Failed to undefine domain foo error: Requested operation is not valid: cannot undefine transient domain $ virsh shutdown foo error: Failed to shutdown domain foo error: invalid argument: monitor must not be NULL It all stems from leaving the list of domains unmodified on the initial failure; we should follow the lead of createXML which removes vm on failure (the actual initial failure still needs to be fixed in a later patch, but at least this patch gets us to the point where we aren't getting stuck with an unremovable "shut off" transient domain). While investigating, I also found a leak in qemuDomainCreateXML; the two functions should behave similarly. Note that there are still two unusual paths: if dom is not allocated, the user will see an OOM error even though the vm remains registered (but oom errors already indicate tricky cleanup); and if the vm starts and then quits again all before the job ends, it is possible to return a non-NULL dom even though the dom will no longer be useful for anything (but this at least lets the user know their short-lived vm ran). * src/qemu/qemu_driver.c (qemuDomainCreateXML): Don't leak vm on failure to obtain job. (qemuDomainQemuAttach): Match cleanup of qemuDomainCreateXML. Signed-off-by: Eric Blake <eblake@redhat.com>
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>