On Fri, Nov 12, 2010 at 12:37:41PM -0500, Dave Allan wrote:
On Fri, Nov 12, 2010 at 04:22:43PM +0000, Daniel P. Berrange wrote:
> The SCSI volumes currently get a name like '17:0:0:1' based
> on $host:$bus:$target:$lun. The names are intended to be unique
> per pool and stable across pool restarts. The inclusion of the
> $host component breaks this, because the $host number for iSCSI
> pools is dynamically allocated by the kernel at time of login.
> This changes the name to be 'unit:0:0:1', ie removes the leading
> host component. THe 'unit:' prefix is just to ensure the volume
> name doesn't start with a number and make it clearer when seen
> out of context.
None of the host/bus/target/LUN values are really stable, although for
our purposes LUN is likely to be. Have you considered LUN$lun for the
volume names?
The LUN$lun value isn't unique within the SCSI host, because
the host can have multiple bus+target each with the same LUN
value
NB, "stable" depends on the context. For storage pools the
requirement is that for a given hardware configuration, the
name is stable every time the storage pool is started. This
patch guarantees that, eg if you repeat this sequence of 6
commands twice in a row you should get the same results:
virsh pool-start foo
virsh vol-list foo
virsh pool-destroy foo
Previously you would not, for iSCSI or NPIV HBAs, now you
will.
If the admin actually plugs/unplugs physical units on the
SCSI host, then obviously bus/target/lun values can all
change, whcih is fine. If you're concerned about that
problem in an app, then you should be using 'key' instead
of 'name', which is permanently stable for the lifetime
of the unit.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|