Re: [Libvir] RFC 'xen like scripts'
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 :|