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.
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 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. 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. Regards, Michael ___________________________________________________________ Technische Universität Dresden Fakultät Wirtschaftswissenschaften Lehrstuhl für Entrepreneurship und Innovation Prof. Dr. Michael Schefczyk D-01062 Dresden Fon: +49-3 51-4 63-3 68 81 Fax: +49-3 51-4 63-3 68 83 www.gruenderlehrstuhl.de -----Ursprüngliche Nachricht----- Von: Eric Blake [mailto:ebl...@redhat.com] Gesendet: Mittwoch, 19. November 2014 16:44 An: Paolo Bonzini; Prof. Dr. Michael Schefczyk; qemu-devel Betreff: Re: [Qemu-devel] "File too large" error from "qemu-img snapshot" (was Re: AW: Bug Repoting Directions Request) On 11/19/2014 07:54 AM, Paolo Bonzini wrote: > On 19/11/2014 13:07, Prof. Dr. Michael Schefczyk wrote: >> Yes! My level of knowledge is that one uses the qcow2 format in order >> to be able to create live snapshots/backups. Otherwise one would tend >> to use the more efficient raw format. Is this not correct and did I >> apply the backup mechanism in the wrong way? > > That's correct, but you still have to create live snapshots from > within QEMU. You absolutely CANNOT modify a qcow2 file via qemu-img or any other external means while qemu is using the file in read-write mode, or you risk file corruption (which appears to be what happened to you). Monitor commands to the qemu process are the only supported means for taking a live snapshot/backup of an in-use disk. > > This is done with a QMP (QEMU Management Protocol) command like > > { "execute": "blockdev-snapshot-internal-sync", > "arguments": { "device": "ide-hd0", > "name": "snapshot0" } > } > > QMP is accessed through normal sockets, or via libvirt. > > However, I'm not sure if running "qemu-img convert" on the resulting > snapshot is possible though, and there is no equivalent of "qemu-img > snapshot -d". qemu-img snapshot -d can be achieved via the QMP monitor command 'human-monitor-command' forwarding to the HMP 'delvm' command. But you are correct that I don't know of any way to reproduce qemu-img convert on a read-write image. > > You can instead use QEMU's support for backup, which will do what you > wanted directly while the VM is running. For example: > > { "execute": "drive-backup", "arguments": { "device": "ide-hd0", > "sync": "full", "format": "qcow2", > "target": "backup.img" } } > > This does not even require qcow2 for the image. The downside is that > you must not turn off the VM until the job has completed. Another option is to create a live snapshot (so that your file under interest is now read-only with a temporary qcow2 overlay as the read-write file), then you can do whatever you want with the file (such as qemu-img convert), and finally do an active commit to get rid of the temporary qcow2 overlay and back to just the main live image. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
smime.p7s
Description: S/MIME Cryptographic Signature