[Qemu-devel] [RFC] Intermediate block mirroring

[Qemu-devel] [RFC] Intermediate block mirroring

[Alberto Garcia]

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 image and [X] would be a copy of [C]. The
latter would be unlinked from the chain.

A use case would be to move disk images across different storage
backends.

My idea is to extend the drive-mirror command. Similar to what we
discussed in the case of the intermediate block streaming, I can reuse
the 'device' parameter to refer to a node name. So the API doesn't
need any changes other than the extended semantics for this parameter.

One difference with the current functionality is that once the block
job is completed, the node above the mirrored one would have to change
its backing image to point to the new one. One solution is to iterate
over all devices (bdrv_next()) and check which ones are connected
directly or indirectly to the mirrored node (bdrv_find_overlay()).

drive-mirror has three different sync modes: top, full and none. This
would be the chain from the example using each one of these modes:

  top:

     [A] -> [B] -> [X] -> [D]

  full:

     [X] -> [D]

  none:

     [A] -> [B] -> [C] -> [X] -> [D]

My understanding is that in the 'sync=full' case, [A] and [B] would
also need to be blocked during the operation since they are going to
disappear from the chain.

I have some code and in principle everything seems to be working fine,
but I'd like to test it a bit more.

What's anyway your opinion about this proposal?

Thanks,

Berto

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

[Eric Blake]

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

On 04/02/2015 07:28 AM, 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] -> [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 unlinked from the chain.

Seems useful, if for no other reason than to be another tool in the
arsenal of low-level manipulations that can be strung together for cool
high-level operations.

> 
> A use case would be to move disk images across different storage
> backends.
> 
> My idea is to extend the drive-mirror command. Similar to what we
> discussed in the case of the intermediate block streaming, I can reuse
> the 'device' parameter to refer to a node name. So the API doesn't
> need any changes other than the extended semantics for this parameter.
> 
> One difference with the current functionality is that once the block
> job is completed, the node above the mirrored one would have to change
> its backing image to point to the new one. One solution is to iterate
> over all devices (bdrv_next()) and check which ones are connected
> directly or indirectly to the mirrored node (bdrv_find_overlay()).
> 
> drive-mirror has three different sync modes: top, full and none. This
> would be the chain from the example using each one of these modes:
> 
>   top:
> 
>      [A] -> [B] -> [X] -> [D]

That is, X becomes the mirror of C, and then a later command lets us
rebase D onto X (since we know the guest-visible contents accessible
from X and C are identical).

> 
>   full:
> 
>      [X] -> [D]

That is, X becomes the mirror of the full chain A through C, and then a
later command lets us rebase D onto X (since we know the guest-visible
contents accessible from X and C are identical).

> 
>   none:
> 
>      [A] -> [B] -> [C] -> [X] -> [D]

That is, X becomes a new file that tracks changes made since a point in
time which are also going into C; and if we desire we can issue a later
command to rebase D onto X (since we know the guest-visible contents
accessible from X and C are identical at that time), and even later
start cleaning up C (we could use dirty bitmaps to see what got moved
into X to clean those sectors out of C and reduce its size)

> 
> My understanding is that in the 'sync=full' case, [A] and [B] would
> also need to be blocked during the operation since they are going to
> disappear from the chain.
> 
> I have some code and in principle everything seems to be working fine,
> but I'd like to test it a bit more.
> 
> What's anyway your opinion about this proposal?

Certainly seems like something worth having.  The devil may be in the
details, but we can get there when you post proposed patches.

> 
> Thanks,
> 
> Berto
> 
> 
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Stefan Hajnoczi]

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

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] -> [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 unlinked from the chain.
> 
> A use case would be to move disk images across different storage
> backends.

The simple solution to that problem is:

Assumption: backing files are read only.  (True in most cases.)

1. Copy the backing files using cp(1) or another method.
2. Issue QMP 'change-backing-file' command so that [D] uses [X] instead
   of [C].

So it can be done today already.

Note that the management tool needs to enforce the assumption since QEMU
cannot know whether other programs or QEMU instances are modifying one
of the backing files.

Stefan

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

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

[Alberto Garcia]

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 unlinked from the chain.
> > 
> > A use case would be to move disk images across different storage
> > backends.
> 
> The simple solution to that problem is:
> 
> Assumption: backing files are read only.  (True in most cases.)
> 
> 1. Copy the backing files using cp(1) or another method.
> 2. Issue QMP 'change-backing-file' command so that [D] uses [X] instead
>    of [C].
> 
> So it can be done today already.

So do you think it would be better to implement this somewhere else?
The code that I have for QEMU is quite simple, the actual algorithm
doesn't change, it only needs to do the changing of backing files in
mirror_exit().

Berto

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

[Stefan Hajnoczi]

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

On Thu, Apr 09, 2015 at 02:40:00PM +0200, Alberto Garcia wrote:
> 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 unlinked from the chain.
> > > 
> > > A use case would be to move disk images across different storage
> > > backends.
> > 
> > The simple solution to that problem is:
> > 
> > Assumption: backing files are read only.  (True in most cases.)
> > 
> > 1. Copy the backing files using cp(1) or another method.
> > 2. Issue QMP 'change-backing-file' command so that [D] uses [X] instead
> >    of [C].
> > 
> > So it can be done today already.
> 
> So do you think it would be better to implement this somewhere else?
> The code that I have for QEMU is quite simple, the actual algorithm
> doesn't change, it only needs to do the changing of backing files in
> mirror_exit().

I'll take a look at your patch series, maybe there are advantages to
doing it within QEMU.

Stefan

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

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

[Kevin Wolf]

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

Am 10.04.2015 um 11:56 hat Stefan Hajnoczi geschrieben:
> On Thu, Apr 09, 2015 at 02:40:00PM +0200, Alberto Garcia wrote:
> > 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 unlinked from the chain.
> > > > 
> > > > A use case would be to move disk images across different storage
> > > > backends.
> > > 
> > > The simple solution to that problem is:
> > > 
> > > Assumption: backing files are read only.  (True in most cases.)
> > > 
> > > 1. Copy the backing files using cp(1) or another method.
> > > 2. Issue QMP 'change-backing-file' command so that [D] uses [X] instead
> > >    of [C].
> > > 
> > > So it can be done today already.
> > 
> > So do you think it would be better to implement this somewhere else?
> > The code that I have for QEMU is quite simple, the actual algorithm
> > doesn't change, it only needs to do the changing of backing files in
> > mirror_exit().
> 
> I'll take a look at your patch series, maybe there are advantages to
> doing it within QEMU.

If the patches are simple, I think consistency and avoiding arbitrary
restrictions are good enough reasons for having the support in qemu.
Eventually we want all nodes to be equal anyway.

Kevin

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