Bug 876828
| Summary: | the qcow2 disk's major:minor number still exists in guest's devices.list after hot-unplug | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ming Tian <mitian> |
| Component: | libvirt | Assignee: | Eric Blake <eblake> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.4 | CC: | acathrow, ajia, dallan, dyasny, dyuan, eblake, jdenemar, mzhan, rwu, zhpeng, zpeng |
| Target Milestone: | rc | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0.10.2-11.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-21 07:26:42 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: | 886216 | ||
Since it works on libvirt-0.9.10-21.el6.x86_64.rpm, so it's a regression bug. Daniel, although I can reproduce this question on libvirt-0.10.2-8 and it's okay on libvirt RHEL6.3 release version(libvirt-0.9.10-21), I still want to confirm if it's a regression bug with you, thanks. Alex Failure to revoke cgroup device ACLs on hotplug does sound like a regression; thankfully it is not a security issue (once access has been granted, failure to revoke cgroup ACLs merely means that a compromised qemu can continue to open() the device; but if qemu already has an fd to the device, it doesn't need to open() the device, so there is no escalation in what a compromised qemu can already do). I have not yet looked in the code to see what may have caused the regression, or how easy it would be to plug. (In reply to comment #5) > Failure to revoke cgroup device ACLs on hotplug does sound like a > regression; thankfully it is not a security issue (once access has been > granted, failure to revoke cgroup ACLs merely means that a compromised qemu > can continue to open() the device; but if qemu already has an fd to the > device, it doesn't need to open() the device, so there is no escalation in > what a compromised qemu can already do). I have not yet looked in the code > to see what may have caused the regression, or how easy it would be to plug. Eric, thanks for your comments. I've confirmed the regression in my testing; it looks like the hot unplug code is failing to populate the new disk->backingChain element (or better, reusing the existing disk->backingChain that was created during hot plug). I expect to have a fix in the next 24 hours. Upstream patch proposed: https://www.redhat.com/archives/libvir-list/2012-November/msg01150.html Actually, this requires two patches (both qemuDomainDetachDiskDevice and qemuDomainDetachPciDiskDevice share the same copy-and-paste sequence). Back in POST: http://post-office.corp.redhat.com/archives/rhvirt-patches/2012-December/msg00002.html # ll /dev/sda brw-rw----. 1 qemu qemu 8, 0 Dec 6 12:18 /dev/sda # virsh attach-device 8 foo.xml Device attached successfully # cat /cgroup/devices/libvirt/qemu/vr-rhel6u2-x86_64-kvm/devices.list ... b 8:0 rw # virsh detach-device 8 foo.xml Device detached successfully cat /cgroup/devices/libvirt/qemu/vr-rhel6u2-x86_64-kvm/devices.list ... So it's verified. pkgs: libvirt-0.10.2-11.el6.x86_64 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html |
Description of problem: the qcow2 disk's major:minor number still exists in guest's devices.list after hot-unplug Version-Release number of selected component (if applicable): libvirt-0.10.2-8.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. install a guest using virsh, virt-install or virt-manager 2. get host disk infomation (such as /dev/sda) # df -h 3. create a qcow2 format image and let it point at /dev/sda # qemu-img create -f qcow2 /var/lib/libvirt/images/foo.qcow2 -o backing_file=/dev/sda 4. check whether demo.qcow2 disk pointing at /dev/sda and disk format is qcow2 # qemu-img info /var/lib/libvirt/images/foo.qcow2 5. editor the following xml block to foo.xml # cat foo.xml <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/foo.qcow2'/> <target dev='vdb' bus='virtio'/> </disk> 6. get the above disk /dev/sda major:minor number #ls -la /dev/sda 7. check whether the above major:minor(8:0) number exists in devices.list # grep "8:0" /cgroup/devices/libvirt/qemu/demo/devices.list 8. attach the above foo.xml to the guest # virsh attach-device demo foo.xml 9. check whether the above major:minor(8:0) number exists in devices.list # grep "8:0" /cgroup/devices/libvirt/qemu/demo/devices.list 10. detach foo.xml from the guest # virsh detach-device demo foo.xml 11. check whether the above major:minor(8:0) number exists in devices.list # grep "8:0" /cgroup/devices/libvirt/qemu/demo/devices.list Actual results: b 8:0 rw Expected results: no results Additional info: This works on libvirt-0.9.10-21.el6.x86_64.rpm, so it's a regression bug.