Am Montag, den 15.10.2012, 09:48 +0200 schrieb Stefan Hajnoczi: > Okay, that's consistent with the other symptoms you've reported. > > It's not clear whether the corruption arises inside qcow2 or if > something else is causing corruption and qcow2/xfs get upset. That is > the next step to debugging this - hopefully it will become possible to > reproduce it reliably, at which point it is much easier to debug :).
Yes, we have now 3 different VM-configurations deployed on the server where we saw the most corruptions so far: * config 1: as-is * config 2: raw-image format instead of qcow2 as you suggested * config 3: vhost=off for the network The third test-case is because we figured out that one major difference between the two servers is that on the server with the most corruptions we have vhost=on (automatically turned on by qemu/libvirt because the vhost-net module got loaded). I know this does not make a lot of sense. In fact, on the server without vhost-net (and with qemu-1.0) we only saw one corruption after all (where the qcow2 got really messed up), so one could assume that this was a single event and may have been a user error. To summarize it: * server 1 (qemu-kvm-1.1, host-kernel 3.5.2, vhost-net loaded and used) has had +5 machines with corrupt filesystems (ext4 and xfs) and 1 machine with a corrupt qcow2. * server 2 (qemu-kvm-1.0, host-kernel 3.2.6, vhost-net not loaded) has had only 1 machine with a corrupt qcow2. The mentioned Test-VMs are running since Friday and unfortunately none of them had the decency to go corrupt again. We will keep you posted, thanks a lot for your help. Best regards, Tiziano -- stepping stone GmbH Neufeldstrasse 9 CH-3012 Bern Telefon: +41 31 332 53 63 www.stepping-stone.ch tiziano.muel...@stepping-stone.ch
