[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