Bug 1584982
| Summary: | qemu abort()-s on lock failure even if it was running previously | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Peter Krempa <pkrempa> |
| Component: | qemu-kvm-rhev | Assignee: | Fam Zheng <famz> |
| Status: | CLOSED WONTFIX | QA Contact: | CongLi <coli> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.5 | CC: | chayang, coli, dyuan, jiyan, juzhang, juzhou, knoel, lmen, michen, mxie, mzhan, pkrempa, qzhang, rbalakri, tzheng, virt-maint, xiaodwan, xuzhang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1569500 | Environment: | |
| Last Closed: | 2018-06-05 05:09:13 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: | 1524792, 1569500 | ||
| Bug Blocks: | |||
|
Description
Peter Krempa
2018-06-01 05:58:38 UTC
I'll try to reproduce here. Meanwhile, do we have a backtrace of QEMU? Original reporter said that no core was generated. I assumed it was an abort from the messages recorded in the VM log file: Failed to get "write" lock Unexpected error in raw_apply_lock_bytes() at block/file-posix.c:642: 2018-04-19T12:05:47.871711Z qemu-kvm: Failed to lock byte 100 2018-04-19 12:05:52.848+0000: shutting down, reason=crashed The last line is generated by libvirt. I could reproduce this issue with libvirt + virt-xml with the same steps as the original report: 1) start vm with an image file attached; 2) try to attach the image again, which results in an error; 3) detach the image. Step 3) causes an abort of QEMU. The error is rather unexpected from QEMU perspective: it now cannot (re-)acquire the locked bits which are already acquired when VM starting. This op is technically not necessary, but is there to keep the image locking code simple. I think what happened is that Libvirt changed the image file's permission (and/or security context) by mistake in the error handling of step 2), which made it no longer accessible to QEMU process. Before step 2): [root@tc-rhel7 rpm]# ls -lhZ /var/lib/libvirt/images/b.img -rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c600,c690 /var/lib/libvirt/images/b.img After: [root@tc-rhel7 rpm]# ls -lhZ /var/lib/libvirt/images/b.img -rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/b.img Peter, is this a known problem? (In reply to Fam Zheng from comment #4) [...] > > Peter, is this a known problem? Yes, it is. I've cloned this bug from the original report on libvirt: https://bugzilla.redhat.com/show_bug.cgi?id=1569500 Which is a duplicate of a known problem: https://bugzilla.redhat.com/show_bug.cgi?id=1524792 |