qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] live migration which includes previos snapshot


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] live migration which includes previos snapshot
Date: Fri, 2 Nov 2012 11:30:25 +0100

On Fri, Nov 2, 2012 at 9:24 AM, Kuniyasu Suzaki <address@hidden> wrote:
>
> Hello Stefan,
>
> From: Stefan Hajnoczi <address@hidden>
> Subject: Re: [Qemu-devel] live migration which includes previos snapshot
> Date: Fri, 2 Nov 2012 08:19:15 +0100
>
>> On Fri, Nov 2, 2012 at 4:15 AM, Kuniyasu Suzaki <address@hidden> wrote:
>> > Can live migration of QEMU include previous snapshot images?
>> > I want to roll back to a previous snapshot image on another machine
>> > after live migration.
>> >
>> > I was thinking Block Migration bring the snapshot images of QCOW2, but
>> > Block Migration transfers the hard disk image only.
>> > Do I have other methods to move snapshot image at live migration?
>>
>> Can you host your qcow2 image files on shared storage like an NFS server?
>
> Excuse me. My explanation was not enough.
> I want to fork a running VM to another machine. I hope that each VM
> has same QCOW2 file on each machine. Therefore I tried to use Block
> Migration but it did not bring snapshot images.
>
>> QEMU does not have a built-in way to migrate the original qcow2 file itself.
>
> Are there any good ideas to fork a running VM with previous snapshot image?

If you are forking the VM so that there will be two VMs running
simultaneously, then a single qcow2 file cannot be used.

Here are two approaches that will work but require you to modify QEMU code:

I. Perhaps you can make it work with external snapshots:

1. Make the original image read-only accessible over NFS.
2. Modify QEMU to create two external snapshot files when the VM is
paused for migration (during your fork operation):

/host-a/original.qcow2
/host-a/new.qcow2 (backing file: /host-a/original.qcow2)
/host-b/new.qcow2 (backing file: /host-b/original.qcow2)

3. After fork the two VMs will write into their respective new.qcow2
files.  original.qcow2 is never modified anymore.

II. If you want to use internal snapshots in a single qcow2 file, you
will need to modify QEMU code more:
1. Implement BlockDriverState snapshot slave support so a qcow2
snapshot can be read-only accessed as a BlockDriverState while the
master BlockDriverState for the image still writes into the image
file.  This is mainly qcow2 refactoring and block.c glue code.
2. Use Paolo's runtime NBD server to export the snapshot slave when
the VM is forked:

/host-a/original.qcow2:
 * Snapshot: fork-snapshot (state of the disk when the VM was forked)

/host-b/new.qcow2 (backing file: nbd:host-a/original.qcow2/fork-snapshot)

Taking the second approach doesn't buy you much and is a lot more work.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]