Discussion:
[libvirt-users] qemu-img snapshot on running virtual machine
Gionatan Danti
2018-03-14 08:36:52 UTC
Permalink
Hi all,
I have a question about internal qcow2 snapshots of a live/running
virtual machine taken via "qemu-img snapshot command".

My question is: is it safe to execute the command above against a
running machine? Or it will cause corruption? Naively I think it should
*not* be safe, however, I would like a direct confirmation.

Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
Ján Tomko
2018-03-15 08:13:39 UTC
Permalink
Post by Gionatan Danti
Hi all,
I have a question about internal qcow2 snapshots of a live/running
virtual machine taken via "qemu-img snapshot command".
My question is: is it safe to execute the command above against a
running machine? Or it will cause corruption? Naively I think it should
*not* be safe, however, I would like a direct confirmation.
It is not safe.

For a running domain, you need to go through libvirt and also save the
memory of the VM - doing just the disk snapshot for a running machine
would be an equivalent of copying a physical hard drive after pulling
out the power cord.

Jan
Gionatan Danti
2018-03-15 13:55:44 UTC
Permalink
Post by Ján Tomko
It is not safe.
For a running domain, you need to go through libvirt and also save the
memory of the VM - doing just the disk snapshot for a running machine
would be an equivalent of copying a physical hard drive after pulling
out the power cord.
Jan
Hi Jan, I 100% agree that taking a snapshot without dumping the memory
content would be akin to "pulling the plug" on the guest.

However, I was speaking about disk image file consistency. In other
words: does taking a snapshot of an in-use virtual disk have a chance to
corrupt the *original* disk Qcow2 image file?

Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
Eric Blake
2018-03-15 15:49:03 UTC
Permalink
Post by Gionatan Danti
Post by Ján Tomko
It is not safe.
For a running domain, you need to go through libvirt and also save the
memory of the VM - doing just the disk snapshot for a running machine
would be an equivalent of copying a physical hard drive after pulling
out the power cord.
Jan
Hi Jan, I 100% agree that taking a snapshot without dumping the memory
content would be akin to "pulling the plug" on the guest.
However, I was speaking about disk image file consistency. In other
words: does taking a snapshot of an in-use virtual disk have a chance to
corrupt the *original* disk Qcow2 image file?
Yes, having two processes (in this case, the qemu process under
libvirt's control, and the qemu-img process) both trying to write to a
single qcow2 file at once is a recipe for disaster. You are VERY likely
to cause irreparable disk corruption; although at least newer
qemu/qemu-io binaries now use file locking to at least fail up front
when they detect that another process has the image open for writing,
rather than letting you shoot yourself in the foot.

The only SAFE way to take a snapshot of a running virtual machine is
through commands issued to the qemu process that is running the machine
(that is, via libvirt APIs if libvirt is managing the qemu process).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Gionatan Danti
2018-03-16 09:21:42 UTC
Permalink
Post by Eric Blake
Yes, having two processes (in this case, the qemu process under
libvirt's control, and the qemu-img process) both trying to write to a
single qcow2 file at once is a recipe for disaster.  You are VERY likely
to cause irreparable disk corruption; although at least newer
qemu/qemu-io binaries now use file locking to at least fail up front
when they detect that another process has the image open for writing,
rather than letting you shoot yourself in the foot.
The only SAFE way to take a snapshot of a running virtual machine is
through commands issued to the qemu process that is running the machine
(that is, via libvirt APIs if libvirt is managing the qemu process).
Roger :)
Thanks so much, Eric.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: ***@assyoma.it - ***@assyoma.it
GPG public key ID: FF5F32A8
Loading...