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

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...

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.