All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Edward Young <edward.and.young@gmail.com>,
	libvirt-users@redhat.com, qemu-discuss@nongnu.org,
	qemu-devel@nongnu.org, libvir-list@redhat.com
Subject: Re: [Qemu-devel] [libvirt] vm live storage migration with snapshots
Date: Wed, 11 Feb 2015 10:52:49 -0700	[thread overview]
Message-ID: <54DB96F1.9040003@redhat.com> (raw)
In-Reply-To: <CALHzvtQ5ya0jhyaCVbAO-o=V_m8mxps2KMvDjnwaUjw_MJPtGQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

On 02/11/2015 10:08 AM, Edward Young wrote:
> Hi all,

[probably didn't need to cross-post to quite that wide of an audience,
oh well]

> 
> I'm investigating the ways to improve the live migration performance in
> libvirt. I have a question about the vm live storage migration. the
> platform is libvirt + qemu + kvm
> 
> If we want to migrate a running vm with its virtual disk images to another
> node.
> we can use 'virsh migrate ....' commands.
> 
> What if this vm has a number of disk-only external snapshots? In the
> current version, how can live migrate this vm?

Are the snapshots based on shared storage, or local-only storage?

If I understand your question correctly, you are starting with this
situation:

base <- mid <- active

and want to make sure that on the destination, the guest still sees the
same contents as 'active' on the source, whether or not the destination
still sees a backing chain or just one file.

> 
> Is it possible to blockcommit the snapshots to the base image and later
> perform the migration, without shutting down the running vm?

Yes, but that may not be the fastest solution.  That is, you would be
going from:

base <- mid <- active

to

base'

where base' is the active image containing all the committed state, then
migrate that file.  If base is not shared, that means qemu has to
migrate the entire disk state.  And you also no longer have the external
snapshots to revert to on the destination.

> 
> Or is it possible to iteratively transfer all the snapshots to the
> destination and later live migrate only the latest new data?
> 

Yes, that works too, and is probably faster, especially if you have
out-of-band means for sharing read-only state between source and
destination.

In fact, if you can create yet another (temporary) external snapshot,
but this time on shared storage, and have storage backends that let you
instantly remap backing files to be visible into the destination, then
it is as simple as:

create a snapshot with shared storage destination
base <- mid <- active(frozen) <- shared
copy base, mid, and active to the destination
live migrate using shared storage instead of doing storage migration
block-commit shared back into active
base <- mid <- active

where the shared storage only needs to hold as much disk state as
diverges during the time of the live migration.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-02-11 17:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-11 17:08 [Qemu-devel] vm live storage migration with snapshots Edward Young
2015-02-11 17:52 ` Eric Blake [this message]
2015-02-11 21:07   ` [Qemu-devel] [libvirt] " Edward Young
2015-02-11 21:12     ` Eric Blake
2015-02-11 21:45       ` Edward Young

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=54DB96F1.9040003@redhat.com \
    --to=eblake@redhat.com \
    --cc=edward.and.young@gmail.com \
    --cc=libvir-list@redhat.com \
    --cc=libvirt-users@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@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 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.