[libvirt-users] [libvirt] vm live storage migration with snapshots

Edward Young edward.and.young at gmail.com
Wed Feb 11 21:07:05 UTC 2015


Hi Eric,

Thanks for your reply! I have the follow up questions blew.

On Wed, Feb 11, 2015 at 11:52 AM, Eric Blake <eblake at redhat.com> wrote:

> 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?
>

Yes, I'm talking about the 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.
>

Yes, I agree with you. In this case, we need to migrate the entire disk
state. In this case, there is no snapshot involved. we just perform the
regular migration with 'virsh migrate....'. Is this correct?


>
> >
> > 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.
>

My question is here. If we do not have any shared storage resource between
source and destination (eg. long distance VM migration), how can we migrate
the latest new data to the destination? we can copy the base, mid to
destination manually, then how can we migrate the active snapshot( new data
goes in)? I learned that drive_mirror in qemu is built to finish this, but
do not understand clearly. Could you elaborate for me, or provide an
example?


>
> 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.
>

Thanks a lot!
Ed

>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20150211/976a4a14/attachment.htm>


More information about the libvirt-users mailing list