[Qemu-devel] qcow2: online snasphots : internal vs external ?

[Qemu-devel] qcow2: online snasphots : internal vs external ?

[Alexandre DERUMIER]

Hi,
I'm currently looking to add live snapshot support to proxmox kvm distribution.

Is it possible to use internal snapshots on a running guest running qcow2 disk?
(qemu-img snapshot -c ) ?

I see some old mails about possible corruption, that's why I tell the question.


Or do I need to use external snapshots with qmp blockdev-snapshot-sync ?
(Seem more complex to delete old snapshots)

Regards,

Alexandre Derumier.

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Stefan Hajnoczi]

On Sat, Aug 25, 2012 at 2:25 PM, Alexandre DERUMIER <aderumier@odiso.com> wrote:
> I'm currently looking to add live snapshot support to proxmox kvm distribution.
>
> Is it possible to use internal snapshots on a running guest running qcow2 disk?
> (qemu-img snapshot -c ) ?

No.  qemu-img should not be used if the guest is running.

> Or do I need to use external snapshots with qmp blockdev-snapshot-sync ?
> (Seem more complex to delete old snapshots)

External qcow2/qed snapshots can be created while the guest is running
using snapshot-blockdev-sync, but it is not yet possible to flatten
the chain arbitrarily while the guest is running.

You can use block-stream to populate the top-most image file with data
from its backing image chain.  Jeff Cody is working on block-commit
which allows merging down (this is the opposite of block-stream).  The
advantage with block-commit is that backing images are often smaller
than the image file, it's therefore more efficient to copy less data
down instead of copying the backing image up into the image file.

Stefan

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Alexandre DERUMIER]

Thank Stefan,that's clear now.


Maybe one more question, about qemu snapshot that I don't understand.

I work since many years with snapshot on zfs or netapp,
and on these system like ceph, I can rollback at the time of the snapshot, and have a view of when the snapshot was taken.

exemple :
image1 : empty dir /
take a snapshot (snap1)
touch /file1
now rollback to snap1
ls /   ->empty dir, like when snap1 was taken


now,example with qemu:
image1 : empty dir /
take a snapshot: (qemu-img snapshot -c snap1 image1)
touch /file1
now rollback to snap1 (qemu-img snapshot -a snap1 image1)
ls /file1


the behaviour is completly different. Did I miss something ?


----- Mail original -----

De: "Stefan Hajnoczi" <stefanha@gmail.com>
À: "Alexandre DERUMIER" <aderumier@odiso.com>
Cc: "Jeff Cody" <jcody@redhat.com>, "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Samedi 25 Août 2012 16:01:45
Objet: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

On Sat, Aug 25, 2012 at 2:25 PM, Alexandre DERUMIER <aderumier@odiso.com> wrote:
> I'm currently looking to add live snapshot support to proxmox kvm distribution.
>
> Is it possible to use internal snapshots on a running guest running qcow2 disk?
> (qemu-img snapshot -c ) ?

No. qemu-img should not be used if the guest is running.

> Or do I need to use external snapshots with qmp blockdev-snapshot-sync ? 
> (Seem more complex to delete old snapshots)

External qcow2/qed snapshots can be created while the guest is running
using snapshot-blockdev-sync, but it is not yet possible to flatten
the chain arbitrarily while the guest is running.

You can use block-stream to populate the top-most image file with data
from its backing image chain. Jeff Cody is working on block-commit
which allows merging down (this is the opposite of block-stream). The
advantage with block-commit is that backing images are often smaller
than the image file, it's therefore more efficient to copy less data
down instead of copying the backing image up into the image file.

Stefan




--

--





Alexandre D e rumier

Ingénieur Systèmes et Réseaux


Fixe : 03 20 68 88 85

Fax : 03 20 68 90 88


45 Bvd du Général Leclerc 59100 Roubaix
12 rue Marivaux 75002 Paris

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Stefan Hajnoczi]

On Sat, Aug 25, 2012 at 6:06 PM, Alexandre DERUMIER <aderumier@odiso.com> wrote:
> I work since many years with snapshot on zfs or netapp,
> and on these system like ceph, I can rollback at the time of the snapshot, and have a view of when the snapshot was taken.
>
> exemple :
> image1 : empty dir /
> take a snapshot (snap1)
> touch /file1
> now rollback to snap1
> ls /   ->empty dir, like when snap1 was taken

