On Tue, 6 May 2008, Daniel P. Berrange wrote:
> 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.
That is why the Net-patent me-App people invented vfilers. Next to this
Dom0 != DomU so where is the security breach? No 'client/user' is able to
do anything with libvirt or 'xm' so I'm very interested in what seperation
you are talking about.
> 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.
The LUN probably is, as stable as the human readable path to it. If your
suggestion is:
/dev/disk/by-path/ip-172.16.103.200:3260-iscsi-iqn.1992-08.com.netapp:sn.118046347:vf.88fa4694-0ba6-11dd-b8a9-00a09807592f-lun-1034
Instead of some more 'simple' and human readable way, that is *garanteed*
to give the right paths at start, no matter what happens (for example
maintance)... it is your argument against mine.
> > > 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.
I don't consider iSCSI discoveries nor DNS look-ups non-starters. Nor I
find an informative lookup to a (v)filer a nonstarter. What you are
suggesting is that one is allowed to 'lookup' using its VPS-solution, but
not when starting the machine.
> > 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.
src/storage_backend_iscsi.c:293
/* Now figure out the stable path
*
* XXX this method is O(N) because it scans the pool target
* dir every time its run. Should figure out a more efficient
* way of doing this...
*/
if ((vol->target.path = virStorageBackendStablePath(conn,
pool,
devpath)) == NULL)
goto cleanup;
if (devpath != vol->target.path)
free(devpath);
devpath = NULL;
What are you trying to 'check' here?
Stefan
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list