qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [RFC] Intermediate block mirroring


From: Kevin Wolf
Subject: Re: [Qemu-block] [RFC] Intermediate block mirroring
Date: Thu, 3 May 2018 14:22:41 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 02.05.2018 um 16:12 hat Max Reitz geschrieben:
> On 2018-05-02 15:07, Alberto Garcia wrote:
> > Were the (more or less) exact requirements of QMP blockdev-reopen
> > discussed? How is it different from qemu-io's "reopen" command? What are
> > the options that you can and can not change?
> 
> I can't quite remember, I'm afraid.  I think it was supposed to be
> pretty much qemu-io's reopen (so just bdrv_reopen()).  I suppose you
> cannot change the driver (obviously) or probably the node name, because
> either would result in the node being replaced by a completely new one.
> 
> Other than that, it probably depends on what the block driver supports,
> but ideally you should be able to change everything.

Honestly the design of bdrv_reopen() is quite broken because of the way
it tries to maintain old options if they aren't specified, and guesses
what you might mean when you add flags to the mix. The exact semantics
are quite complicated and I'd rather avoid them in a stable API.

A clean QMP command would probably apply the same defaults as
blockdev-add, so you just get to specify the full options again.

> reopen: You call it like blockdev-add, that is:
>     { "node-name": "overlay",
>       "backing": "new-backing" }
> In theory every option you do not specify is unchanged, so I suppose you
> can leave out e.g. the "driver" option here.

That already doesn't work because "driver" is the discriminator for the
QAPI union, so it must be mandatory. I'd go further and reuse
BlockdevOptions, which makes everything mandatory that is mandatory when
creating the image.

blockdev-reopen would basically mean "replace the whole set of options
of this node".

> Sure, with reopen you can also respecify the whole tree if you so desire
> (so you can get away without blockdev-add'ing new-backing before), but
> you don't have to.

It might be reasonable to forbid inline declarations for BlockdevRef in
blockdev-reopen, so that always have to specify node names instead. On
the other hand, maybe support for inline declarations falls out almost
automatically.

Kevin

Attachment: signature.asc
Description: PGP signature


reply via email to

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