[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]