[libvirt-users] Error Attaching Seventh VirtIO-SCSI Device to Guest
I have run into a problem attempting to attach the seventh virtio-scsi device to a RHEL 6.4 Guest from a RHEL 6.4 host running libvirt version 0.10.2-18. I have a guest that is running RHEL6.4 where I can attach disks sda(boot), sdb, sdc, sdd, sde and sdf but when I try to attach sdg the virsh attach-disk command fails with the error: error: Failed to attach disk error: internal error Unable to determine model for scsi controller I logged Bug 996327 on this issue including an attached script to repro the bug but there has been no activity on that bug so far. This is the results when attaching virtio-scsi disks in a loop. Sdf is attached but sdg fails. virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-5 --target sdf --cache none --type disk --config --wwn 1fc7058865439717 --serial c7d11fc7058865439717 --shareable Disk attached successfully Vol UEM004-6 created virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-6 --target sdg --cache none --type disk --config --wwn 4d3ddb9d15b05e7e --serial 62fd4d3ddb9d15b05e7e --shareable error: Failed to attach disk error: internal error Unable to determine model for scsi controller The script to create and attach LVM volumes using virtio-scsi is available here: https://bugzilla.redhat.com/attachment.cgi?id=785925 Has anyone else run into this... I had the understanding that each virtio-controller could support 4K devices. --jim
On 04/09/13 09:34, McEvoy, James wrote:
I have run into a problem attempting to attach the seventh virtio-scsi device to a RHEL 6.4 Guest from a RHEL 6.4 host running libvirt version 0.10.2-18. I have a guest that is running RHEL6.4 where I can attach disks sda(boot), sdb, sdc, sdd, sde and sdf but when I try to attach sdg the virsh attach-disk command fails with the error: error: Failed to attach disk error: internal error Unable to determine model for scsi controller
I logged Bug 996327 on this issue including an attached script to repro the bug but there has been no activity on that bug so far.
I took the bug.
This is the results when attaching virtio-scsi disks in a loop. Sdf is attached but sdg fails.
virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-5 --target sdf --cache none --type disk --config --wwn 1fc7058865439717 --serial c7d11fc7058865439717 --shareable Disk attached successfully
Vol UEM004-6 created virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-6 --target sdg --cache none --type disk --config --wwn 4d3ddb9d15b05e7e --serial 62fd4d3ddb9d15b05e7e --shareable
error: Failed to attach disk error: internal error Unable to determine model for scsi controller
It looks odd, It looks to me there is new scsi controller is generated automatically by libvirt when the 6th volume is attaching to the domain, since for narrow SCSI bus, we allow 7 unit for each SCSI controller. But it's strange that it couldn't get a default model for the new SCSI controller. Can you get the devices your qemu supports by: $ qemu-kvm -device ? And attach your domain conf? Either in the list or in the bug is fine. Osier
-----Original Message----- From: Osier Yang [mailto:jyang@redhat.com] Sent: Friday, September 06, 2013 10:54 PM To: McEvoy, James Cc: libvirt-users@redhat.com Subject: Re: [libvirt-users] Error Attaching Seventh VirtIO-SCSI Device to Guest
On 04/09/13 09:34, McEvoy, James wrote:
I have run into a problem attempting to attach the seventh virtio-scsi device to a RHEL 6.4 Guest from a RHEL 6.4 host running libvirt version 0.10.2-18. I have a guest that is running RHEL6.4 where I can attach disks sda(boot), sdb, sdc, sdd, sde and sdf but when I try to attach sdg the virsh attach-disk command fails with the error: error: Failed to attach disk error: internal error Unable to determine model for scsi controller
I logged Bug 996327 on this issue including an attached script to repro the bug but there has been no activity on that bug so far.
I took the bug.
This is the results when attaching virtio-scsi disks in a loop. Sdf is attached
but sdg fails.
virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-5 --target sdf --cache none --type disk --config --wwn 1fc7058865439717 --serial c7d11fc7058865439717 --shareable Disk attached successfully
Vol UEM004-6 created virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-6 --target sdg --cache none --type disk --config --wwn 4d3ddb9d15b05e7e --serial 62fd4d3ddb9d15b05e7e --shareable
error: Failed to attach disk error: internal error Unable to determine model for scsi controller
It looks odd, It looks to me there is new scsi controller is generated automatically by libvirt when the 6th volume is attaching to the domain, since for narrow SCSI bus, we allow 7 unit for each SCSI controller. But it's strange that it couldn't get a default model for the new SCSI controller.
Can you get the devices your qemu supports by:
$ qemu-kvm -device ?
And attach your domain conf?
Either in the list or in the bug is fine.
Osier
Hi Osier, I have attached the details you asked for to the bug 996327 and here is the short version: These are the qemu-kvm -drive and -device options for /dev/sdg on the guest: -drive file=/dev/GuestVols/UEM002-6,if=none,id=drive-scsi0-0-0-6,format=raw,serial=8aad44f9e53e05868e81,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=6,drive=drive-scsi0-0-0-6,id=scsi0-0-0-6,wwn=44f9e53e05868e81 I am seeing an error on device /dev/sdg on the guest when I query SCSI page 0x83 for that device. [root@node1 ~]# sg_inq -p 0x83 /dev/sdg VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 24 designator_type: vendor specific [0x0], code_set: ASCII associated with the addressed logical unit vendor specific: 22b0daf285d88050fd39 Designation descriptor number 2, descriptor length: 12 designator_type: NAA, code_set: Binary associated with the addressed logical unit << unexpected naa [0xd]>> 00 da f2 85 d8 80 50 fd 39 .....P.9 [root@node1 ~]# One other detail, I am defining the scsi controller using the virt-install command. --jim
On 08/09/13 04:19, McEvoy, James wrote:
-----Original Message----- From: Osier Yang [mailto:jyang@redhat.com] Sent: Friday, September 06, 2013 10:54 PM To: McEvoy, James Cc: libvirt-users@redhat.com Subject: Re: [libvirt-users] Error Attaching Seventh VirtIO-SCSI Device to Guest
On 04/09/13 09:34, McEvoy, James wrote:
I have run into a problem attempting to attach the seventh virtio-scsi device to a RHEL 6.4 Guest from a RHEL 6.4 host running libvirt version 0.10.2-18. I have a guest that is running RHEL6.4 where I can attach disks sda(boot), sdb, sdc, sdd, sde and sdf but when I try to attach sdg the virsh attach-disk command fails with the error: error: Failed to attach disk error: internal error Unable to determine model for scsi controller
I logged Bug 996327 on this issue including an attached script to repro the bug but there has been no activity on that bug so far.
I took the bug.
This is the results when attaching virtio-scsi disks in a loop. Sdf is attached but sdg fails. virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-5 --target sdf --cache none --type disk --config --wwn 1fc7058865439717 --serial c7d11fc7058865439717 --shareable Disk attached successfully
Vol UEM004-6 created virsh attach-disk --domain UEM004n1 --source /dev/GuestVols/UEM004-6 --target sdg --cache none --type disk --config --wwn 4d3ddb9d15b05e7e --serial 62fd4d3ddb9d15b05e7e --shareable
error: Failed to attach disk error: internal error Unable to determine model for scsi controller It looks odd, It looks to me there is new scsi controller is generated automatically by libvirt when the 6th volume is attaching to the domain, since for narrow SCSI bus, we allow 7 unit for each SCSI controller. But it's strange that it couldn't get a default model for the new SCSI controller.
Can you get the devices your qemu supports by:
$ qemu-kvm -device ?
And attach your domain conf?
Either in the list or in the bug is fine.
Osier Hi Osier,
I have attached the details you asked for to the bug 996327 and here is the short version:
These are the qemu-kvm -drive and -device options for /dev/sdg on the guest: -drive file=/dev/GuestVols/UEM002-6,if=none,id=drive-scsi0-0-0-6,format=raw,serial=8aad44f9e53e05868e81,cache=none -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=6,drive=drive-scsi0-0-0-6,id=scsi0-0-0-6,wwn=44f9e53e05868e81
I am seeing an error on device /dev/sdg on the guest when I query SCSI page 0x83 for that device. [root@node1 ~]# sg_inq -p 0x83 /dev/sdg VPD INQUIRY: Device Identification page Designation descriptor number 1, descriptor length: 24 designator_type: vendor specific [0x0], code_set: ASCII associated with the addressed logical unit vendor specific: 22b0daf285d88050fd39 Designation descriptor number 2, descriptor length: 12 designator_type: NAA, code_set: Binary associated with the addressed logical unit << unexpected naa [0xd]>> 00 da f2 85 d8 80 50 fd 39 .....P.9 [root@node1 ~]#
Hi, Jim I didn't notice your libvirt version is 0.10.2-18, which doesn't contain the commit below, which is included since 1.0.6. commit cdb978955991070ba14ade9d3ad460c43f836d87 Author: Osier Yang <jyang@redhat.com> Date: Fri May 31 18:09:24 2013 +0800 conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead. That says what I said (below) is not true for your libvirt version <...> It looks odd, It looks to me there is new scsi controller is generated automatically by libvirt when the 6th volume is attaching to the domain, since for narrow SCSI bus, we allow 7 unit for each SCSI controller. But it's strange that it couldn't get a default model for the new SCSI controller. </...> However, before I find out the cause for the odd error message, I'd like let you know it works nice for me even with libvirt 0.10.2. # qemu-kvm --version QEMU emulator version 1.2.2 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard ================= # fdisk -l Disk /dev/sda: 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 identifier: 0x0009fa70 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 41943039 20458496 8e Linux LVM Disk /dev/sdb: 1 MB, 1048576 bytes, 2048 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/sdc: 1 MB, 1048576 bytes, 2048 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/sdd: 1 MB, 1048576 bytes, 2048 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/sde: 1 MB, 1048576 bytes, 2048 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/sdf: 1 MB, 1048576 bytes, 2048 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/sdg: 1 MB, 1048576 bytes, 2048 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/sdh: 1 MB, 1048576 bytes, 2048 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/sdi: 1 MB, 1048576 bytes, 2048 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/sdj: 1 MB, 1048576 bytes, 2048 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/sdk: 1 MB, 1048576 bytes, 2048 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/fedora-swap: 2113 MB, 2113929216 bytes, 4128768 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/fedora-root: 18.8 GB, 18832424960 bytes, 36782080 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/sdl: 1073 MB, 1073741824 bytes, 2097152 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/sdm: 536 MB, 536870912 bytes, 1048576 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes # sg_inq /dev/sdk standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=1 Linked=0 [TranDis=0] CmdQue=1 length=36 (0x24) Peripheral device type: disk Vendor identification: QEMU Product identification: QEMU HARDDISK Product revision level: 1.2. Unit serial number: a4523e8fa43d16eb246f [root@localhost ~]# sg_inq /dev/sdg standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=1 Linked=0 [TranDis=0] CmdQue=1 length=36 (0x24) Peripheral device type: disk Vendor identification: QEMU Product identification: QEMU HARDDISK Product revision level: 1.2. Unit serial number: d58e4ddf258df1b11920 # sg_inq /dev/sdm standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=1 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=66 (0x42) Peripheral device type: disk Vendor identification: IET Product identification: VIRTUAL-DISK Product revision level: 0001 Unit serial number: beaf12 Osier
participants (2)
-
McEvoy, James -
Osier Yang