| Summary: | drive_del cause "fdisk -l" fail inside RHEL7 guest | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jun Li <juli> |
| Component: | qemu-kvm | Assignee: | Markus Armbruster <armbru> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | acathrow, armbru, hhuang, juli, juzhang, michen, sluo, virt-maint, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-13 14:29:45 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: | |
|
Description
Jun Li
2013-09-04 05:56:46 UTC
Whether "fdisk -l" fail in RHEL7 guest is a new issue? "drive_del" cause "Input/output error". This error cause "fdisk -l" fail inside RHEL7. I am not sure if it is a new issue. Do I need to file a new bug to track it for RHEL7 guest. drive_del rips out the block backend forcibly. To the guest, this should look like hardware failure. Background info: drive_del is useful when you want to revoke the guest's access to an image, and a hot unplug is impossible (disk device doesn't support it) or doesn't work (e.g. because the guest doesn't cooperate). The observed result (fdisk gets an I/O error and fails) is exactly what I expect, which suggests NOTABUG. See also RHEL-6 bug 970159 and upstream commit 5810174. Your "Additional Info" for RHEL-6 reports different behavior. We changed error handling after drive_del recently (bug 970159, fixed in qemu-kvm-0.12.1.2-2.387.el6 by backporting said commit 5810174). Please make sure to test with the current version, and report back. (In reply to Markus Armbruster from comment #3) > drive_del rips out the block backend forcibly. To the guest, this > should look like hardware failure. > > Background info: drive_del is useful when you want to revoke the > guest's access to an image, and a hot unplug is impossible (disk > device doesn't support it) or doesn't work (e.g. because the guest > doesn't cooperate). > > The observed result (fdisk gets an I/O error and fails) is exactly > what I expect, which suggests NOTABUG. See also RHEL-6 bug 970159 and > upstream commit 5810174. > I have read that bug. But I did not delete device(device_del), I only delete drive(drive_del). After delete drive(drive_del), can not run "fdisk -l" command correctly inside RHEL7 guest. At the same time, if use RHEL6 guest, "fdisk -l" can run correctly. > Your "Additional Info" for RHEL-6 reports different behavior. We > changed error handling after drive_del recently (bug 970159, fixed in > qemu-kvm-0.12.1.2-2.387.el6 by backporting said commit 5810174). > Please make sure to test with the current version, and report back. I test RHEL 6.4 guest and RHEL7 guest inside RHEL6.5 host. qemu-kvm and host kernel version: qemu-kvm-0.12.1.2-2.399.el6.x86_64 2.6.32-416.el6.x86_64 For RHEL6.4 guest, after delete drive(drive_del), "fdisk -l" could run as normal inside guest. For RHEL7 guest, after delete drive(drive_del), "fdisk -l" can not run correctly inside guest. The guest cannot do *anything* with the block device after its backend was ripped off with drive_del. The device is *wrecked*. The guest will notice the device failed when it next tries to read or write. That may not happen on the very first guest operation on the device. A guest operation may execute fully within the guest OS's cache. Only when the OS has to read/write the actual device will it realize that you wrecked it. "fdisk -l" merely lists the partition table. If the partition table information is already cached, and the fdisk program makes no attempt to bypass the cache, then it can succeed even after you broke the device. To sum up: * The reported expected behavior is wrong. * The reported actual behavior with a RHEL-7 is expected. * The reported actual behavior with a RHEL-6 guest is inconclusive. I'm therefore closing this NOTABUG. If you have questions, don't hesitate to ask. (In reply to Markus Armbruster from comment #5) > The guest cannot do *anything* with the block device after its backend > was ripped off with drive_del. The device is *wrecked*. > > The guest will notice the device failed when it next tries to read or > write. That may not happen on the very first guest operation on the > device. A guest operation may execute fully within the guest OS's > cache. Only when the OS has to read/write the actual device will it > realize that you wrecked it. > > "fdisk -l" merely lists the partition table. If the partition table > information is already cached, and the fdisk program makes no attempt > to bypass the cache, then it can succeed even after you broke the > device. As "fdisk -l" merely lists the partition table, every disk has its own partition table. When hot-unplug the second disk drive, the second disk partition table can not read, but the first disk(system disk) partition table is well. So in my opinion，"fdisk -l" can list the first disk(system disk) partition table correctly. BTW, Whether if one disk partition table has some problems, it will affect the whole system disk partition table. When you have time, could you give me some explanation? Thank you very much. Best Regards, Jun Li > > To sum up: > > * The reported expected behavior is wrong. > > * The reported actual behavior with a RHEL-7 is expected. > > * The reported actual behavior with a RHEL-6 guest is inconclusive. > > I'm therefore closing this NOTABUG. > > If you have questions, don't hesitate to ask. You are right. I missed one crucial fact: you reported the guest reports I/O error on /dev/vda after destruction of /dev/vdb by drive_del. However, I can't reproduce this. "fdisk -l /dev/vda" works, "fdisk -l /dev/vdb" triggers kernel errors on vdb, and "fdisk -l" does both. Works as expected. Same behavior with a Fedora 20 guest. I'm leaving the bug CLOSED/NOTABUG on the hypothesis that you misread the error messages in your initial testing. If you can reproduce I/O errors being reported for vda, please reopen the bug. |