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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list