Re: [Libvir] RFC 'xen like scripts'
On Tue, May 06, 2008 at 02:44:49PM +0200, Stefan de Konink wrote:
On Tue, 6 May 2008, Daniel P. Berrange wrote:
> On Tue, May 06, 2008 at 07:53:29AM +0200, Stefan de Konink wrote:
>
> 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.
Well the use of vfilers isn't something you mentioned before, so it could
make it more viable. I'm still not particularly keen on the idea of SSHing
into machines from the libvirt daemon though. What authentication mechanims
does it use ? Passwords, kerberos GSSAPI, public keys ?
> > 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.
As I mentioned before there are several names available for a volume - the
path, the 'name', and the 'key'. The 'name' is the only one
intended to
ever be shown to the user in normal circumstances, and in your example above
that would simply be 'lun-1034'. The full stable path you illustrate above
is intended for use by management tools, not to be shown to the user.
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?
It is checking whether the input path (eg '/dev/sdf') is the same as the
returned path. If not, then it free's the original inpujt path since it
is now unused.
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 :|