On Fri, Nov 12, 2010 at 06:43:39PM +0000, Daniel P. Berrange wrote: > 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
Oops, how did that happen, somehow I got pool == target in my mind for a moment. Sigh. > 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 there is really a requirement that volume names remain stable, you can't base names on bus/target/lun; it's all based on order of discovery by the kernel and can change across reboots as a result of SAN topology changes that I would be hard pressed to characterize as a hardware change. I'm not saying it's a problem, after all, the way I named volumes they changed names every time an iSCSI pool restarted, but you should be aware of the possibility. > 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. You are assuming that the admin of the host is the same as the admin of the storage which is not generally the case with SANs. In any case, we should strongly encourage applications to use key if we don't already. Dave -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
