[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] [RFC] Intermediate block mirroring
From: |
Eric Blake |
Subject: |
Re: [Qemu-block] [Qemu-devel] [RFC] Intermediate block mirroring |
Date: |
Thu, 02 Apr 2015 10:56:09 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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
signature.asc
Description: OpenPGP digital signature