[libvirt] [PATCH 4/5] blockjob: wire up qemu async virDomainBlockJobAbort

[Eric Blake]

On 04/11/2012 07:26 PM, Daniel Veillard wrote:
> On Wed, Apr 11, 2012 at 05:40:37PM -0600, Eric Blake wrote:
>> Without the VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC flag, libvirt will internally
>> poll using qemu's "query-block-jobs" API and will not return until the
>> operation has been completed.  API users are advised that this operation
>> is unbounded and further interaction with the domain during this period
>> may block.  Future patches may refactor things to allow other queries in
>> parallel with this polling.  For older qemu, we synthesize the cancelation
>> event, since qemu won't generate it.
>>

>> +                static struct timespec ts = { .tv_sec = 0,
>> +                                              .tv_nsec = 50 * 1000 * 1000ull };
>> +                virDomainBlockJobInfo dummy;
>> +
>> +                qemuDomainObjEnterMonitorWithDriver(driver, vm);
>> +                ret = qemuMonitorBlockJob(priv->mon, device, NULL, 0, &dummy,
>> +                                          BLOCK_JOB_INFO, async);
>> +                qemuDomainObjExitMonitorWithDriver(driver, vm);
>> +
>> +                if (ret <= 0)
>> +                    break;
>> +
>> +                virDomainObjUnlock(vm);
>> +                qemuDriverUnlock(driver);
>> +
>> +                nanosleep(&ts, NULL);
> 
>   Okay, I was wondering how to justify the arbitrary 50ms, we use the
> same value on migration for potential user input. It's slightly over
> the human perception delay, but for those kind of operation that
> sounds fine...

Yep, copy and paste from qemu_migration.c; I've updated the commit
message to mention that.

> 
>   ACK, I was wondering how we could test for those events but since this
> requires an actual qemu-kvm process we really can't implement it as
> part of the existing python event test program.

We should really revive the patch series that allow us to hook up our
own process on the other end of the monitor, rather than needing a
qemu-kvm process, so that we can spoon-feed our own JSON and under our
own speed control.  In particular, I have _no_ idea how long a block job
cancellation is expected to take, to know how many times this will loop.
 I suspect that the bigger disk you have, with more data that needs
flushing, is enough to start triggering this, but in all my simple
testing, I never got past a second iteration.

-- 
Eric Blake   eblake at 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: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120411/e3c75135/attachment-0001.sig>