On Fri, Apr 26, 2013 at 04:58:24PM -0600, Eric Blake wrote: > On 04/23/2013 10:25 AM, Stefan Hajnoczi wrote: > > @block-backup > > > > Start a point-in-time copy of a block device to a new destination. > > > > @device: the name of the device whose writes should be mirrored. > > > > @target: the target of the new image. If the file exists, or if it > > is a device, the existing file/device will be used as the new > > destination. If it does not exist, a new file will be created. > > > > @format: #optional the format of the new destination, default is to > > probe if @mode is 'existing', else the format of the source > > > > @mode: #optional whether and how QEMU should create a new image, default is > > 'absolute-paths'. > > > > @speed: #optional the maximum speed, in bytes per second > > > > Returns: nothing on success > > If @device is not a valid block device, DeviceNotFound > > This starts a new block job type; I assume the existing block-job-cancel > and query-block-jobs can track it.
Right. I will update the documentation to be explicit about the block job that this command creates. > I'd really love to see us change 'BlockJobInfo' to use an enum for > 'type', instead of its open-coded 'str'. Likewise, the block-job > related events in QMP/qmp-events.txt should be updated to refer to the > enum instead of also being open-coded 'str'. Since the block job QMP API has been in released I'm not sure changing this is worthwhile. QEMU and libvirt would have to maintain compatibility so the code will just be duplicated. > Will this job be called "backup"? Yes, it is called "backup".