Patchwork [8/8] docs: add mirroring to live block operations

login
register
mail settings
Submitter Paolo Bonzini
Date April 13, 2012, 4:23 p.m.
Message ID <1334334198-30899-9-git-send-email-pbonzini@redhat.com>
Download mbox | patch
Permalink /patch/152344/
State New
Headers show

Comments

Paolo Bonzini - April 13, 2012, 4:23 p.m.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 docs/live-block-ops.txt |   38 +++++++++++++++++++++++++++++++-------
 1 file changed, 31 insertions(+), 7 deletions(-)
Eric Blake - April 13, 2012, 5:09 p.m.
On 04/13/2012 10:23 AM, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/live-block-ops.txt |   38 +++++++++++++++++++++++++++++++-------
>  1 file changed, 31 insertions(+), 7 deletions(-)
> 

>  
> +Live block migration
> +====================
> +
> +Migrating an in use image to another destination in the filesystem
> +is done through image mirroring.  The idea is to execute
> +'drive_mirror virtio0 /new-path/disk.img qcow2' while the guest
> +is running.  The topmost image ([D] in the example above) will
> +be copied to the given path, and the two can be kept in sync.
> +
> +Progress can be monitored using 'info block-jobs'.  Once this command
> +reports something like

maybe: s/reports something like/reports completion equal to size, as in/

> +
> +  Type mirror, device virtio0: Completed 1048576000 of 1048576000 bytes
> +
> +it is possible to switch to the destination using
> +
> +(qemu) drive_reopen virtio0 /new-path/disk.img
> +
> +This assumes that all images A/B/C are also present under /new-path
> +or.  An image can be omitted from the destination if one of the images

Dangling sentence.

> +refers to its backing file using an absolute path.

I think you need to rework this paragraph.  It sounds like you are
trying to state whether /new-path/disk.img will have an absolute backing
file path (in which case, it is reusing C, and therefore A and B, from
the same locations found when originally opening D), or whether
/new-path/disk.img will have a relative backing path (this would be
either through a relative-paths mode option, or through the reuse of an
existing file intentionally created with a relative backing path), in
which case the reopen now resolves the backing path locally so A, B, and
C must all be present at /new-path for the reopen to succeed.

> +
> +
>  Live block copy
>  ===============
>  
>  To copy an in use image to another destination in the filesystem, one
> -should create a live snapshot in the desired destination, then stream
> -into that image. Example:
> -
> -(qemu) snapshot_blkdev ide0-hd0 /new-path/disk.img qcow2
> +can also use mirroring with the -f option.
>  
> -(qemu) block_stream ide0-hd0
> +(qemu) drive_mirror -f virtio0 /new-path/disk.img qcow2
>  
> +Note that if one image in the chain is in raw format, the
> +resulting copy might not be thin-provisioned anymore, depending on
> +the underlying file system.
>  
> +It is also possible to use raw as the format of the destination image.
> +Converting an image to raw will properly support thin provisioning.

Do you need to mention the use of block_job_cancel needed at the point
where you are ready to stop qemu from writing into the copy?
Paolo Bonzini - April 13, 2012, 5:32 p.m.
Il 13/04/2012 19:09, Eric Blake ha scritto:
>> > +It is also possible to use raw as the format of the destination image.
>> > +Converting an image to raw will properly support thin provisioning.
> Do you need to mention the use of block_job_cancel needed at the point
> where you are ready to stop qemu from writing into the copy?

No, you need to do this with drive-reopen.  Using block_job_cancel will
report completion, but will leave a race window that can cause to
corruption in the guest.  Do your libvirt patches do that? O:)

Paolo
Eric Blake - April 13, 2012, 6:05 p.m.
On 04/13/2012 11:32 AM, Paolo Bonzini wrote:
> Il 13/04/2012 19:09, Eric Blake ha scritto:
>>>> +It is also possible to use raw as the format of the destination image.
>>>> +Converting an image to raw will properly support thin provisioning.
>> Do you need to mention the use of block_job_cancel needed at the point
>> where you are ready to stop qemu from writing into the copy?
> 
> No, you need to do this with drive-reopen.  Using block_job_cancel will
> report completion, but will leave a race window that can cause to
> corruption in the guest.  Do your libvirt patches do that? O:)

