[Libvir] RFC 'xen like scripts'

[Daniel P. Berrange]

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 :|