[libvirt] [PATCH 2/2] blockjob: properly track blockcopy xml changes on disk
Eric Blake
eblake at redhat.com
Tue Jul 22 12:58:07 UTC 2014
On 07/21/2014 11:38 PM, chen.fan.fnst at cn.fujitsu.com wrote:
> On Mon, 2014-07-21 at 22:34 -0600, Eric Blake wrote:
>> We were not directly saving the domain XML to file after starting
>> or finishing a blockcopy. Without the startup write, a libvirtd
>> restart in the middle of a copy job would forget that the job was
>> underway. Then at pivot, we were indirectly writing new XML in
>> reaction to events that occur as we stop and restart the guest CPUs.
>> But there was a race: since pivot is an async action, it is possible
>> that the guest is restarted before the pivot completes, so if XML
>> changes during the event, that change was not written. The original
>> blockcopy code cleared out the <mirror> element prior to restarting
>> the CPUs, but this is also a race, observed if a user does an async
>> pivot and a dumpxml before the event occurs. Furthermore, this race
>> will interfere with active commit, because that code relies on the
>> <mirror> element at the time of the qemu event to determine whether
>> to inform the user of a normal commit or an active commit.
>> +++ b/src/qemu/qemu_process.c
>> @@ -1016,6 +1016,7 @@ qemuProcessHandleBlockJob(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
>> virObjectEventPtr event2 = NULL;
>> const char *path;
>> virDomainDiskDefPtr disk;
>> + virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
>
> Hello Eric,
> The cfg should be unref by virObjectUnref(cfg) at the end.
You're right. I also discovered I need to write state after a normal
abort. I'll post an updated version, along with a rebase of my patches
to enable active commit.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140722/2e09cfd6/attachment-0001.sig>
More information about the libvir-list
mailing list