On Mon 11 Jun 2018 02:20:06 PM CEST, Kevin Wolf wrote:
> Am 01.06.2018 um 12:51 hat Alberto Garcia geschrieben:
>> On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf wrote:
>> >> > Were the (more or less) exact requirements of QMP blockdev-reopen
>> >> > discussed? How is it different from qemu-io's "
Am 01.06.2018 um 12:51 hat Alberto Garcia geschrieben:
> On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf 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 an
On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf 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
On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf wrote:
> 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-b
On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf wrote:
> 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 a
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 c
On Wed 02 May 2018 04:12:49 PM CEST, Max Reitz wrote:
> On 2018-05-02 15:07, Alberto Garcia wrote:
>> On Wed 25 Apr 2018 04:03:22 PM CEST, Max Reitz wrote:
> But the question stands whether we need simple node replacement when
> we want bdrv_reopen() anyway. In addition, we don't need just
On 2018-05-02 15:07, Alberto Garcia wrote:
> On Wed 25 Apr 2018 04:03:22 PM CEST, Max Reitz wrote:
But the question stands whether we need simple node replacement when
we want bdrv_reopen() anyway. In addition, we don't need just
replacement, we also need addition and removal (e.g.
On Wed 25 Apr 2018 04:03:22 PM CEST, Max Reitz wrote:
>>> But the question stands whether we need simple node replacement when
>>> we want bdrv_reopen() anyway. In addition, we don't need just
>>> replacement, we also need addition and removal (e.g. for backing
>>> files or quorum children) -- and
On 2018-04-25 15:42, Alberto Garcia wrote:
> On Wed 25 Apr 2018 03:06:34 PM CEST, Max Reitz wrote:
> One other way is to have a more generic replace-node command
> which would call bdrv_replace_node(), but I don't know if we
> want to expose that and I don't have any other u
On Wed 25 Apr 2018 03:06:34 PM CEST, Max Reitz wrote:
One other way is to have a more generic replace-node command
which would call bdrv_replace_node(), but I don't know if we
want to expose that and I don't have any other use case for it
at the moment.
>>>
>
On 2018-04-25 14:58, Alberto Garcia wrote:
> On Fri 20 Apr 2018 03:13:49 PM CEST, Max Reitz wrote:
>>> One other way is to have a more generic replace-node command
>>> which would call bdrv_replace_node(), but I don't know if we want
>>> to expose that and I don't have any other use cas
On Fri 20 Apr 2018 03:13:49 PM CEST, Max Reitz wrote:
>> One other way is to have a more generic replace-node command
>> which would call bdrv_replace_node(), but I don't know if we want
>> to expose that and I don't have any other use case for it at the
>> moment.
>
> I thi
On 2018-04-18 17:34, Alberto Garcia wrote:
> On Mon 16 Apr 2018 05:15:21 PM CEST, Max Reitz wrote:
>> On 2018-04-16 16:59, Alberto Garcia wrote:
>>> On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote:
On 2018-04-12 19:07, Alberto Garcia wrote:
> Hello,
>
> I mentioned this some t
On Mon 16 Apr 2018 05:15:21 PM CEST, Max Reitz wrote:
> On 2018-04-16 16:59, Alberto Garcia wrote:
>> On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote:
>>> On 2018-04-12 19:07, Alberto Garcia wrote:
Hello,
I mentioned this some time ago, but I'd like to retake it now: I'm
ch
On 2018-04-16 16:59, Alberto Garcia wrote:
> On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote:
>> On 2018-04-12 19:07, Alberto Garcia wrote:
>>> Hello,
>>>
>>> I mentioned this some time ago, but I'd like to retake it now: I'm
>>> checking how to copy arbitrary nodes on a backing chain, so if I
On Fri 13 Apr 2018 04:23:07 PM CEST, Max Reitz wrote:
> On 2018-04-12 19:07, Alberto Garcia wrote:
>> Hello,
>>
>> I mentioned this some time ago, but I'd like to retake it now: I'm
>> checking how to copy arbitrary nodes on a backing chain, so if I have
>> e.g.
>>
>>[A] <- [B] <- [C] <- [D]
On 2018-04-12 19:07, Alberto Garcia wrote:
> Hello,
>
> I mentioned this some time ago, but I'd like to retake it now: I'm
> checking how to copy arbitrary nodes on a backing chain, so if I have
> e.g.
>
>[A] <- [B] <- [C] <- [D]
>
> I'd like to end up with
>
>[A] <- [E] <- [C] <- [D]
>
Hello,
I mentioned this some time ago, but I'd like to retake it now: I'm
checking how to copy arbitrary nodes on a backing chain, so if I have
e.g.
[A] <- [B] <- [C] <- [D]
I'd like to end up with
[A] <- [E] <- [C] <- [D]
where [E] is a copy of [B]. The most obvious use case is to move
On Thu, Apr 09, 2015 at 11:39:28AM +0100, Stefan Hajnoczi wrote:
> > The goal would be to convert this:
> >
> >[A] -> [B] -> [C] -> [D]
> >
> > into this:
> >
> >[A] -> [B] -> [X] -> [D]
> >
> > where [D] is the active image and [X] would be a copy of [C]. The
> > latter would be unlin
On Thu, Apr 02, 2015 at 03:28:57PM +0200, Alberto Garcia wrote:
> Hi,
>
> I'm interested in adding the possibility to mirror an intermediate
> node in a disk image chain, but I would like to have some feedback
> before sending any patches.
>
> The goal would be to convert this:
>
>[A] -> [B]
Hi,
I'm interested in adding the possibility to mirror an intermediate
node in a disk image chain, but I would like to have some feedback
before sending any patches.
The goal would be to convert this:
[A] -> [B] -> [C] -> [D]
into this:
[A] -> [B] -> [X] -> [D]
where [D] is the active i
22 matches
Mail list logo
