All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: dlaor@redhat.com, Kevin Wolf <kwolf@redhat.com>,
	Chris Wright <chrisw@redhat.com>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	quintela@redhat.com, qemu-devel@nongnu.org,
	Avi Kivity <avi@redhat.com>,
	jes sorensen <jes.sorensen@redhat.com>
Subject: Re: [Qemu-devel] KVM call agenda for June 28
Date: Tue, 5 Jul 2011 09:58:58 -0300	[thread overview]
Message-ID: <20110705125858.GA21254@amt.cnet> (raw)
In-Reply-To: <CAJSP0QXLJBZn_3RfCWJCBE8-6LMd2jn4gJ3DqM8VHG3gg+85iQ@mail.gmail.com>

On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote:
> On Tue, Jul 5, 2011 at 9:01 AM, Dor Laor <dlaor@redhat.com> wrote:
> > I tried to re-arrange all of the requirements and use cases using this wiki
> > page: http://wiki.qemu.org/Features/LiveBlockMigration
> >
> > It would be the best to agree upon the most interesting use cases (while we
> > make sure we cover future ones) and agree to them.
> > The next step is to set the interface for all the various verbs since the
> > implementation seems to be converging.
> 
> Live block copy was supposed to support snapshot merge.  I think the
> current favored approach is to make the source image a backing file to
> the destination image and essentially do image streaming.
> 
> Using this mechanism for snapshot merge is tricky.  The COW file
> already uses the read-only snapshot base image.  So now we cannot
> trivally copy the COW file contents back into the snapshot base image
> using live block copy.

It never did. Live copy creates a new image were both snapshot and
"current" are copied to.

This is similar with image streaming.

> It seems like snapshot merge will require dedicated code that reads
> the allocated clusters from the COW file and writes them back into the
> base image.
> 
> A very inefficient alternative would be to create a third image, the
> "merge" image file, which has the COW file as its backing file:
> snapshot (base) -> cow -> merge
> 
> All data from snapshot and cow is copied into merge and then snapshot
> and cow can be deleted.  But this approach is results in full data
> copying and uses potentially 3x space if cow is close to the size of
> snapshot.

Management can set a higher limit on the size of data that is merged,
and create a new base once exceeded. This avoids copying excessive
amounts of data.

> Any other ideas that reuse live block copy for snapshot merge?
> 
> Stefan

WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Chris Wright <chrisw@redhat.com>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	quintela@redhat.com, jes sorensen <jes.sorensen@redhat.com>,
	dlaor@redhat.com, qemu-devel@nongnu.org,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] KVM call agenda for June 28
Date: Tue, 5 Jul 2011 09:58:58 -0300	[thread overview]
Message-ID: <20110705125858.GA21254@amt.cnet> (raw)
In-Reply-To: <CAJSP0QXLJBZn_3RfCWJCBE8-6LMd2jn4gJ3DqM8VHG3gg+85iQ@mail.gmail.com>

On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote:
> On Tue, Jul 5, 2011 at 9:01 AM, Dor Laor <dlaor@redhat.com> wrote:
> > I tried to re-arrange all of the requirements and use cases using this wiki
> > page: http://wiki.qemu.org/Features/LiveBlockMigration
> >
> > It would be the best to agree upon the most interesting use cases (while we
> > make sure we cover future ones) and agree to them.
> > The next step is to set the interface for all the various verbs since the
> > implementation seems to be converging.
> 
> Live block copy was supposed to support snapshot merge.  I think the
> current favored approach is to make the source image a backing file to
> the destination image and essentially do image streaming.
> 
> Using this mechanism for snapshot merge is tricky.  The COW file
> already uses the read-only snapshot base image.  So now we cannot
> trivally copy the COW file contents back into the snapshot base image
> using live block copy.

It never did. Live copy creates a new image were both snapshot and
"current" are copied to.

This is similar with image streaming.

> It seems like snapshot merge will require dedicated code that reads
> the allocated clusters from the COW file and writes them back into the
> base image.
> 
> A very inefficient alternative would be to create a third image, the
> "merge" image file, which has the COW file as its backing file:
> snapshot (base) -> cow -> merge
> 
> All data from snapshot and cow is copied into merge and then snapshot
> and cow can be deleted.  But this approach is results in full data
> copying and uses potentially 3x space if cow is close to the size of
> snapshot.

