Hide Forgot
Description of problem: Unable to configure a xvd device on a 4.7 Fully Virt guest (also a 4.6 Fully Virt guest that was up2date). Host: RHEL 5.2 Version-Release number of selected component (if applicable): Guest: 2.6.9-78.0.1.ELsmp Host: 2.6.18-92.1.6.el5xen How reproducible: Consistent on the 4.7 node and the up2date 4.6 node (running same kernel) Steps to Reproduce: 1. Added device to configuration disk = [ "phy:/dev/RenoirVirtVG/ra-vm8-RHEL47fv2-vol,hda,w", "tap:aio:/var/lib/xen/images/prealloc_file,xvdb,w" ] (have attempted using file and xvda) 2. rebooted the guest 3. No device shows up! root@ra-vm8:~ > ls /dev/x* /dev/xfrm root@ra-vm8:~ > No module is loaded! root@ra-vm8:~ > lsmod | grep xen xen_vnif 28481 0 [permanent] root@ra-vm8:~ > 4. alias scsi_adapter xen-vbd in modprobe.conf and rebooted with same result, no module even loaded. Actual results: Expected results: Additional info:
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 ***