I've got a kvm host running that has and iscsi backed storage pool:

virsh # pool-info mypool
Name:           mypool
UUID:           913210f2-f8a0-4a56-b7bf-ef00b0080ee1
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       2,00 TiB
Allocation:     2,00 TiB
Available:      0,00 B

The pool has just one volume (which is a LUN) at the moment:

virsh # vol-list mypool
Name                 Path                                    
unit:0:0:1           /dev/disk/by-path/ip-

How is the name or that volume determined? Bonus question: The iscsi target uses 'tgtd'. It seems that the volume name cannot be influenced by setting the 'vendor_id' or 'product_id' of the LUN. Is there a way to have more pretty names (ideally, the LUN is create for a particular VM and that name shows up in virsh's vol-list or the virt-manager GUI)?


Looks like it's hard coded and it looks like the iscsi and scsi backends share some code.

scsi storage backend (re: device name assignment unit:x:x:x) : https://github.com/libvirt/libvirt/blob/master/src/storage/storage_backend_scsi.c#L197

storage backend (re: iSCSI uses unit:): https://github.com/libvirt/libvirt/blob/master/src/storage/storage_driver.c#L3364

I don't understand all the code so here the rest of the storage stuff: https://github.com/libvirt/libvirt/tree/master/src/storage

Have you tried mounting and accessing the iscsi targets as regular files (as a "dir" pool) from libvirt? Maybe they then won't have ambiguous names. https://libvirt.org/storage.html#StorageBackendDir

I don't use iSCSI, but I use ZFS and have it configured like this:

<pool type='dir'>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>

So the device names looks like this

root@igor:~# virsh  vol-list pool2
 Name                 Path                                    
 echo_root            /dev/zvol/pool2/echo_root               
 echo_root-part1      /dev/zvol/pool2/echo_root-part1         
 echo_root-part2      /dev/zvol/pool2/echo_root-part2         
 echo_root-part5      /dev/zvol/pool2/echo_root-part5         
 landscape_root       /dev/zvol/pool2/landscape_root          
 landscape_root-part1 /dev/zvol/pool2/landscape_root-part1    
 landscape_root-part2 /dev/zvol/pool2/landscape_root-part2    
 landscape_root-part5 /dev/zvol/pool2/landscape_root-part5    
 mail_root            /dev/zvol/pool2/mail_root               
 mail_root-part1      /dev/zvol/pool2/mail_root-part1         
 mail_root-part2      /dev/zvol/pool2/mail_root-part2         
 mail_root-part5      /dev/zvol/pool2/mail_root-part5         
 spectre_root         /dev/zvol/pool2/spectre_root            
 spectre_root-part1   /dev/zvol/pool2/spectre_root-part1      
 spectre_root-part2   /dev/zvol/pool2/spectre_root-part2      
 swap                 /dev/zvol/pool2/swap                    
 test                 /dev/zvol/pool2/test                    
 www1_root            /dev/zvol/pool2/www1_root               
 www1_root-part1      /dev/zvol/pool2/www1_root-part1         
 www1_root-part2      /dev/zvol/pool2/www1_root-part2         
 www1_root-part5      /dev/zvol/pool2/www1_root-part5         
  • I'm not exactly sure what you mean by 'accessing the iscsi target as regular files'. Would you suggest mounting an iscsi target, configuring a directory pool to point to that mount point and then putting raw files as volumes inside that target? Or am I missing something obvious? – Clayton Louden Aug 20 '16 at 13:02
  • @ClaytonLouden Umm.. in my words: Connect to any configured iscsi targets, create a dir pool pointing to /dev/disk/by-path/ and they'll show up like files along with any other disks. It's the same way I manage my ZFS pool. I point to /dev/zvol/pool2, under than are all of my zvols. I'm guessing it would be similar with iscsi, and couldn't hurt to try. Can't promise you'll get what you want out of it. – Ryan Babchishin Aug 20 '16 at 13:08
  • That's a neat idea! Unfortunately the name that shows up is just the device name, in my case 'ip-', which basically has the same information content as the path. But thank a lot for sharing this idea and also for the links! – Clayton Louden Aug 20 '16 at 13:14
  • @ClaytonLouden You're welcome. That's the best I can do. Except... what if you symlink the device files to friendly names? Ah.... – Ryan Babchishin Aug 20 '16 at 13:16
  • Had the same idea, but that might just add more complexity than it needs to. In the end virt-manager or virsh will show if a LUN is used by a particular VM and won't allow another initiator to use it simultaneously. Should be fine. If it get's too messy I can always add human readable symlinks later on. (Especially since there are multiple KVM hosts, so one would have to keep the symlinks in sync on every host. Ugh!) – Clayton Louden Aug 20 '16 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.