Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Using qemu-img to modify an image that is in use can corrupt the image
Opening a QEMU disk image from multiple processes at the same time, for example by attempting to take a snapshot of a QEMU image while the guest is running, in some cases corrupts the image. To avoid this problem, never use the qemu-img utility to modify images in use by a running virtual machine or any other process. In addition, be aware that querying an image that is being modified by another process may trigger an inconsistent state error. This update also adds an admonition about the mentioned problem to the qemu-img(1) man page.
This should be a backport of
commit 48467328c6dccc9c7be6628ed0ef0810f83be2a9
Author: Kevin Wolf <kwolf>
Date: Thu Aug 16 10:56:35 2012 +0200
Documentation: Warn against qemu-img on active image
People have repeatedly expected that you can do things like snapshotting
an image with qemu-img while a qemu instance is running. Maybe we need
to consider locking the files while they are in use, but having a
warning in the qemu-img manpage is doable for 1.2 and can't hurt anyway.
Signed-off-by: Kevin Wolf <kwolf>
+++ This bug was initially created as a clone of Bug #1277167 +++
--- Additional comment from Ademar Reis on 2016-01-11 11:29:58 BRST ---
(In reply to Frank DeLorey from comment #0)
>
> Before this problem happened, customer took a snapshot when the vm was
> running:
>
> # /usr/bin/qemu-img snapshot -c snapshot-test-20151019
> /var/lib/libvirt/images/kpd-dbw.qcow2
>
> When trying to delete the snapshot, customer sees the same error message.
>
> # /usr/bin/qemu-img snapshot -l /var/lib/libvirt/images/kpd-dbw.qcow2
> Could not open '/var/lib/libvirt/images/kpd-dbw.qcow2': File too large
>
> # /usr/bin/qemu-img snapshot -d snapshot-test-20151029
> /var/lib/libvirt/images/kpd-dbw.qcow2
> Could not open '/var/lib/libvirt/images/kpd-dbw.qcow2': File too large
>
This will lead to image corruption for sure, so this is expected. One should never use qemu-img snapshot on a running VM. You can see a more complete explanation in the upstream bug you've mentioned (https://bugs.launchpad.net/qemu/+bug/1354167/comments/12):
"[...] it turned out that qemu-img snapshot was used on the image while the VM is running. This was likely the root cause of the corruption. So if you're reading this, it's probably already too late, but I want to spell it out anyway:
WARNING: Never open the same disk image from two processes at the same time, except if both are read-only! If your VM is running, use the qemu monitor of that VM (or libvirt functionality, which will do the same internally) to do operations on the image. Use qemu-img only for images of shut down VMs."
If the customer followed some of our documentation when doing it, then it should be fixed. There are recent and recurrent upstream discussions about adding some sort of locking to qemu and qemu-img, but there's no consensus, as this would add complexity and require cleanups in case of crashes.
You can see more details about a recent discussion here:
https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04279.html
Anyway, we should at least backport to RHEL6 the warning which was added to qemu-img's manpage back in 2012. I'll open a new BZ to track that.
Verified with:
qemu-kvm-0.12.1.2-2.484.el6.x86_64
qemu-img-0.12.1.2-2.484.el6.x86_64
Warning added to manpage in DESCRIPTION part.
# man qemu-img
QEMU-IMG(1) QEMU-IMG(1)
NAME
qemu-img - QEMU disk image utility
SYNOPSIS
usage: qemu-img command [command options]
DESCRIPTION
qemu-img allows you to create, convert and modify images offline. It can handle all image formats supported by QEMU.
Warning: Never use qemu-img to modify images in use by a running virtual machine or any other process; this may destroy the
image. Also, be aware that querying an image that is being modified by another process may encounter inconsistent state.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-0815.html
This should be a backport of commit 48467328c6dccc9c7be6628ed0ef0810f83be2a9 Author: Kevin Wolf <kwolf> Date: Thu Aug 16 10:56:35 2012 +0200 Documentation: Warn against qemu-img on active image People have repeatedly expected that you can do things like snapshotting an image with qemu-img while a qemu instance is running. Maybe we need to consider locking the files while they are in use, but having a warning in the qemu-img manpage is doable for 1.2 and can't hurt anyway. Signed-off-by: Kevin Wolf <kwolf> +++ This bug was initially created as a clone of Bug #1277167 +++ --- Additional comment from Ademar Reis on 2016-01-11 11:29:58 BRST --- (In reply to Frank DeLorey from comment #0) > > Before this problem happened, customer took a snapshot when the vm was > running: > > # /usr/bin/qemu-img snapshot -c snapshot-test-20151019 > /var/lib/libvirt/images/kpd-dbw.qcow2 > > When trying to delete the snapshot, customer sees the same error message. > > # /usr/bin/qemu-img snapshot -l /var/lib/libvirt/images/kpd-dbw.qcow2 > Could not open '/var/lib/libvirt/images/kpd-dbw.qcow2': File too large > > # /usr/bin/qemu-img snapshot -d snapshot-test-20151029 > /var/lib/libvirt/images/kpd-dbw.qcow2 > Could not open '/var/lib/libvirt/images/kpd-dbw.qcow2': File too large > This will lead to image corruption for sure, so this is expected. One should never use qemu-img snapshot on a running VM. You can see a more complete explanation in the upstream bug you've mentioned (https://bugs.launchpad.net/qemu/+bug/1354167/comments/12): "[...] it turned out that qemu-img snapshot was used on the image while the VM is running. This was likely the root cause of the corruption. So if you're reading this, it's probably already too late, but I want to spell it out anyway: WARNING: Never open the same disk image from two processes at the same time, except if both are read-only! If your VM is running, use the qemu monitor of that VM (or libvirt functionality, which will do the same internally) to do operations on the image. Use qemu-img only for images of shut down VMs." If the customer followed some of our documentation when doing it, then it should be fixed. There are recent and recurrent upstream discussions about adding some sort of locking to qemu and qemu-img, but there's no consensus, as this would add complexity and require cleanups in case of crashes. You can see more details about a recent discussion here: https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04279.html Anyway, we should at least backport to RHEL6 the warning which was added to qemu-img's manpage back in 2012. I'll open a new BZ to track that.