[libvirt-users] the naming convention libvirt names a block based storage volume
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 Regards, --Yih Yih-Herng Chuang IBM Center for Microsoft Technologies 3600 Carillon Point, Kirkland WA 98033 (DID) (425) 803-7285 (TIE) 977-7285 YihHerng@us.ibm.com
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 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 :|
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. Dave
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 :|
participants (3)
-
Daniel P. Berrange -
Dave Allan -
Yih-Herng Chuang