Fix race condition reconnecting to vms & loading configs

The following sequence

 1. Define a persistent QMEU guest
 2. Start the QEMU guest
 3. Stop libvirtd
 4. Kill the QEMU process
 5. Start libvirtd
 6. List persistent guests

At the last step, the previously running persistent guest
will be missing. This is because of a race condition in the
QEMU driver startup code. It does

 1. Load all VM state files
 2. Spawn thread to reconnect to each VM
 3. Load all VM config files

Only at the end of step 3, does the 'virDomainObjPtr' get
marked as "persistent". There is therefore a window where
the thread reconnecting to the VM will remove the persistent
VM from the list.

The easy fix is to simply switch the order of steps 2 & 3.

In addition to this though, we must only attempt to reconnect
to a VM which had a non-zero PID loaded from its state file.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit f26701f565525dd402df021d8923489e62412158)
This commit is contained in:
Daniel P. Berrange 2013-10-28 11:49:18 +00:00 committed by Cole Robinson
parent 5ddb57e01e
commit b044210ed2
2 changed files with 4 additions and 2 deletions

View File

@ -811,8 +811,6 @@ qemuStateInitialize(bool privileged,
conn = virConnectOpen(cfg->uri);
qemuProcessReconnectAll(conn, qemu_driver);
/* Then inactive persistent configs */
if (virDomainObjListLoadAllConfigs(qemu_driver->domains,
cfg->configDir,
@ -823,6 +821,7 @@ qemuStateInitialize(bool privileged,
NULL, NULL) < 0)
goto error;
qemuProcessReconnectAll(conn, qemu_driver);
virDomainObjListForEach(qemu_driver->domains,
qemuDomainSnapshotLoad,

View File

@ -3253,6 +3253,9 @@ qemuProcessReconnectHelper(virDomainObjPtr obj,
struct qemuProcessReconnectData *src = opaque;
struct qemuProcessReconnectData *data;
if (!obj->pid)
return 0;
if (VIR_ALLOC(data) < 0)
return -1;