[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re
From: |
Prof. Dr. Michael Schefczyk |
Subject: |
Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request) |
Date: |
Sat, 22 Nov 2014 17:02:49 +0000 |
Dear All,
after some trying, my impression is that the following steps do work with plain
Centos 7:
virsh snapshot-create-as VM backsnap
qemu-img convert -f qcow2 -s backsnap -O qcow2 VM.img backup.img
virsh snapshot-delete VM backsnap
Am I on the right track with these commands?
The further features seem to be reserved to RHEL (and potentially other
distributions) but not included in Centos:
virsh snapshot-create-as issues "Live Disk Snapshot not supported in this
version of QEMU" (retranslated from German).
virsh blockcommit issues "Online Transfer not supported ..."
Thus, with Centos 7 it should be possible to back up VMs without shutting them
down. They are being paused, however, as long as the snapshot is created. The
qemu-guest-agent does not help in this context, as the features which depend on
it are not available in Centos.
Regards,
Michael
-----Ursprüngliche Nachricht-----
Von: Eric Blake [mailto:address@hidden
Gesendet: Mittwoch, 19. November 2014 19:13
An: Prof. Dr. Michael Schefczyk; Paolo Bonzini; qemu-devel
Betreff: Re: AW: [Qemu-devel] "File too large" error from "qemu-img snapshot"
(was Re: AW: Bug Repoting Directions Request)
On 11/19/2014 10:32 AM, Prof. Dr. Michael Schefczyk wrote:
> Dear Eric, dear all,
>
> Again, thank you very much. I now gather that I took the wrong path towards
> nightly backups of running VM. I remain surprised that I did work for a
> relatively long time.
[can you convince your mailer to wrap long lines? also, we tend to frown on
top-posting on technical lists]
Yeah, you were just getting lucky that two different processes weren't both
trying to allocate a cluster for different purposes at the same time. When the
collision finally did happen, it had catastrophic results on your image.
>
> A major book on KVM in German language by Kofler & Spenneberg recommends the
> following approach for online backups (with and without "--disk-only"):
>
> virsh snapshot-create-as vm XXX --disk-only qemu-img convert -f qcow2
> -s XXX -O qcow2 XXX.img /backup/YYY.img virsh snapshot-delete vm XXX
Yes, virsh is using QMP commands under the hood, so this method is safe.
One slight issue is that this sequence is incomplete (it does not shrink the
backing file chain after the copy is complete), so if you keep repeating it,
you will eventually cause reduced performance when you have a really long chain
of multiple qcow2 overlays, or even cause qemu to run into fd exhaustion.
Also, this command does not show that unless you clean things up, then the
second time you run this you do not want to copy XXX.img into backup, but
instead the qcow2 wrapper file that was created by the first snapshot (and
which itself wrapped by the second snapshot).
With new enough libvirt and qemu, you can shrink the chain back down with an
active commit, as in:
virsh blockcommit vm XXX --verbose --active --pivot
Also, the use of --disk-only means that your disks have a snapshot taken as if
at a point in time when you yank the power cord; reverting to such a backup may
require fsck, and may suffer from other problems from anything that was
depending on I/O that had not yet been flushed to disk. If you add the
--quiesce option (which implies that you set up your guest to use
qemu-guest-agent, and told libvirt to manage the agent), then you can guarantee
that your guest has flushed and frozen all filesystems prior to the point in
time where the snapshot is created; and you can even install hooks in the guest
to extend that stability to things like databases. Then your backups are much
easier to use. If you omit --disk-only, and take a full snapshot, then you
have the guest memory state that is necessary to restore all pending I/O, and
don't need to worry about freezing the guest file systems; but then you have to
remember to back up the memory state in addition to your disk state.
>
> Would this be any better than my script, because it uses virsh
> snapshot-create-as instead of qemu-img snapshot? The second command is still
> qemu-img convert which may be problematical.
No, remember what I said. qemu-img may not be used on any image that is opened
read-write by qemu, but is perfectly safe to do read-only operations on any
image that is opened read-only by qemu. That sequence of commands goes from
the initial:
disk.img [read-write]
then the snapshot-create command causes libvirt to issue a QMP command to
switch qemu to:
disk.img [read-only] <- overlay.qcow2 [read-write]
at which point you can do anything read-only to disk.img (whether 'qemu-img
convert' or 'cp' or any other command that doesn't alter the contents of the
file)
finally, the 'virsh blockcommit' command would take you back to:
disk.img [read-write]
>
> The problem I am facing is that the documentation is not easy to understand
> for the average user/administrator who is not among the kvm developers and
> experts. I have of course tried to read section 14.2.3 of RHEL 7
> Virtualization Deployment and Administration Guide on backups, but I found
> that too cryptic for someone like myself to draw practical consequences from
> it.
If you are using libvirt to manage your guests, then yes, the qemu
documentation is cryptic, but that shouldn't matter - you should be asking the
libvirt community how to accomplish a job. And yes, libvirt could probably do
a better job of advertising and documenting its level of support for live
backups, but that is more a question for the address@hidden mailing list (the
archive of that list show that questions like this come up very regularly; you
are not the first to ask about live backups, so perusing those archives may
give you some ideas on what works).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
smime.p7s
Description: S/MIME Cryptographic Signature
- [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Paolo Bonzini, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Max Reitz, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Prof. Dr. Michael Schefczyk, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Paolo Bonzini, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Prof. Dr. Michael Schefczyk, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Paolo Bonzini, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Eric Blake, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Prof. Dr. Michael Schefczyk, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Eric Blake, 2014/11/19
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request),
Prof. Dr. Michael Schefczyk <=
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Paolo Bonzini, 2014/11/24
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Kevin Wolf, 2014/11/25
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Prof. Dr. Michael Schefczyk, 2014/11/25
- Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request), Kashyap Chamarthy, 2014/11/24