[libvirt-users] the naming convention libvirt names a block based storage volume

Daniel P. Berrange berrange at redhat.com
Wed Aug 10 14:13:47 UTC 2011


On Wed, Aug 10, 2011 at 10:02:41AM -0400, Dave Allan wrote:
> 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.

More specifically

 - path: assuming use of /dev/disk/by-id paths, this should be globally
   unique and stable across OS reboots & for all hosts with the pool
   configured in the same way.

 - name: this is unique within the scope of the storage pool, and is
   stable across hosts & reboots, provided the storage topology is
   not changed.

 - key: this is globally unique across all pools and all OS no matter
   what configuration is used.

For the latter, we use a number of strategies. For LVM we use the LVM
volume UUID, while for SCSI/iSCSI we use the SCSI lun's WWN


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvirt-users mailing list