qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevO


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blockdev-snapshot-sync
Date: Mon, 31 Aug 2015 22:12:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]