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
pgptucKCxbenC.pgp
Description: PGP signature
