Bug 461293
Summary: | Xen virtual block devices not configuring with 4.7 guest kernels on 5.2 host | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Steve Reichard <sreichar> |
Component: | xenpv-kmod | Assignee: | Xen Maintainance List <xen-maint> |
Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.7 | CC: | ddutile, xen-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-01-06 19:46:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Steve Reichard
2008-09-05 17:09:10 UTC
Try adding this in the /etc/modprobe.conf file: alias pci:v00008086d00007010sv00005853sd00000001bc*sc*i* xen-vbd and see if that makes xvd's get setup/connected to driver(s). - Don Note: a fully updated 4.6 system will become a 4.7 kernel, thus the same issue due to it being the same kernel. in 4.7, the built-in xenpvhvm drivers are being used. Added requested alias. The driver did not load. Saw the following in /var/log/messages corresponding to boot with alias. Sep 5 16:04:07 ra-vm8 kernel: XENBUS: Device with no driver: device/vif/0 Sep 5 16:04:07 ra-vm8 kernel: XENBUS: Device with no driver: device/vbd/768 Sep 5 16:04:07 ra-vm8 kernel: XENBUS: Device with no driver: device/vbd/5171 In original I tried "alias scsi_adapter xen-vbd". I should have tried alias scsi_hostadapter xen-vbd. When this is done, it is listed in a lsmod, however the device is still not configured. the messages in #4 always occur -- they are generated by xenbus_probe(), before a driver match is found for vif/vbd devices. note, how your vnif is configured, even though the XENBUS messages say no driver for vif/0. Can you try a sequence of block-attach, block-detach, to see if they work ? eg: xm block-attach ra-vm8 tap:aio://var/lib/xen/images/ra-vm8_usr.dsk /dev/xvdb r xm block-list ra-vm8 --> to get xen-generated number to pass in next line xm block-detach ra-vm8 51728 after the xm block-attach, you should be able to do the following (in the guest) and see an xvd listed: kudzu -p -c HD root@renoir:/etc/sysconfig > xm block-attach ra-vm8 tap:aio:/var/lib/xen/images/extra_file /dev/xvdb r root@renoir:/etc/sysconfig > xm block-list ra-vm8 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 1 -1 -1 /local/domain/0/backend/vbd/89/768 51728 0 0 4 10 770 /local/domain/0/backend/tap/89/51728 root@renoir:/etc/sysconfig > On guest -- root@ra-vm8:~ > kudzu -p -c HD - class: HD bus: IDE detached: 0 device: hda driver: ignore desc: "QEMU HARDDISK" physical: 16383/16/63 logical: 16383/255/63 - class: HD bus: XEN detached: 0 device: xvda driver: xenblk desc: "Xen Virtual Block Device" root@ra-vm8:~ > ls /sys/block dm-0 hda loop1 loop3 loop5 loop7 ram0 ram10 ram12 ram14 ram2 ram4 ram6 ram8 xvdb dm-1 loop0 loop2 loop4 loop6 md0 ram1 ram11 ram13 ram15 ram3 ram5 ram7 ram9 root@ra-vm8:~ > Host --- root@renoir:/etc/sysconfig > xm block-detach ra-vm8 51728 root@renoir:/etc/sysconfig > Guest ---- root@ra-vm8:~ > ls /sys/block dm-0 hda loop1 loop3 loop5 loop7 ram0 ram10 ram12 ram14 ram2 ram4 ram6 ram8 dm-1 loop0 loop2 loop4 loop6 md0 ram1 ram11 ram13 ram15 ram3 ram5 ram7 ram9 root@ra-vm8:~ > ~~~ I did a little experimenting The config file has: disk = [ "phy:/dev/RenoirVirtVG/ra-vm8-RHEL47fv2-vol,hda,w", "tap:aio:/var/lib/xen/images/prealloc_file,xvda,w" ] On a startup this device is not seen. I can get a xm block-attach device to be seen if scsi_hostadapter is in the modprobe.com. The long alias did not seem to have much effect. The raw source of this problem is that the same loadable modules didn't exist btwn a rhel4.6+kmod-xenpv system and rhel4.7. the patch posted for bz474667 resolves this issue; similar problem occurred in rhel5 & was fixed there in a separate bz. marking as duplicate. *** This bug has been marked as a duplicate of bug 474667 *** |