
On 06/16/2010 03:15 PM, Tom Georgoulias wrote:
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-is...
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.
Let me refine that. This command does it all (if you don't mind checking the path for the name. Note, I stripped the IP from my IQN). # udevinfo -q env -p $(udevinfo -q path -n /dev/sdg) ID_VENDOR=SUN ID_MODEL=Sun_Storage_7310 ID_REVISION=1.0 ID_SERIAL=3600144f0a523738a00004c18ec990004 ID_TYPE=disk ID_BUS=scsi ID_PATH=ip-X.X.X.X:3260-iscsi-iqn.1986-03.com.sun:02:2d90ab5a-ac15-623d-a5aa-aa1baa0cfa58-lun-0