Using snapshot capabilities of the underlying storage is a good idea.
LVM snapshots have been used with KVM for a long time.  The same works
for zfs, btrfs, etc.  They are probably more efficient than using
QEMU's external snapshots, which must copy data between image files
when flattening the image chain.

> now,example with qemu:
> image1 : empty dir /

Did you shut down the guest here?

> take a snapshot: (qemu-img snapshot -c snap1 image1)
> touch /file1

Did you shut down the guest here?

> now rollback to snap1 (qemu-img snapshot -a snap1 image1)
> ls /file1
>
>
> the behaviour is completly different. Did I miss something ?

It should work if you shut down the guest before manipulating snapshots.

Stefan

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Alexandre DERUMIER]

>>Using snapshot capabilities of the underlying storage is a good idea.
>>LVM snapshots have been used with KVM for a long time. The same works
>>for zfs, btrfs, etc. They are probably more efficient than using
>>QEMU's external snapshots, which must copy data between image files
>>when flattening the image chain.
Yes, indeed ;)  But I'll try to add feature to proxmox for all kind of storage.



>>It should work if you shut down the guest before manipulating snapshots. 
Oh, sorry, I have redone test with stopping the vm before manipulate, and it's work fine now.

It is possible to achieve the same behaviour with external snapshot ? (I would like to do it online)
I don't see how I can rollback to the point of time of the snapshot.

Also I see that snapshot_blkdev qmp command give in his description:
"Otherwise the snapshot will be internal! (currently unsupported)."

is Live internal snapshots on the roadmap ?

Thanks Again,

Alexandre Derumier
----- Mail original -----

De: "Stefan Hajnoczi" <stefanha@gmail.com>
À: "Alexandre DERUMIER" <aderumier@odiso.com>
Cc: "Jeff Cody" <jcody@redhat.com>, "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Dimanche 26 Août 2012 09:07:44
Objet: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

On Sat, Aug 25, 2012 at 6:06 PM, Alexandre DERUMIER <aderumier@odiso.com> wrote:
> I work since many years with snapshot on zfs or netapp,
> and on these system like ceph, I can rollback at the time of the snapshot, and have a view of when the snapshot was taken.
>
> exemple :
> image1 : empty dir /
> take a snapshot (snap1)
> touch /file1
> now rollback to snap1
> ls / ->empty dir, like when snap1 was taken

Using snapshot capabilities of the underlying storage is a good idea.
LVM snapshots have been used with KVM for a long time. The same works
for zfs, btrfs, etc. They are probably more efficient than using
QEMU's external snapshots, which must copy data between image files
when flattening the image chain.

> now,example with qemu:
> image1 : empty dir /

Did you shut down the guest here?

> take a snapshot: (qemu-img snapshot -c snap1 image1)
> touch /file1

Did you shut down the guest here?

> now rollback to snap1 (qemu-img snapshot -a snap1 image1)
> ls /file1
>
>
> the behaviour is completly different. Did I miss something ?

It should work if you shut down the guest before manipulating snapshots.

Stefan



--

--





Alexandre D e rumier

Ingénieur Systèmes et Réseaux


Fixe : 03 20 68 88 85

Fax : 03 20 68 90 88


45 Bvd du Général Leclerc 59100 Roubaix
12 rue Marivaux 75002 Paris

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Stefan Hajnoczi]

On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER
<aderumier@odiso.com> wrote:
> It is possible to achieve the same behaviour with external snapshot ? (I would like to do it online)
> I don't see how I can rollback to the point of time of the snapshot.

The snapshot only captures the contents of the disk.  Rollback does
not make sense without shutting down the guest.  The OS/file system
would be very confused if the disk contents changed underneath it.

Existing hotplug can be used.  For example, if we have an external
snapshot of a virtio-blk drive, we can use hotplug to remove the
drive, choose the snapshot file and attach it again.  This only works
for "data" drives, the root file system usually cannot be changed
while the guest is running.

You may also wish to look at libvirt for higher level snapshot primitives.

> Also I see that snapshot_blkdev qmp command give in his description:
> "Otherwise the snapshot will be internal! (currently unsupported)."
>
> is Live internal snapshots on the roadmap ?

I'm not aware of anyone working on adding internal snapshot in the
near future.  Patches are welcome.

Stefan

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Alexandre DERUMIER]

