| Message ID | 1334334198-30899-9-git-send-email-pbonzini@redhat.com |
|---|---|
| State | New |
| Headers | show |
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?
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
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
> 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
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.
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
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.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- docs/live-block-ops.txt | 38 +++++++++++++++++++++++++++++++------- 1 file changed, 31 insertions(+), 7 deletions(-)