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.

+++ This bug was initially created as a clone of Bug #836710 +++

For a full description of the bug, read this:

https://www.redhat.com/archives/libguestfs/2012-July/msg00020.html

Hello,
I tried your script and do more than 500 runs, it has no error output.
https://bugzilla.redhat.com/show_bug.cgi?id=836710#c5

Is there need other steps to repoduce?

(In reply to bfan from comment #2)
> Hello,
> I tried your script and do more than 500 runs, it has no error output.
> https://bugzilla.redhat.com/show_bug.cgi?id=836710#c5
> 
> Is there need other steps to repoduce?

This was actually a bug in qemu.  The problem was that
qemu's qcow2 code used to crash, and libguestfs didn't
detect the crash (so instead you would just get occasional
lost data writes).  Since then:

 - qemu was fixed so the qcow2 code no longer crashes

 - the kernel was fixed so it issues a write barrier for sync

 - libguestfs has been modified to add a guestfs_shutdown
   call to detect these crashes and report the error
   instead of ignoring it.

Since this was all fixed a long time ago, it's unlikely
that you will be able to reproduce the bug.  You would
have to go back to some quite old versions of qemu, kernel
and libguestfs.

My suggestion is that we close this bug.  Even if the
qemu bug reappears, libguestfs will now detect and report
it.

I am closing this, based on my previous comment.