Bug 1006122
Summary: | [qemu][rhel6]win8-32 qcow2 image damaged when do system_reset during wakeup from s3 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | guo jiang <jguo> | ||||||
Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> | ||||||
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 6.5 | CC: | acathrow, amit.shah, bcao, bsarathy, chayang, famz, flang, hreitz, juzhang, kwolf, michen, mkenneth, qzhang, stefanha, virt-maint, vrozenfe | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2014-06-05 22:15:40 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 912287 | ||||||||
Attachments: |
|
Description
guo jiang
2013-09-10 04:40:25 UTC
Created attachment 795820 [details]
The screenshot of wakeup from s3, and in this status do system_reset guest.
system_reset in qemu monitor is like pressing the reset button on a physical computer or plugging off the power cord and plugging it back in. Since there's no guest cooperation, the guest could be in the middle of using the disk, have unwritten data in memory, and all that will be lost when system_reset is invoked. Not surprising this can cause image corruption. (In reply to Amit Shah from comment #5) > system_reset in qemu monitor is like pressing the reset button on a physical > computer or plugging off the power cord and plugging it back in. Since > there's no guest cooperation, the guest could be in the middle of using the > disk, have unwritten data in memory, and all that will be lost when > system_reset is invoked. > > Not surprising this can cause image corruption. Amit, is that to say this is not a bug? This looks very much like a bug, ERRORs reported by qemu-img check are almost always bugs. Can you try if this is reproducible on RHEL 7? Is it really necessary to install the QXL driver or does it happen without it as well? Do you still have the image around, so I could have a look at it? (In reply to Kevin Wolf from comment #7) > This looks very much like a bug, ERRORs reported by qemu-img check are almost > always bugs. > > Can you try if this is reproducible on RHEL 7? > > Is it really necessary to install the QXL driver or does it happen without it > as well? > > Do you still have the image around, so I could have a look at it? Hi, Kevin I could not reproduce it with QXL driver installed or without it on rhel6 host, so I could not analysis the reason why image corruption. I have the image and will uploaded. This is a case of two data clusters pointing to the same cluster in the image file, as shown by the following 'qemu-img map' output: Offset Length Mapped to File ... 0x546d70000 0x10000 0x53e6e0000 win8-32-old.qcow2 ... 0x7e13f0000 0x90000 0x53e670000 win8-32-old.qcow2 ... The corrupted cluster (343662 * 64k = 0x53e6e0000) is contained in the "mapped to" area of both allocations. Created attachment 796723 [details]
qemu-img map/check output (with debug messages added to check)
Attaching some qemu-img outputs I gathered on the machine with the broken image.
One is the output of 'qemu-img map' as of current upstream master, the other one
the output of a 'qemu-img check' with added debug output for each reference that
is found and accounted for.
Not sure how relevant it is, but from the qemu-img check output: UPDATE: cluster offset=0x473400000 -> refcount 1 UPDATE: cluster offset=0x473410000 -> refcount 1 UPDATE: cluster offset=0x53e6e0000 -> refcount 1 UPDATE: cluster offset=0x540c90000 -> refcount 1 UPDATE: cluster offset=0x540ca0000 -> refcount 1 ... UPDATE: cluster offset=0x53e6c0000 -> refcount 1 UPDATE: cluster offset=0x53e6d0000 -> refcount 1 UPDATE: cluster offset=0x53e6e0000 -> refcount 2 UPDATE: cluster offset=0x53e6f0000 -> refcount 1 UPDATE: cluster offset=0x53e740000 -> refcount 1 This shows that one of the allocations is a single cluster allocation, whereas the other one is part of a longer contiguous allocation. S3/S4 support is tech-preview in RHEL6 and it'll be promoted to fully supported at some point, but only in RHEL7. Therefore we're closing all S3/S4 related bugs in RHEL6. New bugs will be considered only if they're regressions or break some important use-case or certification. RHEL7 is being more extensively tested and effort from QE is underway in certifying that this particular bug is not present there. Please reopen with a justification if you believe this bug should not be closed. We'll consider them on a case-by-case basis following a best effort approach. Thank you. |