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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list