9:34 a.m.
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
1:54 p.m.
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
4:19 a.m.
-----Original Message-----
From: Osier Yang [mailto:jyang@redhat.com]
Sent: Friday, September 06, 2013 10:54 PM
To: McEvoy, James
Cc: libvirt-users(a)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
4:11 p.m.
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(a)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(a)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
4016
days inactive
4021
days old
3 comments
2 participants
participants (2)
-
McEvoy, James -
Osier Yang