Seems like different libvirt versions generate a storage volume name in different format. We would like to learn how libvirt names a storage volume under a block based storage pool. So that we may properly extract the LUN identifier out of the volume name for now and in the future. On host A loaded with libvirt 0.8.7 # virsh vol-list SanPool1 Name Path ----------------------------------------- unit:0:0:11 /dev/disk/by-id/wwn-0x600a0b800013071a000035ec4e32b832

On host B loaded with libvirt 0.8.1 # virsh vol-list SanPool1 Name Path ----------------------------------------- 1.0.0.0 /dev/disk/by-id/wwn-0x60080e500017e1d40000d0b74d873b13

On Wed, Aug 10, 2011 at 10:20:10AM +0100, Daniel P. Berrange wrote: > On Tue, Aug 09, 2011 at 03:28:50PM -0700, Yih-Herng Chuang wrote: > > > > > > Seems like different libvirt versions generate a storage volume name in > > different format. We would like to learn how libvirt names a storage > > volume under a block based storage pool. So that we may properly extract > > the LUN identifier out of the volume name for now and in the future. > > > > On host A loaded with libvirt 0.8.7 > > # virsh vol-list SanPool1 > > Name Path > > ----------------------------------------- > > unit:0:0:11 /dev/disk/by-id/wwn-0x600a0b800013071a000035ec4e32b832 > > This is the new naming scheme which we plan to stick with long > term. The key point of the naming scheme is that the name is > stable across reboots, and across login/logout of iSCSI targets. > > > > > On host B loaded with libvirt 0.8.1 > > > > # virsh vol-list SanPool1 > > Name Path > > ----------------------------------------- > > 1.0.0.0 /dev/disk/by-id/wwn-0x60080e500017e1d40000d0b74d873b13 > > This was the old method, which was broken, because we should not > have been including the HBA number in the name (the leading '1' > here). The HBA number changes every time you login to an iSCSI > target, or everytime an NPIV HBA is created, so it resulted in > an unstable name which changed frequently Since I was the one who came up with the original naming method, I should probably chime in. Note that although the HBA number changes rapidly with iSCSI and NPIV, resulting as Dan points out in unstable volume names, the other parts of the tuple are not guaranteed to remain stable, either. Changes to SAN topology will result in volume name changes. The only identifier you can depend on is the UUID of the logical unit.