On Sun, Feb 15, 2009 at 2:57 AM, Gleb Natapov <g...@redhat.com> wrote: > > I am not able to reproduce this. After more then hundred boot linux; generate > disk io; quit loops all I've got is an image with 7 leaked blocks and > couple of filesystem corruptions that were fixed by fsck.
The type of activity occuring in the guest is most likely an important factor determining the probability of the bug occuring. So you should try running guest OSes I remember having been affected by it: Windows 2003 SP2 x64. And now that I think about it, I don't recall any other guest OS having been a victim of that bug... coincidence ? Other factors you might consider when trying to reproduce: the qcow2 images that ended up being corrupted had a backing file (a read-only qcow2 image); NPT was in use; the host filesystem was xfs; my command line was: $ qemu-system-x86_64 -name xxx -monitor stdio -vnc xxx:xxx -hda hda -net nic,macaddr=xx:xx:xx:xx:xx:xx,model=rtl8139 -net tap -boot c -cdrom "" -cpu qemu64 -m 1024 -usbdevice tablet -marc -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
