[libvirt-users] snapshot of a raw file - how to revert ?
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:bernd.lentes@helmholtz-muenchen.de | bernd.lentes@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
----- On Feb 13, 2018, at 1:38 PM, Bernd Lentes bernd.lentes@helmholtz-muenchen.de wrote:
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
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
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. 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-snapshot... 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
On Thu, Feb 15, 2018 at 11:41:37AM +0100, Lentes, Bernd wrote: [...]
Hi,
i found that: https://dustymabe.com/2015/01/11/qemu-img-backing-files-a-poor-mans-snapshot...
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
----- On Feb 15, 2018, at 12:53 PM, Kashyap Chamarthy kchamart@redhat.com wrote:
On Thu, Feb 15, 2018 at 11:41:37AM +0100, Lentes, Bernd wrote:
[...]
Hi,
i found that: https://dustymabe.com/2015/01/11/qemu-img-backing-files-a-poor-mans-snapshot...
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
--
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
On Fri, Feb 16, 2018 at 01:59:01PM +0100, Lentes, Bernd wrote: [...]
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.
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
----- On Feb 16, 2018, at 3:01 PM, Kashyap Chamarthy kchamart@redhat.com wrote:
On Fri, Feb 16, 2018 at 01:59:01PM +0100, Lentes, Bernd wrote:
[...]
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
On Fri, Feb 16, 2018 at 04:37:38PM +0100, Lentes, Bernd wrote: [...]
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.
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
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
On Tue, Feb 20, 2018 at 11:35:12AM +0100, Lentes, Bernd wrote: (Just noticed this question.)
Hi,
i just realized that i have a guest with two disks. What would be the appropiate way to snapshot both of them ?
[...]
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
On Tue, Feb 13, 2018 at 01:38:34PM +0100, Lentes, Bernd wrote:
Hi,
[...]
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.
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-kash... -- /kashyap
participants (2)
-
Kashyap Chamarthy -
Lentes, Bernd