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