Discussion:
[libvirt-users] snapshot of a raw file - how to revert ?
Lentes, Bernd
2018-02-13 12:38:34 UTC
Permalink
Hi,

i have the following system:

pc59093:~ # cat /etc/os-release
NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"

pc59093:~ # uname -a
Linux pc59093 3.0.101-84-default #1 SMP Tue Oct 18 10:32:51 UTC 2016 (15251d6) x86_64 x86_64 x86_64 GNU/Linux

pc59093:~ # rpm -qa|grep -iE 'libvirt|kvm'
libvirt-cim-0.5.12-0.7.16
libvirt-python-1.2.5-1.102
libvirt-client-1.2.5-15.3
kvm-1.4.2-47.1
sles-kvm_en-pdf-11.4-0.33.1
libvirt-1.2.5-15.3


I have several guests running with raw files, which is sufficent for me. Now i'd like to snapshot one guest because i make heavy configuration changes on it.
From what i read in the net is that libvirt supports snapshoting of raw files when the guest is shutdown and the file of the snapshot becomes a qcow2. Right ?
I try to avoid converting my raw file to a qcow2 file. I can shutdown the guest for a certain time, that's no problem. I don't need a live snapshot.
But how can i revert to my previous state if my configuration changes go wrong ?
Can i do this with snapshot-revert or do i have to edit the xml file and point the hd again to the origin raw file ?
What i found in the net wasn't complete clear.

Thanks.