Management can set a higher limit on the size of data that is merged,
and create a new base once exceeded. This avoids copying excessive
amounts of data.

> Any other ideas that reuse live block copy for snapshot merge?
> 
> Stefan

  reply	other threads:[~2011-07-05 12:59 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-27 14:32 KVM call agenda for June 28 Juan Quintela
2011-06-27 14:32 ` [Qemu-devel] " Juan Quintela
2011-06-28 13:38 ` Stefan Hajnoczi
2011-06-28 13:38   ` [Qemu-devel] " Stefan Hajnoczi
2011-06-28 19:41   ` Marcelo Tosatti
2011-06-28 19:41     ` [Qemu-devel] " Marcelo Tosatti
2011-06-29  5:32     ` Stefan Hajnoczi
2011-06-29  5:32       ` [Qemu-devel] " Stefan Hajnoczi
2011-06-29  7:57     ` Kevin Wolf
2011-06-29  7:57       ` [Qemu-devel] " Kevin Wolf
2011-06-29 10:08       ` Stefan Hajnoczi
2011-06-29 10:08         ` [Qemu-devel] " Stefan Hajnoczi
2011-06-29 15:41         ` Marcelo Tosatti
2011-06-29 15:41           ` [Qemu-devel] " Marcelo Tosatti
2011-06-30 11:48           ` Stefan Hajnoczi
2011-06-30 11:48             ` [Qemu-devel] " Stefan Hajnoczi
2011-06-30 12:39             ` Kevin Wolf
2011-06-30 12:39               ` [Qemu-devel] " Kevin Wolf
2011-06-30 12:54           ` Stefan Hajnoczi
2011-06-30 12:54             ` [Qemu-devel] " Stefan Hajnoczi
2011-06-30 14:36             ` Marcelo Tosatti
2011-06-30 14:36               ` [Qemu-devel] " Marcelo Tosatti
2011-06-30 14:52               ` Kevin Wolf
2011-06-30 14:52                 ` [Qemu-devel] " Kevin Wolf
2011-06-30 18:38                 ` Marcelo Tosatti
2011-07-05  8:01                   ` Dor Laor
2011-07-05 12:40                     ` Stefan Hajnoczi
2011-07-05 12:40                       ` Stefan Hajnoczi
2011-07-05 12:58                       ` Marcelo Tosatti [this message]
2011-07-05 12:58                         ` Marcelo Tosatti
2011-07-05 13:39                         ` Dor Laor
2011-07-05 13:39                           ` Dor Laor
2011-07-05 14:29                           ` Marcelo Tosatti
2011-07-05 14:29                             ` [Qemu-devel] " Marcelo Tosatti
2011-07-05 14:32                           ` Marcelo Tosatti
2011-07-05 14:32                             ` Marcelo Tosatti
2011-07-05 14:46                             ` Kevin Wolf
2011-07-05 14:46                               ` Kevin Wolf
2011-07-05 15:04                             ` Dor Laor
2011-07-05 15:04                               ` Dor Laor
2011-07-05 15:29                               ` Marcelo Tosatti
2011-07-05 15:29                                 ` Marcelo Tosatti
2011-07-05 15:37                             ` Stefan Hajnoczi
2011-07-05 15:37                               ` Stefan Hajnoczi
2011-07-05 18:18                               ` Marcelo Tosatti
2011-07-05 18:18                                 ` Marcelo Tosatti
2011-07-06  7:48                                 ` Kevin Wolf
2011-07-06  7:48                                   ` Kevin Wolf
2011-07-07 15:25                                 ` Stefan Hajnoczi
2011-07-07 15:25                                   ` Stefan Hajnoczi
2011-06-28 13:43 ` Anthony Liguori
2011-06-28 13:43   ` Anthony Liguori
2011-06-28 13:48   ` Avi Kivity
2011-06-28 13:48     ` Avi Kivity
2011-06-30 14:10     ` Anthony Liguori

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=20110705125858.GA21254@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=avi@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=dlaor@redhat.com \
    --cc=jes.sorensen@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.