[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

[Expired for QEMU because there has been no activity for 60 days.] ** Changed in: qemu Status: Incomplete => Expired -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Can we close this ticket now? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: New Bug description:

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Hi Claus, Thanks for the info! By now we know that the XFS bug can only be triggered with aio=native (for -drive), and since you aren’t using that, you won’t hit that. I suppose using git master works in the meantime, but in general of course it isn’t advisable for stability. (Yes, yes, I

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Which filesystems does this apply to? Excludes ZFS? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: New

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Sorry for the delay,I was busy doing my job the last two weeks. I use XFS V5 on both main host (5.3.7-arch1-2-ARCH) and backup host (5.3.5-arch1-1-ARCH). It seems I ran in the first bug that has been fixed upstream. With git master (git clone at 18.10.) I could not reproduce the failure on my

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

There is a patch for the XFS kernel driver to fix the bug: https://www.spinics.net/lists/linux-xfs/msg33429.html On the qemu side, we’re still discussing on how to work around the bug in the 4.2 release. Max -- You received this bug notification because you are a member of qemu- devel-ml,

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

I have the same (related?) issue and wanted to add my experience with it. I had 3 qemu qcow2 VM running on ArchLinux. I never used snapshots or something like it. Just normal start 2 of these VMs were also ArchLinux running on ext4. Both of these VMs had a data corruption inside the quest. The

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

I suppose that the problem described in bug 1846427 can also affect guest data, so I think it makes sense to divide based on whether there are only data corruptions or both data and metadata corruptions. So far, I don’t know of a report of pure guest data corruptions (without qcow2 metadata being

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

i've seen guest data corruption and qcow2 corruption on ext4. i've seen one case where the guest (win10) reports corruption but qemu- img check does not, but that's the outlier, usually both guest and qemu- img report corruption. for me the issue seems to only be win10 guests using virtio-scsi,

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

The bug reported here is not about qcow2 metadata corruption, but about guest data corruption (qemu-img check reports a clean image). It’s entirely possible (and I would even say likely) that there are two different causes. We know about two guest data corruptions already (which appeared in

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Hi Max, from my : I've seen corruption on ext4. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

I can confirm exactly the same issue on Arch linux with ext4 filesystem (qemu-4.1.0). After downgrading from 4.1.0 => 4.0.0 everything is running normal again, no corruption detected and all qcow2 images stays healthy. -- You received this bug notification because you are a member of qemu-

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Hi Claus, Do you use XFS on the host? Max -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1847793 Title: qemu 4.1.0 - Corrupt guest filesystem after new vm install Status in QEMU: New Bug

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

OK, thanks. This might be the same problem as https://bugs.launchpad.net/qemu/+bug/1846427 but we'll have to see. For a bisect; first of all, check out qemu from git and build 4.1.0; check to make sure this breaks. Now, see the git bisect instructions at: https://git-scm.com/docs/git-bisect

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Hi David, a) > qemu-img check /volumes/disk2-part2/images/vmtest10-1.qcow2 No errors were found on the image. 24794/327680 = 7.57% allocated, 9.28% fragmented, 0.00% compressed clusters Image end offset: 1625751552 > qemu-img info /volumes/disk2-part2/images/vmtest10-1.qcow2 image:

[Bug 1847793] Re: qemu 4.1.0 - Corrupt guest filesystem after new vm install

Hi Claus, Some things to try: a) after you quit qemu can you try qemu-img check on the qcow2 file to see if it's happy? b) If you repeat your test using a raw image file rather than a qcow2 is it any happier? c) How repeatable is it? If it's very repeatable it would be great if you