Thanks again Stefan

>>The snapshot only captures the contents of the disk. Rollback does
>>not make sense without shutting down the guest. The OS/file system
>>would be very confused if the disk contents changed underneath it.

>>Existing hotplug can be used. For example, if we have an external
>>snapshot of a virtio-blk drive, we can use hotplug to remove the
>>drive, choose the snapshot file and attach it again. This only works
>>for "data" drives, the root file system usually cannot be changed
>>while the guest is running.


Yes, sure rollback must be done offline.
But I wanted to say, with external snapshot, how can I rollback to the point of the snapshot.

exemple :
image1.qcow2
file : /beforesnap1
take a snaphot (snap1), so qemu switch to snap1.qcow2
write some file:
file:
    /aftersnap1.
    /beforesnap1

Now, how can I rollback to the point of time of snap1 ?
I can reuse image1.qcow2, but if I write some datas on it, I don't see how I can return to the point of time of the snap1. (like qemu-image -a  with internal snapshots)


>>You may also wish to look at libvirt for higher level snapshot primitives.
Thanks, I'll look at the libvirt to see how they do things.


----- Mail original -----

De: "Stefan Hajnoczi" <stefanha@gmail.com>
À: "Alexandre DERUMIER" <aderumier@odiso.com>
Cc: "Jeff Cody" <jcody@redhat.com>, "qemu-devel" <qemu-devel@nongnu.org>, "Paolo Bonzini" <pbonzini@redhat.com>, "Eric Blake" <eblake@redhat.com>
Envoyé: Lundi 27 Août 2012 11:04:14
Objet: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER
<aderumier@odiso.com> wrote:
> It is possible to achieve the same behaviour with external snapshot ? (I would like to do it online)
> I don't see how I can rollback to the point of time of the snapshot.

The snapshot only captures the contents of the disk. Rollback does
not make sense without shutting down the guest. The OS/file system
would be very confused if the disk contents changed underneath it.

Existing hotplug can be used. For example, if we have an external
snapshot of a virtio-blk drive, we can use hotplug to remove the
drive, choose the snapshot file and attach it again. This only works
for "data" drives, the root file system usually cannot be changed
while the guest is running.

You may also wish to look at libvirt for higher level snapshot primitives. 

> Also I see that snapshot_blkdev qmp command give in his description:
> "Otherwise the snapshot will be internal! (currently unsupported)."
>
> is Live internal snapshots on the roadmap ?

I'm not aware of anyone working on adding internal snapshot in the
near future. Patches are welcome.

Stefan



--

--





Alexandre D e rumier

Ingénieur Systèmes et Réseaux


Fixe : 03 20 68 88 85

Fax : 03 20 68 90 88


45 Bvd du Général Leclerc 59100 Roubaix
12 rue Marivaux 75002 Paris

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Paolo Bonzini]

Il 27/08/2012 11:26, Alexandre DERUMIER ha scritto:
> how can I rollback to the point of the snapshot.
> 
> exemple :
> image1.qcow2
> file : /beforesnap1
> take a snaphot (snap1), so qemu switch to snap1.qcow2
> write some file:
> file: 
>     /aftersnap1.
>     /beforesnap1
> 
> Now, how can I rollback to the point of time of snap1 ?
> I can reuse image1.qcow2, but if I write some datas on it, I don't
> see how I can return to the point of time of the snap1. (like qemu-image -a
> with internal snapshots)

If you can drop snap1.qcow2 altogether, you just use image1.qcow2 the
next time you start QEMU.

If you cannot, you create snap2.qcow2 based on image1.qcow2:

  qemu-img -f qcow2 -obacking_file=image1.qcow2 snap2.qcow2

and use it the next time you start QEMU.

Paolo

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Alexandre DERUMIER]

Ok, got it,

Thanks Paolo !

----- Mail original -----

De: "Paolo Bonzini" <pbonzini@redhat.com>
À: qemu-devel@nongnu.org
Envoyé: Lundi 27 Août 2012 12:10:34
Objet: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

Il 27/08/2012 11:26, Alexandre DERUMIER ha scritto:
> how can I rollback to the point of the snapshot.
>
> exemple :
> image1.qcow2
> file : /beforesnap1
> take a snaphot (snap1), so qemu switch to snap1.qcow2
> write some file:
> file:
> /aftersnap1.
> /beforesnap1
>
> Now, how can I rollback to the point of time of snap1 ?
> I can reuse image1.qcow2, but if I write some datas on it, I don't
> see how I can return to the point of time of the snap1. (like qemu-image -a
> with internal snapshots)

