On Tue, May 06, 2008 at 07:53:29AM +0200, Stefan de Konink wrote: > On Tue, 6 May 2008, Daniel P. Berrange wrote: > > > > Due to the reason all LUNs are exported over one connection, a > > > rescan before usage a rescan is always required. LUN numbering is not > > > stable, nor they can be found at the client side. > > > > So where does the information mapping netapp pathnames to the the LUNs > > come from ? > > The information service, so in my case ssh script. Having the daemon SSH into the filer is a non-starter. There's no way most admins will allow that as in any reasonably large company its fundamental security protocol that there is separation between server & filer admins. One group not having access to the other's systems & vica-verca. And from the other via SELinux policy for libvirt will not allow the daamon to SSH to servers as it violates the principle of containment. > > If LUNs can change when re-scanning what happens to LUNs > > already in use for other guests ? It doesn't sound usable if LUNs that > > are in use get renumbered at rescan. > > Luns that don't change get not remapped. But if a user decides to destroy > a disk, and have one with the same name again, it is most likely to get a > other lun. But with the same name. So the LUN is stable for the entire lifetime of the associated named disk volume. > > AFAICT this is basically just suggesting an alternate naming scheme for > > storage volumes, instead of 'lun-XXX' where XXX is the number, you want > > a name that's independant of LUN numbering. So the key question is where > > does the information for the persistent names come from ? > > Exactly this is what I want. If I have a iSCSI uri, I want to have it > discovered, if I have a netapp uri I want to have it 'discovered' too, but > in this case I provide the address of the administrative interface. Logging into the admin interface is a non-starter. > And unlike you do for storage pools with iSCSI that the provided target > name for volumes should 'match up' with the 'discovered name', I want this > to be transparent to the user. *Because* Linux might have a target > /dev/bla-by-path/X but who says *BSD, *Solaris has it? (Yes I know, there > are other problems, but the base problem is that the target provided target device > is pretty limited to one OS running udev.) The question of disk path naming is completely independnat of of the storage volume namin - they are separate pieces of metadata & there's no hard link between them. The /dev/ naming scheme for volumes is by neccessity going to be different across every OS. The use of /dev/disk/byXXX is obviously Linux speciifc and would need to be adapted for any BSD or Solaris disto. There are several levels of naming for storage volumes in the libvirt API - name - unique with in the scope of a storage pool - key - unique amongst all storage pools - path - unique amongst all pools in a single host The scheme for each can be addressed independantly as best suits the storage type in question. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list