2:15 p.m.
On 06/16/2010 01:41 PM, Daniel P. Berrange wrote:
On Wed, Jun 16, 2010 at 01:20:02PM -0400, Tom Georgoulias wrote:
> I've configured a libvirt storage pool using an iscsi target from a Sun
> 7310 storage appliance and am using the LUNs in this target as volumes
> for my KVM guests. The setup is very similar to what Daniel covered in
> a recent blog posting:
>
>
http://berrange.com/posts/2010/05/05/provisioning-kvm-virtual-machines-on...
>
> It works great, but I can't figure out how to match the volume names&
> path IQNs within the storage pool to the GUIDs on the target.
>
> For example, here's what I see when I use the vol-info command:
>
> # virsh vol-list kvm-target
> Name Path
> -----------------------------------------
> 6.0.0.0
> /dev/disk/by-path/ip-X.X.X.X:3260-iscsi-iqn.1986-03.com.sun:02:<snipped>-lun-0
> 6.0.0.1
> /dev/disk/by-path/ip-X.X.X.X:3260-iscsi-iqn.1986-03.com.sun:02:<snipped>-lun-1
>
> The IQN matches the targets IQN, but when I browse the LUNs from the
> storage system I do not see a way to determine which of them is *-lun-0
> and which is *-lun-1, I only see a GUID and an alias name that I created.
>
> Is there any way to get that info (or something else that will do the
> job) from a virsh command?
Nothing at this time. If you weren't using libvirt, how would you discover
the GUIDs on the Linux client ? If there is a way to get these from sysfs
or elsewhere, we can wire it up in libvirt to the<key> element in the XML
for the volume. I just don't know how yet...
That's a good question, I tried to figure out a way to do so with
iscsiadm but didn't find anything. But I'm glad you mentioned the sysfs
angle, it prodded me in the right direction and I think I found
something to work with.
# udevinfo -a -p $(udevinfo -q path -n /dev/sdg)
looking at device '/block/sdg':
KERNEL=="sdg"
SUBSYSTEM=="block"
SYSFS{stat}==" 20458 183 451623 17494 27820 11891
4508156 552205 0 70083 569695"
SYSFS{size}=="41943040"
SYSFS{removable}=="0"
SYSFS{range}=="16"
SYSFS{dev}=="8:96"
looking at parent device
'/devices/platform/host6/session2/target6:0:0/6:0:0:0':
ID=="6:0:0:0"
BUS=="scsi"
DRIVER=="sd"
SYSFS{ioerr_cnt}=="0x3"
SYSFS{iodone_cnt}=="0xbcb4"
SYSFS{iorequest_cnt}=="0xbcb4"
SYSFS{iocounterbits}=="32"
SYSFS{timeout}=="60"
SYSFS{state}=="running"
SYSFS{rev}=="1.0 "
SYSFS{model}=="Sun Storage 7310"
SYSFS{vendor}=="SUN "
SYSFS{scsi_level}=="6"
SYSFS{type}=="0"
SYSFS{queue_type}=="none"
SYSFS{queue_depth}=="32"
SYSFS{device_blocked}=="0"
looking at parent device '/devices/platform/host6/session2/target6:0:0':
ID=="target6:0:0"
BUS==""
DRIVER==""
looking at parent device '/devices/platform/host6/session2':
ID=="session2"
BUS==""
DRIVER==""
looking at parent device '/devices/platform/host6':
ID=="host6"
BUS==""
DRIVER==""
looking at parent device '/devices/platform':
ID=="platform"
BUS==""
DRIVER==""
# scsi_id -g -x -s /block/sdg
ID_VENDOR=SUN
ID_MODEL=Sun_Storage_7310
ID_REVISION=1.0
ID_SERIAL=3600144f0a523738a00004c18ec990004
ID_TYPE=disk
ID_BUS=scsi
The GUID for this LUN is "600144F0A523738A00004C18EC990004". That's the
same number that is used in the ID_SERIAL, except that it has a 3
prepended on it. So now I can tell which LUN is really volume 6.0.0.0.
Tom