Re: [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blockdev-snapshot-sync

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

Am 31.08.2015 um 22:12 hat Max Reitz geschrieben:
> On 31.08.2015 22:05, Eric Blake wrote:
> > On 08/31/2015 01:53 PM, Max Reitz wrote:
> > 
> >> Design question: Would it make sense to instead add a "reference" mode
> >> to blockdev-snapshot-sync where you can specify a BDS's node-name
> >> instead of snapshot-file to use an existing BDS as the new top layer,
> >> ideally an empty one?
> > 
> > Indeed - then blockdev-add can be used to create an unattached BDS (with
> > all appropriate options), and blockdev-snapshot-sync would then attach
> > that BDS as the snapshot-file that wraps an existing BDS (without
> > needing to worry about options).
> > 
> >>
> >> What we'd then need is a QMP command for creating images. But as far as
> >> I know we'll need that anyway sooner or later...
> > 
> > Can't blockdev-add already be used for that (at least, for supported
> > file types)? If not, what would it take to get it there?
> 
> It would take a blockdev-create-image QMP command. :-)
> 
> blockdev-add only opens existing images, blockdev-create-image would
> then create these so they can be opened using blockdev-add.
> 
> Similar to blockdev-add, it would probably have a single parameter, but
> it'd be of a different type, called e.g. BlockdevCreateOptions, since it
> has to reflect the creation options instead of the runtime options for
> opening existing images. For instance, for qcow2 you could set the
> refcount-bits value, but not the L2 cache size.

Would be nice to have (especially because we would get a schema of the
create options), but not absolutely necessary for a blockdev-* style
snapshotting command. libvirt seems to cope just fine with calling
qemu-img before going to the QMP monitor.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]