If you can drop snap1.qcow2 altogether, you just use image1.qcow2 the
next time you start QEMU.

If you cannot, you create snap2.qcow2 based on image1.qcow2:

qemu-img -f qcow2 -obacking_file=image1.qcow2 snap2.qcow2

and use it the next time you start QEMU.

Paolo






--

--





Alexandre D e rumier

Ingénieur Systèmes et Réseaux


Fixe : 03 20 68 88 85

Fax : 03 20 68 90 88


45 Bvd du Général Leclerc 59100 Roubaix
12 rue Marivaux 75002 Paris

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Paolo Bonzini]

Il 27/08/2012 11:04, Stefan Hajnoczi ha scritto:
>> > Also I see that snapshot_blkdev qmp command give in his description:
>> > "Otherwise the snapshot will be internal! (currently unsupported)."
>> >
>> > is Live internal snapshots on the roadmap ?
> I'm not aware of anyone working on adding internal snapshot in the
> near future.  Patches are welcome.

The main problem with internal snapshots is that it's difficult to work
with two snapshots at the same time, especially if you need to write to
two of them.  IIUC this is why people concentrated more on external
snapshots.

It's not intrinsic to internal snapshots, more like a wart of the
implementation, but not an easily fixed one.

Paolo

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Kevin Wolf]

Am 27.08.2012 11:04, schrieb Stefan Hajnoczi:
> On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER
> <aderumier@odiso.com> wrote:
>> It is possible to achieve the same behaviour with external snapshot ? (I would like to do it online)
>> I don't see how I can rollback to the point of time of the snapshot.
> 
> The snapshot only captures the contents of the disk.  Rollback does
> not make sense without shutting down the guest.  The OS/file system
> would be very confused if the disk contents changed underneath it.
> 
> Existing hotplug can be used.  For example, if we have an external
> snapshot of a virtio-blk drive, we can use hotplug to remove the
> drive, choose the snapshot file and attach it again.  This only works
> for "data" drives, the root file system usually cannot be changed
> while the guest is running.
> 
> You may also wish to look at libvirt for higher level snapshot primitives.
> 
>> Also I see that snapshot_blkdev qmp command give in his description:
>> "Otherwise the snapshot will be internal! (currently unsupported)."
>>
>> is Live internal snapshots on the roadmap ?
> 
> I'm not aware of anyone working on adding internal snapshot in the
> near future.  Patches are welcome.

I wonder why nobody mentioned the savevm/loadvm monitor commands, which
do take an internal snapshot of a running VM. They just aren't live, and
when writing out the whole VM state this matters indeed.

However, if a disk-only snapshot is enough (this is what qemu-img
snapshot -c would produce), it would be a trivial patch to add a savevm
option to omit the VM state - and even though the snapshot is then still
not really performed in the background, it should be quick enough to be
workable.

Of course, the other thing is that external snapshots are way better
tested that internal ones. So possibly you need to put some effort in
testing and possibly fixing if you go for internal snapshots (I would
really like to see internal snapshots improved; even just that they can
be deleted without major hassle makes them the better option in many cases)

Kevin

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Stefan Hajnoczi]

On Mon, Aug 27, 2012 at 5:12 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 27.08.2012 11:04, schrieb Stefan Hajnoczi:
>> On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER
>> <aderumier@odiso.com> wrote:
>>> It is possible to achieve the same behaviour with external snapshot ? (I would like to do it online)
>>> I don't see how I can rollback to the point of time of the snapshot.
>>
>> The snapshot only captures the contents of the disk.  Rollback does
>> not make sense without shutting down the guest.  The OS/file system
>> would be very confused if the disk contents changed underneath it.
>>
>> Existing hotplug can be used.  For example, if we have an external
>> snapshot of a virtio-blk drive, we can use hotplug to remove the
>> drive, choose the snapshot file and attach it again.  This only works
>> for "data" drives, the root file system usually cannot be changed
>> while the guest is running.
>>
>> You may also wish to look at libvirt for higher level snapshot primitives.
>>
>>> Also I see that snapshot_blkdev qmp command give in his description:
>>> "Otherwise the snapshot will be internal! (currently unsupported)."
>>>
>>> is Live internal snapshots on the roadmap ?
>>
>> I'm not aware of anyone working on adding internal snapshot in the
>> near future.  Patches are welcome.
>
> I wonder why nobody mentioned the savevm/loadvm monitor commands, which
> do take an internal snapshot of a running VM. They just aren't live, and
> when writing out the whole VM state this matters indeed.
>
> However, if a disk-only snapshot is enough (this is what qemu-img
> snapshot -c would produce), it would be a trivial patch to add a savevm
> option to omit the VM state - and even though the snapshot is then still
> not really performed in the background, it should be quick enough to be
> workable.

