[Qemu-devel] live migration which includes previos snapshot

[Qemu-devel] live migration which includes previos snapshot

[Kuniyasu Suzaki]

Hello,

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?

------
suzaki

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

[Stefan Hajnoczi]

On Fri, Nov 2, 2012 at 4:15 AM, Kuniyasu Suzaki <k.suzaki@aist.go.jp> 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?

QEMU does not have a built-in way to migrate the original qcow2 file itself.

Stefan

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

[Kuniyasu Suzaki]

Hello Stefan,

From: Stefan Hajnoczi <stefanha@gmail.com>
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 <k.suzaki@aist.go.jp> 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?

------
suzaki

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

[Stefan Hajnoczi]

On Fri, Nov 2, 2012 at 9:24 AM, Kuniyasu Suzaki <k.suzaki@aist.go.jp> wrote:
>
> Hello Stefan,
>
> From: Stefan Hajnoczi <stefanha@gmail.com>
> 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 <k.suzaki@aist.go.jp> 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

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

[Eric Blake]

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

On 11/02/2012 04:30 AM, Stefan Hajnoczi wrote:

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

You are not the first to request this - libvirt would also like the
ability to have read-only access into the contents of an internal
snapshot while the rest of qemu continues to write into the image.

> 2. Use Paolo's runtime NBD server to export the snapshot slave when
> the VM is forked:

An NBD server on top of the read-only state is an additional step that
will make access easier.

-- 
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: 617 bytes --]

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

[Kuniyasu Suzaki]

Hello Eric,

From: Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] live migration which includes previos snapshot
Date: Fri, 02 Nov 2012 07:12:21 -0600

> On 11/02/2012 04:30 AM, Stefan Hajnoczi wrote:
> 
> > 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.
> 
> You are not the first to request this - libvirt would also like the
> ability to have read-only access into the contents of an internal
> snapshot while the rest of qemu continues to write into the image.

Do you mean that libvirt can change the access mode of internal
harddisk from read-write to read-only?
Please tell me how to change the mode by libvirt.

Does the qemu which has read-only access only, use another COW file?
Nested COWs sound interested, but the inter COW must be read-only, I think.

> > 2. Use Paolo's runtime NBD server to export the snapshot slave when
> > the VM is forked:
> 
> An NBD server on top of the read-only state is an additional step that
> will make access easier.

Does an NBD work as COW? It looks convenient.

Thank you.
------
suzaki

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

[Kuniyasu Suzaki]

Hello Stefan,

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

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

Does it means nested qcow2?
Does it allow to use a snapshot image in original.qcow2?
# I want to share a snapshot image taken by "savevm" on two QEMUs.

------
suzaki

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

[Eric Blake]

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

On 11/02/2012 09:00 AM, Kuniyasu Suzaki wrote:
>> You are not the first to request this - libvirt would also like the
>> ability to have read-only access into the contents of an internal
>> snapshot while the rest of qemu continues to write into the image.
> 
> Do you mean that libvirt can change the access mode of internal
> harddisk from read-write to read-only?

No.  I meant that reading an internal snapshot (a read-only operation)
while still using the rest of the qcow2 file read-write for live
operation would be a nice feature.  The very nature of the qcow2 file
format means that you cannot have two writers at the same time; the best
you can do is expose the snapshots as a read-only backing file of yet
another qcow2 file if you want a second writer based on the state of the
snapshot without interfering with the first writer.

> Please tell me how to change the mode by libvirt.

Libvirt can't support reading of internal snapshots until qemu supports
it.  In other words, it's a feature no one has written yet, but which
several people want.

> 
> Does the qemu which has read-only access only, use another COW file?
> Nested COWs sound interested, but the inter COW must be read-only, I think.

Correct - any reading of internal snapshots must be read-only - you are
required to use external backing files before you can have multiple
writers sharing a common backing file.

> 
>>> 2. Use Paolo's runtime NBD server to export the snapshot slave when
>>> the VM is forked:
>>
>> An NBD server on top of the read-only state is an additional step that
>> will make access easier.
> 
> Does an NBD work as COW? It looks convenient.

Rather, I'm thinking of making the NBD of the read-only internal
snapshot be the backing file of the new qcow2 layer.  But yes, NBD is
probably the best way for qemu to expose the contents of an internal
snapshot, rather than inventing yet another protocol.

-- 
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: 617 bytes --]

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

[Eric Blake]

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

On 11/02/2012 09:18 AM, Kuniyasu Suzaki wrote:
>> 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.
> 
> Does it means nested qcow2?
> Does it allow to use a snapshot image in original.qcow2?
> # I want to share a snapshot image taken by "savevm" on two QEMUs.

This is not yet possible, someone has to step up and write patches to
make it possible.

-- 
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: 617 bytes --]