qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 8/8] docs: add mirroring to live block operation


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 8/8] docs: add mirroring to live block operations
Date: Fri, 13 Apr 2012 11:09:03 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/13/2012 10:23 AM, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>  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?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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