They don't in v4 [1], but I'll fix it to do that in v5.  Thanks for the
heads up.
[1] https://www.redhat.com/archives/libvir-list/2012-April/msg00330.html
Paolo Bonzini - April 13, 2012, 8:41 p.m.
> On 04/13/2012 11:32 AM, Paolo Bonzini wrote:
> > Il 13/04/2012 19:09, Eric Blake ha scritto:
> >>>> +It is also possible to use raw as the format of the destination
> >>>> image.
> >>>> +Converting an image to raw will properly support thin
> >>>> provisioning.
> >> Do you need to mention the use of block_job_cancel needed at the
> >> point
> >> where you are ready to stop qemu from writing into the copy?
> > 
> > No, you need to do this with drive-reopen.  Using block_job_cancel
> > will report completion, but will leave a race window that can cause to
> > corruption in the guest.  Do your libvirt patches do that? O:)
> 
> They don't in v4 [1], but I'll fix it to do that in v5.  Thanks for
> the heads up.

I think we misunderstood each other.  I was asking if you were doing
block-job-cancel + drive-reopen to switch to the target.  That would
be wrong.

Doing block-job-cancel to revert to the source is perfectly fine.

Paolo
Eric Blake - April 13, 2012, 9:08 p.m.
On 04/13/2012 02:41 PM, Paolo Bonzini wrote:
>> On 04/13/2012 11:32 AM, Paolo Bonzini wrote:
>>> Il 13/04/2012 19:09, Eric Blake ha scritto:
>>>>>> +It is also possible to use raw as the format of the destination
>>>>>> image.
>>>>>> +Converting an image to raw will properly support thin
>>>>>> provisioning.
>>>> Do you need to mention the use of block_job_cancel needed at the
>>>> point
>>>> where you are ready to stop qemu from writing into the copy?
>>>
>>> No, you need to do this with drive-reopen.  Using block_job_cancel
>>> will report completion, but will leave a race window that can cause to
>>> corruption in the guest.  Do your libvirt patches do that? O:)
>>
>> They don't in v4 [1], but I'll fix it to do that in v5.  Thanks for
>> the heads up.
> 
> I think we misunderstood each other.  I was asking if you were doing
> block-job-cancel + drive-reopen to switch to the target.  That would
> be wrong.
> 
> Doing block-job-cancel to revert to the source is perfectly fine.

Glad to hear it.  My current approach is:

request | phase > |    streaming     |    mirroring
== v =============+==================+===================
revert-source     | block-job-cancel |  block-job-cancel
pivot             | error            |  drive-reopen

with no combined commands (that is, I'm not doing
block-job-cancel+drive-reopen).  Although if I understand correctly, the
combination of mirroring/revert-source could also be implemented by
drive-reopen instead of block-job-cancel, with the same net results in
the end.
Paolo Bonzini - April 16, 2012, 7:14 a.m.
Il 13/04/2012 23:08, Eric Blake ha scritto:
> Although if I understand correctly, the
> combination of mirroring/revert-source could also be implemented by
> drive-reopen instead of block-job-cancel, with the same net results in
> the end.

block-job-cancel cannot fail, drive-reopen can (and leave the VM hosed).

Paolo

Patch

diff --git a/docs/live-block-ops.txt b/docs/live-block-ops.txt
index a257087..caf3466 100644
--- a/docs/live-block-ops.txt
+++ b/docs/live-block-ops.txt
@@ -1,8 +1,7 @@ 
 LIVE BLOCK OPERATIONS
 =====================
 
-High level description of live block operations. Note these are not
-supported for use with the raw format at the moment.
+High level description of live block operations.
 
 Snapshot live merge
 ===================
@@ -44,15 +43,40 @@  In the example above, the command would be:
 (qemu) block_stream virtio0 A
 
 
+Live block migration
+====================
+
+Migrating an in use image to another destination in the filesystem
+is done through image mirroring.  The idea is to execute
+'drive_mirror virtio0 /new-path/disk.img qcow2' while the guest
+is running.  The topmost image ([D] in the example above) will
+be copied to the given path, and the two can be kept in sync.
+
+Progress can be monitored using 'info block-jobs'.  Once this command
+reports something like
+
+  Type mirror, device virtio0: Completed 1048576000 of 1048576000 bytes
+
+it is possible to switch to the destination using
+
+(qemu) drive_reopen virtio0 /new-path/disk.img
+
+This assumes that all images A/B/C are also present under /new-path
+or.  An image can be omitted from the destination if one of the images
+refers to its backing file using an absolute path.
+
+
 Live block copy
 ===============
 
 To copy an in use image to another destination in the filesystem, one
-should create a live snapshot in the desired destination, then stream
-into that image. Example:
-
-(qemu) snapshot_blkdev ide0-hd0 /new-path/disk.img qcow2
+can also use mirroring with the -f option.
 
-(qemu) block_stream ide0-hd0
+(qemu) drive_mirror -f virtio0 /new-path/disk.img qcow2
 
+Note that if one image in the chain is in raw format, the
+resulting copy might not be thin-provisioned anymore, depending on
+the underlying file system.
 
+It is also possible to use raw as the format of the destination image.
+Converting an image to raw will properly support thin provisioning.