Bernd
--
Bernd Lentes
Systemadministration
Institut für Entwicklungsgenetik
Gebäude 35.34 - Raum 208
HelmholtzZentrum münchen
[ mailto:***@helmholtz-muenchen.de | ***@helmholtz-muenchen.de ]
phone: +49 89 3187 1241
fax: +49 89 3187 2294
[ http://www.helmholtz-muenchen.de/idg | http://www.helmholtz-muenchen.de/idg ]

no backup - no mercy


Helmholtz Zentrum München
Lentes, Bernd
2018-02-15 10:41:37 UTC
Permalink
Post by Lentes, Bernd
Hi,
pc59093:~ # cat /etc/os-release
NAME="SLES"
VERSION="11.4"
VERSION_ID="11.4"
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:11:4"
pc59093:~ # uname -a
Linux pc59093 3.0.101-84-default #1 SMP Tue Oct 18 10:32:51 UTC 2016 (15251d6)
x86_64 x86_64 x86_64 GNU/Linux
pc59093:~ # rpm -qa|grep -iE 'libvirt|kvm'
libvirt-cim-0.5.12-0.7.16
libvirt-python-1.2.5-1.102
libvirt-client-1.2.5-15.3
kvm-1.4.2-47.1
sles-kvm_en-pdf-11.4-0.33.1
libvirt-1.2.5-15.3
I have several guests running with raw files, which is sufficent for me. Now i'd
like to snapshot one guest because i make heavy configuration changes on it.
From what i read in the net is that libvirt supports snapshoting of raw files
when the guest is shutdown and the file of the snapshot becomes a qcow2. Right
?
I try to avoid converting my raw file to a qcow2 file. I can shutdown the guest
for a certain time, that's no problem. I don't need a live snapshot.
But how can i revert to my previous state if my configuration changes go wrong ?
Can i do this with snapshot-revert or do i have to edit the xml file and point
the hd again to the origin raw file ?
What i found in the net wasn't complete clear.
Thanks.
Hi,

i found that: https://dustymabe.com/2015/01/11/qemu-img-backing-files-a-poor-mans-snapshotrollback/

I tried it and it seemed to work, although my root fs was checked after the commit, anything else seemed to work.
What do you think of this procedure ?

Bernd


Helmholtz Zentrum München
Kashyap Chamarthy
2018-02-15 11:53:05 UTC
Permalink
On Thu, Feb 15, 2018 at 11:41:37AM +0100, Lentes, Bernd wrote:

[...]
Post by Lentes, Bernd
Hi,
i found that: https://dustymabe.com/2015/01/11/qemu-img-backing-files-a-poor-mans-snapshotrollback/
I tried it and it seemed to work, although my root fs was checked
after the commit, anything else seemed to work. What do you think of
this procedure ?
Instead of 'qemu-img create', I'd suggest using `virsh
snapshot-create-as` (as shown in my previous email). This will tell
libvirt to automatically use the just created QCOW2 overlay.

But yeah, one useful bit is to use the `virt-xml` tool to point to the
desired disk image (instead of `virsh edit` that I mentioned in the
previous email):

$ virt-xml F21server --edit target=vda \
--disk driver_type=raw,path=./A.raw
--
/kashyap
Lentes, Bernd
2018-02-16 12:59:01 UTC
Permalink
Post by Kashyap Chamarthy
[...]
Post by Lentes, Bernd
Hi,
https://dustymabe.com/2015/01/11/qemu-img-backing-files-a-poor-mans-snapshotrollback/
I tried it and it seemed to work, although my root fs was checked
after the commit, anything else seemed to work. What do you think of
this procedure ?
Instead of 'qemu-img create', I'd suggest using `virsh
snapshot-create-as` (as shown in my previous email). This will tell
libvirt to automatically use the just created QCOW2 overlay.
But yeah, one useful bit is to use the `virt-xml` tool to point to the
desired disk image (instead of `virsh edit` that I mentioned in the
$ virt-xml F21server --edit target=vda \
--disk driver_type=raw,path=./A.raw
--
Hi Kashyap,

thanks for your quick and detailed answers. Just to be complete.
The procedure in the above mentioned link does work with my old software ?

pc59093:~ # rpm -qa|grep -iE 'libvirt|kvm'
libvirt-cim-0.5.12-0.7.16
libvirt-python-1.2.5-1.102
libvirt-client-1.2.5-15.3
kvm-1.4.2-47.1
sles-kvm_en-pdf-11.4-0.33.1
libvirt-1.2.5-15.3

Bernd


Helmholtz Zentrum München
Kashyap Chamarthy
2018-02-16 14:01:55 UTC
Permalink
On Fri, Feb 16, 2018 at 01:59:01PM +0100, Lentes, Bernd wrote:

[...]
Post by Lentes, Bernd
Hi Kashyap,
thanks for your quick and detailed answers. Just to be complete.
The procedure in the above mentioned link does work with my old software ?
It _should_ work; but please try on a test VM and see what works and
what doesn't in your environment.
Post by Lentes, Bernd
pc59093:~ # rpm -qa|grep -iE 'libvirt|kvm'
libvirt-cim-0.5.12-0.7.16
libvirt-python-1.2.5-1.102
libvirt-client-1.2.5-15.3
kvm-1.4.2-47.1
sles-kvm_en-pdf-11.4-0.33.1
libvirt-1.2.5-15.3
--
/kashyap
Lentes, Bernd
2018-02-16 15:37:38 UTC
Permalink
Post by Kashyap Chamarthy
[...]
Post by Lentes, Bernd
Hi Kashyap,
thanks for your quick and detailed answers. Just to be complete.
The procedure in the above mentioned link does work with my old software ?
It _should_ work; but please try on a test VM and see what works and
what doesn't in your environment.
Hi,

again thanks for your quick answer. I had a look on https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit
and i liked it. I'm thinking of upgrading my systems to SLES 12 SP3. With that i have qemu 2.9.1 and libvirt 3.3.0, so it should work.
Does this procedure also work with raw files ?

Bernd



Helmholtz Zentrum München
Kashyap Chamarthy
2018-02-16 15:54:25 UTC
Permalink
On Fri, Feb 16, 2018 at 04:37:38PM +0100, Lentes, Bernd wrote:

[...]
Post by Lentes, Bernd
Hi,
again thanks for your quick answer. I had a look on
https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit
and i liked it. I'm thinking of upgrading my systems to SLES 12 SP3.
With that i have qemu 2.9.1 and libvirt 3.3.0, so it should work.
Yep.
Post by Lentes, Bernd
Does this procedure also work with raw files ?
Your *base* image can (IIRC) be raw, but all the overlay files _must_ be
QCOW2. But again, you can test it in 10 minutes on a VM :-)
--
/kashyap
Lentes, Bernd
2018-02-20 10:35:12 UTC
Permalink
Hi,

i just realized that i have a guest with two disks. What would be the appropiate way to snapshot both of them ?

virsh snapshot-create-as --domain guest --diskspec vda,file=/path/to/snapshot/snapshot1.qcow2 -disk-only --atomic &&
virsh snapshot-create-as --domain guest --diskspec vdb,file=/path/to/snapshot/snapshot2.qcow2 -disk-only --atomic

or

virsh snapshot-create-as --domain guest --diskspec vda,file=/path/to/snapshot/snapshot1.qcow2 --diskspec vdb,file=/path/to/snapshot/snapshot2.qcow2 --disk-only --atomic



Bernd


Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671
Kashyap Chamarthy
2018-03-29 09:23:58 UTC
Permalink
On Tue, Feb 20, 2018 at 11:35:12AM +0100, Lentes, Bernd wrote:

(Just noticed this question.)
Post by Lentes, Bernd
Hi,
i just realized that i have a guest with two disks. What would be the
appropiate way to snapshot both of them ?
[...]
Post by Lentes, Bernd
or
virsh snapshot-create-as --domain guest --diskspec
vda,file=/path/to/snapshot/snapshot1.qcow2 --diskspec
vdb,file=/path/to/snapshot/snapshot2.qcow2 --disk-only --atomic
The above should work.

[...]
--
/kashyap
Kashyap Chamarthy
2018-02-15 11:10:05 UTC
Permalink
Post by Lentes, Bernd
Hi,
[...]
Post by Lentes, Bernd
I have several guests running with raw files, which is sufficent for
me. Now i'd like to snapshot one guest because i make heavy
configuration changes on it. From what i read in the net is that
libvirt supports snapshoting of raw files when the guest is shutdown
and the file of the snapshot becomes a qcow2. Right ?
The guest doesn't have to be shutdown.

First of all the term "snapshot" is a bit overloaded. There are
different kinds of snapshots. Refer slide-7 here[*].

In your case, since you want to take a snapshot of a raw disk image,
we'll be talk about "external snapshots". So let's spell out what
exactly happens when you try to take live snapshot of a raw disk image.

If you have a disk image (to which live QEMU is writing):

A.raw (live QEMU)

When you create an "external snapshot" as below:

$ virsh snapshot-create-as --domain vm1 disk-state1 \
--diskspec vda,file=/export/images/B.qcow2 \
--disk-only --atomic

You will get the following:

A.raw <-- B.qcow2 (live QEMU)

What it means is the original A.raw is turned into a read-only backing
file. A new QCOW2 "overlay" (B.qcow2) is created, and all the new
writes from now on will happen in B.qcow2.

In the above scenario, `virsh snapshot-revert` will not work (as of
now). If you now want to rever to A.raw, you have to:

(1) Shutdown the guest:

$ virsh shutdown vm1

(2) Edit the guest XML so that it now points to A.raw:

$ virsh edit vm1

And update the 'source file' attribute:
...
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/my/A.raw'/>
...

(3) Start the guest again:

$ virsh start vm1

* * *

If you want to take backups, there's a cleaner way:

https://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit

The above is possible with QEMU 2.1 (and above), libvirt-1.2.9 (and
above). So, in your environment, you have to upgrade.
Post by Lentes, Bernd
I try to avoid converting my raw file to a qcow2 file. I can shutdown
the guest for a certain time, that's no problem. I don't need a live
snapshot. But how can i revert to my previous state if my
configuration changes go wrong ? Can i do this with snapshot-revert
or do i have to edit the xml file and point the hd again to the origin
raw file ? What i found in the net wasn't complete clear.
I answered your questions above to keep them in one place. (Yes, you're
right — you have to edit the XML file and point to the original disk.)

The command `virsh snapshot-revert` works only with "internal snapshots"
— where your original and the delta, all of them reside in the single
QCOW2 file.


PS: I also fixed the quoting in your email, it was a bit off.

[*] https://kashyapc.fedorapeople.org/virt/lc-2012/lceu-2012-virt-snapshots-kashyap-chamarthy.pdf
--
/kashyap
Loading...