The change to qmp-transaction or snapshot-blkdev-sync should be
similarly small.  I think savevm/loadvm isn't the right place to add
disk-only snapshots since we already have
qmp-transaction/snapshot-blkdev-sync for that.

Stefan

Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

[Alexandre DERUMIER]

> However, if a disk-only snapshot is enough (this is what qemu-img
> snapshot -c would produce), it would be a trivial patch to add a savevm
> option to omit the VM state - and even though the snapshot is then still 
> not really performed in the background, it should be quick enough to be
> workable.

I found a old patch RFC from 2010 for savevm to omit the vmstate
http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg00655.html

>>The change to qmp-transaction or snapshot-blkdev-sync should be
>>similarly small. I think savevm/loadvm isn't the right place to add
>>disk-only snapshots since we already have
>>qmp-transaction/snapshot-blkdev-sync for that.

But indeed, qmp-transaction/snapshot-blkdev-sync seem to be better place.



----- Mail original -----

De: "Stefan Hajnoczi" <stefanha@gmail.com>
À: "Kevin Wolf" <kwolf@redhat.com>
Cc: "Alexandre DERUMIER" <aderumier@odiso.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Jeff Cody" <jcody@redhat.com>, "Eric Blake" <eblake@redhat.com>, "qemu-devel" <qemu-devel@nongnu.org>
Envoyé: Mardi 28 Août 2012 10:11:18
Objet: Re: [Qemu-devel] qcow2: online snasphots : internal vs external ?

On Mon, Aug 27, 2012 at 5:12 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 27.08.2012 11:04, schrieb Stefan Hajnoczi:
>> On Sun, Aug 26, 2012 at 10:56 AM, Alexandre DERUMIER
>> <aderumier@odiso.com> wrote:
>>> It is possible to achieve the same behaviour with external snapshot ? (I would like to do it online)
>>> I don't see how I can rollback to the point of time of the snapshot.
>>
>> The snapshot only captures the contents of the disk. Rollback does
>> not make sense without shutting down the guest. The OS/file system
>> would be very confused if the disk contents changed underneath it.
>>
>> Existing hotplug can be used. For example, if we have an external
>> snapshot of a virtio-blk drive, we can use hotplug to remove the
>> drive, choose the snapshot file and attach it again. This only works
>> for "data" drives, the root file system usually cannot be changed
>> while the guest is running.
>>
>> You may also wish to look at libvirt for higher level snapshot primitives.
>>
>>> Also I see that snapshot_blkdev qmp command give in his description:
>>> "Otherwise the snapshot will be internal! (currently unsupported)."
>>>
>>> is Live internal snapshots on the roadmap ?
>>
>> I'm not aware of anyone working on adding internal snapshot in the
>> near future. Patches are welcome.
>
> I wonder why nobody mentioned the savevm/loadvm monitor commands, which
> do take an internal snapshot of a running VM. They just aren't live, and 
> when writing out the whole VM state this matters indeed.
>
> However, if a disk-only snapshot is enough (this is what qemu-img
> snapshot -c would produce), it would be a trivial patch to add a savevm
> option to omit the VM state - and even though the snapshot is then still 
> not really performed in the background, it should be quick enough to be
> workable.

The change to qmp-transaction or snapshot-blkdev-sync should be
similarly small. I think savevm/loadvm isn't the right place to add
disk-only snapshots since we already have
qmp-transaction/snapshot-blkdev-sync for that.

Stefan



--

--





Alexandre D e rumier

Ingénieur Systèmes et Réseaux


Fixe : 03 20 68 88 85

Fax : 03 20 68 90 88


45 Bvd du Général Leclerc 59100 Roubaix
12 rue Marivaux 75002 Paris