Bug 1255258
| Summary: | The virtio-blk disk with pci multifunction could not be recognized in the guest | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Gu Nini <ngu> |
| Component: | qemu-kvm-rhev | Assignee: | Virtualization Maintenance <virt-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | juzhang, qzhang, shuyu, virt-maint, xuhan, xuma, zhengtli |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-20 08:13:01 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: | |||
Close the bug since it's the multifunction limitation at present to use 'addr=0x*.0,multifunction=on' first before using the other ones in the same pci address 'addr=0x*.*'. |
Description of problem: Start a guest with a virtio-blk disk using pci multifunction, after the guest boots up, the disk could not be recognized inside the guest with cmds 'll /dev/vd*' and 'fdisk -l' Version-Release number of selected component (if applicable): Host kernel: 3.10.0-305.el7.ppc64le Guest kernel: 3.10.0-302.el7.ppc64le/3.10.0-302.el7.ppc64 Qemu-kvm-rhev: qemu-kvm-rhev-2.3.0-18.el7.ppc64le How reproducible: 100% Steps to Reproduce: 1. Start a guest with a virtio-blk disk using pci multifunction: ...... -drive id=drv71,file=/tmp/resize71.qcow2,format=qcow2,if=none,cache=none,snapshot=off,aio=native -device virtio-blk-pci,drive=drv71,id=dev71,addr=0x7.1,multifunction=on,scsi=off ...... 2. Check above disk with hmp cmd 'info block': (qemu) info block drive_image1: /media/ngu/virtioblk-0814-le (qcow2) Cache mode: writeback, direct drv71: /tmp/resize71.qcow2 (qcow2) Cache mode: writeback, direct 3. After the guest boots up, check above disk with cmds 'll -h /dev/vd*' and 'fdisk -l' inside the guest: [root@dhcp70-159 ~]# ll /dev/vd* brw-rw----. 1 root disk 252, 0 Aug 20 02:09 /dev/vda brw-rw----. 1 root disk 252, 1 Aug 20 02:09 /dev/vda1 brw-rw----. 1 root disk 252, 2 Aug 20 02:09 /dev/vda2 brw-rw----. 1 root disk 252, 3 Aug 20 02:09 /dev/vda3 [root@dhcp70-159 ~]# fdisk -l Disk /dev/vda: 21.5 GB, 21474836480 bytes, 41943040 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: dos Disk identifier: 0x0004a68f Device Boot Start End Blocks Id System /dev/vda1 * 2048 10239 4096 41 PPC PReP Boot /dev/vda2 10240 1034239 512000 83 Linux /dev/vda3 1034240 41943039 20454400 8e Linux LVM Disk /dev/mapper/rhel-root: 18.8 GB, 18752733184 bytes, 36626432 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/mapper/rhel-swap: 2147 MB, 2147483648 bytes, 4194304 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Actual results: As showed in step3, there is not the disk under the cmds output in the guest Expected results: In step3, there is the virtio-blk disk using pci multifunction inside the guest Additional info: I have done test on On x86 host, there is the same problem, the detailed sw versions are: Host kernel: 3.10.0-306.el7.x86_64 Guest kernel: 3.10.0-302.el7.x86_64 Qemu-kvm-rhev: qemu-kvm-rhev-2.3.0-18.el7.x86_64