[Libvir] RFC 'xen like scripts'

[Stefan de Konink]

On Tue, 6 May 2008, Daniel P. Berrange wrote:

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

Lets say, NetApp 'claims' it can do it with keys. But since noone is able
to add my key for a vfiler I have now implemented as a python script using
pexcept to be able to login using ssh.

Trust me, if I was happy with the solution I would be alot more positive
about the complete implementation.


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

I'll give it a shot then :)

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

But is this input path the target path that is in the examples online (as
last xmlnode)?


Stefan