]> xenbits.xensource.com Git - libvirt.git/commit
blockjob: allow for fast-finishing job
authorEric Blake <eblake@redhat.com>
Wed, 11 Apr 2012 22:28:35 +0000 (16:28 -0600)
committerEric Blake <eblake@redhat.com>
Thu, 12 Apr 2012 03:45:43 +0000 (21:45 -0600)
commita9d3495e67990315ca476dad5369835b43a086db
treef32132ebcb71e26219e1851aaf901b50e27c1ada
parenta91ce852b5a1ee2f9f2cbf0bb47612d429ed531a
blockjob: allow for fast-finishing job

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 not only annoying, but
a bug in itself - if you do parallel virDomainBlockRebase, and hit
the race window just right, the first call grabs the VM job to start
a fast block job, then the second call grabs the VM job to start
a long-running job with unspecified speed, then the first call finally
regrabs the VM job and sets the speed, which ends up running the
second job under the speed from the first call.  By consolidating
things into a single job, we avoid opening that race, as well as reduce
the time between starting the job and changing the speed, for less
likelihood of the speed change happening after block job completion
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.
src/qemu/qemu_driver.c
src/qemu/qemu_monitor.h
src/qemu/qemu_monitor_json.c