[libvirt] [PATCH 5/5] blockjob: allow for fast-finishing job

Eric Blake eblake at redhat.com
Thu Apr 12 03:48:45 UTC 2012


On 04/11/2012 07:29 PM, Daniel Veillard wrote:
> On Wed, Apr 11, 2012 at 05:40:38PM -0600, Eric Blake wrote:
>> In my testing, I was able to provoke an odd block pull failure:
>>
>> $ virsh blockpull dom vda --bandwidth 10000
>> error: Requested operation is not valid: No active operation on device: drive-virtio-disk0
>>
>> merely by using gdb to artifically wait to do the block job set speed
>> until after the pull had already finished.  But in reality, that should
>> be a success, since the pull finished before we had a chance to set
>> speed.  Furthermore, using a double job lock is annoying; we can alter
>> the speed as part of the same job that started the block pull for less
>> likelihood of hitting the speed failure in the first place.
>>
>> * src/qemu/qemu_monitor.h (BLOCK_JOB_CMD): Add new mode.
>> * src/qemu/qemu_driver.c (qemuDomainBlockRebase): Move secondary
>> job call...
>> (qemuDomainBlockJobImpl): ...here, for fewer locks.
>> * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJob): Change
>> return value on new internal mode.
>> ---

>   ACK, a race we can't really avoid at that level and that's the proper
> handling. Again I'm wondering how we could automate testing for this ...

Again, injecting our own monitor between libvirt and qemu-kvm would make
this a snap to test.  But that will have to be some other day.  For now,
I've gone ahead and pushed this series.

-- 
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/f63993ff/attachment-0001.sig>


More information about the libvir-list mailing list