qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Tiziano Müller" <tiziano.mueller@stepping-stone.ch>
To: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Silent filesystem/qcow2 corruptions with qemu-kvm-1.0 and 1.1.1
Date: Thu, 11 Oct 2012 15:33:23 +0200	[thread overview]
Message-ID: <1349962403.4696.51.camel@storm> (raw)

Hi everyone

We have a couple of VMs, each with QCow2-files as disk images and we are
seeing random filesystem/qcow2 corruptions of the VM filesystems.

We have two types of corruptions:
* if the guest OS uses XFS, we get corruption errors originating most of
the time in xfs_da_do_buf inside the VM.
* if the guest OS uses ext4 (on rare occasions also XFS), there are most
of the time no noticeable faults in the guest until qemu shuts down with
the following messages (maybe that's a different case and unrelated to
the first one):
handle_dev_stop: stop
handle_dev_stop: stop
handle_dev_stop: stop
qcow2_free_clusters failed: Invalid argument
[...]
qcow2_free_clusters failed: Invalid argument
handle_dev_stop: stop
handle_dev_stop: stop
2012-10-09 00:52:49.294+0000: shutting down

(one time there was also a message before the end about a failed assert
in a qcow-related function)

Checking the image using `qemu-img check` then gives something like
this:

ERROR OFLAG_COPIED: offset=3bc30000 refcount=1
ERROR offset=c7e331: Cluster is not properly aligned; L2 entry
corrupted.
ERROR: invalid cluster offset=0x3aa4810400fa0000
ERROR offset=fa000000001000: Cluster is not properly aligned; L2 entry
corrupted.
ERROR: invalid cluster offset=0x80966181ff0000
ERROR: invalid cluster offset=0x80966182000000
ERROR offset=80966181ffffff: Cluster is not properly aligned; L2 entry
corrupted.
ERROR: cluster 280376143330560: copied flag must never be set for
compressed clusters
Warning: cluster offset=0x286d3d000000 is after the end of the image
file, can't properly check refcounts.
Warning: cluster offset=0x286d3d010000 is after the end of the image
file, can't properly check refcounts.

We can observe such corruptions on two servers:
* one with qemu-kvm-1.1 and kernel 3.5.2 (for the kernel configuration see [1])
* the second one with qemu-kvm-1.0 and kernel 3.2.6 (for the kernel configuration see [2])

The corruptions happen up a lot faster and more often on server 1 with
qemu-kvm-1.1 and do not depend on whether write operations happen or
not.

One test case was:
* xfs_repair /dev/vda2 -> corruptions found and fixed
* xfs_repair /dev/vda2 -> no corruptions found
* mount /dev/vda2 /mnt/something
* find /mnt/something > /dev/null
* umount /mnt/something
* xfs_repair /dev/vda2 -> corruptions found again

The interesting thing here is that xfs_repair shows bad magic numbers of
0x0 most of the time which would indicate that blocks get zeroed out and
not randomly overwritten.

The guest kernels range from 3.2 to 3.5, used distros: Gentoo, Fedora,
Ubuntu, all x86_64.

The host filesystem is XFS as well, on a LVM volume on a RAID1 (Megaraid
SAS). Management is done with libvirt and we are using virtio-blk with
cache=writeback (an example configuration of a VM is found in [3]).

We were unable to trigger this deliberately, some of the VMs were
running without problems for more than a month (server 2), some of them show
problems after a couple of hours (server 1).

We checked:
* in the host: memory and LVM using memtester, verify-data and
badblocks. We also tried with a brand new XFS volume and brand new qcow2
files.
* in the VMs: memory using memtest86+ and the virtual disk using
verify-data (verify-data -e /dev/vda3 1M 10000). Both test are currently
running without problems so far. The only suspicious thing is that
verify-data sometimes hangs for up to a minute (as do all block
operations in that VM), but `dmesg` does not show anything.

Does anyone has any ideas on how to narrow this problem down further or
how to debug it?

We are currently setting up another server with qemu-1.1.2 or qemu-1.2.0
and would like to be able to reproduce this problem before and make sure
we don't face the same problems there again.

We can provide logs of almost everything if required. We could also
provide SSH and/or Spice access to one or more VMs running on the server
if that helps and someone would be willing to help track down this
problem.

Similar problems were already mentioned here, but without a solution:
* https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1040033
* http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01756.html

Thanks in advance,
Tiziano

[1] server1 kernel config: http://bpaste.net/show/rajkzUNGLdmo95sl35YE/
[2] server2 kernel config: http://bpaste.net/show/cAFQ7FhJzfjAorIirUj6/
[3] libvirt vm xml: http://bpaste.net/show/D7nRCbr26f9nmapq5gTo/
[4] qemu-kvm invocation: http://bpaste.net/show/Mgrq9AeD2ehBfI43SH5u/
-- 
stepping stone GmbH
Neufeldstrasse 9
CH-3012 Bern
Telefon: +41 31 332 53 63
www.stepping-stone.ch
tiziano.mueller@stepping-stone.ch

             reply	other threads:[~2012-10-11 13:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-11 13:33 Tiziano Müller [this message]
2012-10-12  8:28 ` [Qemu-devel] Silent filesystem/qcow2 corruptions with qemu-kvm-1.0 and 1.1.1 Stefan Hajnoczi
2012-10-12  8:53   ` Tiziano Müller
2012-10-12  8:33 ` Stefan Hajnoczi
2012-10-12  8:53   ` Tiziano Müller
2012-10-15  7:48     ` Stefan Hajnoczi
2012-10-15  9:34       ` Tiziano Müller
2012-10-15 11:11     ` Kevin Wolf
2012-10-15 11:39       ` Tiziano Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1349962403.4696.51.camel@storm \
    --to=tiziano.mueller@stepping-stone.ch \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).