qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: dlaor@redhat.com
Cc: Kevin Wolf <kwolf@redhat.com>,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] Image streaming gives live block copy for free (and vice versa)
Date: Fri, 24 Jun 2011 10:35:48 +0100	[thread overview]
Message-ID: <BANLkTim1caFV3UtjULVE-_7PCgG9q6GS2A@mail.gmail.com> (raw)
In-Reply-To: <4DFE1FEC.10207@redhat.com>

On Sun, Jun 19, 2011 at 5:12 PM, Dor Laor <dlaor@redhat.com> wrote:
> On 06/17/2011 08:53 AM, Stefan Hajnoczi wrote:
>>
>> Perhaps someone has been saying this all along but I want to spell it
>> out that image streaming and live block copy are equivalent in theory.
>> I just realized this last night.  In practice we might choose one
>> implementation or two different ones for performance reasons.
>>
>> If any of these are unclear please let me know and I'll try to post
>> diagrams.
>>
>> Live block copy using image streaming
>> -------------------------------------
>>
>> 1. Create the destination image file and use the source image as the
>> backing file.
>> 2. Quiesce I/O and pause VM.
>> 3. Switch to destination image.
>> 4. Resume VM.
>> 5. Start streaming destination image in order to copy source image
>> data into destination file.
>> 6. Streaming completes and disables the backing file, leaving the live
>> copied destination image that no longer depends on the source image.
>
> Well streaming is copying just using post-copy approach.
> Both pre and post are required:
>  - post-copy (aka streaming) for fast live block migration of the VM
>   for cpu load balance.
>  - pre-copy (aka live block copy)
>   If you manage to get a network outage between the source and the
>   destination storage systems, you will manage to keep running the VM
>   on the source side.

Out of interest, are you brainstorming using live block copy and image
streaming for pre- and post-copy live migration or do you have
concrete plans to update libvirt to use these mechanisms?

So far I've been focussing on the fast provisioning use case where
image streaming helps, but eventually I would like to improve the
state of storage migration too.

Stefan

  reply	other threads:[~2011-06-24  9:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BANLkTimMuRnrRo7g2uTs0bihLDEa_DDz1A@mail.gmail.com>
2011-06-17  5:53 ` [Qemu-devel] Image streaming gives live block copy for free (and vice versa) Stefan Hajnoczi
2011-06-19 16:12   ` Dor Laor
2011-06-24  9:35     ` Stefan Hajnoczi [this message]
2011-06-26 12:52       ` Dor Laor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTim1caFV3UtjULVE-_7PCgG9q6GS2A@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=avi@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).