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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Tue, 6 May 2008, Stefan de Konink wrote: 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 Lets elaborate a bit further on this. If this would be implemented using libvirt as 'normal' path. No iSCSI fuss, since the host should be logged in anyway. How would I 'force' a rescan using libvirt as only mean of communication with my dom0? Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Tue, May 06, 2008 at 02:52:40PM +0200, Stefan de Konink wrote: On Tue, 6 May 2008, Stefan de Konink wrote: 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 Lets elaborate a bit further on this. If this would be implemented using libvirt as 'normal' path. No iSCSI fuss, since the host should be logged in anyway. How would I 'force' a rescan using libvirt as only mean of communication with my dom0? By invoking the virStoragePoolRefresh method 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Tue, May 06, 2008 at 03:37:04PM +0200, Stefan de Konink wrote: On Tue, 6 May 2008, Daniel P. Berrange wrote: /* 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)? The 'devpath' parameter to virStorageBackendStablePath() is the path of the LUN in question, typically eg, /dev/sdg. The 'pool' object has an internal attribute which is the 'target' element from the pool XML, eg '/dev/disk/by-path'. The virStorageBackendStablePath(), then iterates over all the entries in '/dev/disk/by-path' to find the one matching (symlinking to) '/dev/sdg' and returns it, eg /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 but if it doesn't find a matching symlink then it just returns the original string '/dev/sdg'. The latter scenario is depressingly common because soo many distros (including RHEL-5) have broken udev rules for iSCSI. Its only since Fedora 8 that they work properly for me 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] RFC 'xen like scripts'
Currently in Xen it is very easy to prototype a certain function related to binding host hardware to virtual hardware. The script gets an argument, can do anything it wants and returns another argument, or better: writes it to the xen-store. I was reviewing the current iSCSI code, because I cannot switch to libvirt with the current implementation. (From OpenSolaris, I migrated to NetApp.) So I pose a simple request: would anyone be able to create a xen-like storage backend that in principle passes the URI to a script (that runs as a fork) this script sets for example an envirionment variable or text output, the code uses this envirionment variable as path to the storage area. And a great prototypable system has been created. It could be a question by some: 'why doesn't he write a simple implementation in C?' basically: I'll will do this, no worries about that one, but I would like to be able to prototype my programs first. Is there anyone who wants to spend a few hours on this simple request, or could someone tell me what he/she doesn't like about setting the environment? Other solutions are ofcourse possible. Waiting for your comments, Stefan de Konink -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Mon, May 05, 2008 at 10:15:19PM +0200, Stefan de Konink wrote: Currently in Xen it is very easy to prototype a certain function related to binding host hardware to virtual hardware. The script gets an argument, can do anything it wants and returns another argument, or better: writes it to the xen-store. I was reviewing the current iSCSI code, because I cannot switch to libvirt with the current implementation. (From OpenSolaris, I migrated to NetApp.) So I pose a simple request: would anyone be able to create a xen-like storage backend that in principle passes the URI to a script (that runs as a fork) this script sets for example an envirionment variable or text output, the code uses this envirionment variable as path to the storage area. And a great prototypable system has been created. This kind of plugin functionality is delibrately not exposed in libvirt. The XML configuration for a guest is intended to provide a description of a guest with guarenteed semantics which is portable to any machine using libvirt. If we were to enable arbitrary admin provided scripts on the backend the semantics could not longer be guarenteed. It could be a question by some: 'why doesn't he write a simple implementation in C?' basically: I'll will do this, no worries about that one, but I would like to be able to prototype my programs first. While I understand your desire to be able to prototype things quickly I don't want to expose a generic scriptable plugin in the libvirt backend BTW, if you want any hints / advise / help with making the iSCSI stuff work on OpenSolaris let me know. I'm assuming the iSCSI admin tools on Linux are rather differnent in calling conventions, but the general principles of the Linux impl should still apply. 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Mon, 5 May 2008, Daniel P. Berrange wrote: So I pose a simple request: would anyone be able to create a xen-like storage backend that in principle passes the URI to a script (that runs as a fork) this script sets for example an envirionment variable or text output, the code uses this envirionment variable as path to the storage area. And a great prototypable system has been created. This kind of plugin functionality is delibrately not exposed in libvirt. The XML configuration for a guest is intended to provide a description of a guest with guarenteed semantics which is portable to any machine using libvirt. If we were to enable arbitrary admin provided scripts on the backend the semantics could not longer be guarenteed. I agree on your argument, but this limitation in flexibility is a real show stopper. If only it was a 'dev backend' it would be a great help. Like we discussed before; our both intentions are to kill xend, but prototyping in libvirt is currently SM. It could be a question by some: 'why doesn't he write a simple implementation in C?' basically: I'll will do this, no worries about that one, but I would like to be able to prototype my programs first. While I understand your desire to be able to prototype things quickly I don't want to expose a generic scriptable plugin in the libvirt backend BTW, if you want any hints / advise / help with making the iSCSI stuff work on OpenSolaris let me know. I'm assuming the iSCSI admin tools on Linux are rather differnent in calling conventions, but the general principles of the Linux impl should still apply. I'm not running it *on* Open Solaris (although I would like to do this), I'm currently creating the tools to be able to talk to an arbritary 'storage backend' to 'create/clone/snapshot/destroy' and in our case: 'create/remove users'. Since this works for NetApp and ZFS now purely remote based it is rather dynamic. To implement the iSCSI connection to NetApp I would prefer to pass: netapp://username/partition I would prefer to let libvirt figure out where the lun can be found on the system. (This involves connecting to the fileserver, fetching the LUN, looking up the connection on the Linux side, reading the symlink). The other way around would be to 'postprocess' my configurations before I push them inside libvirt. But then I get another problem, migration. In my humble opinion a scriptable way doesn't need to be something bad. Like with Xen the URI can be parsed or not. Would a patch be accepted? For the iscsi backend, like we have discussed before, just discovery needs to be implemented. The problem with the NetApp implementation is that it exports all 'luns' at the same time. Technically this can be done 'host based', but still *far* from implementable in libvirt using the current configuration. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Mon, May 05, 2008 at 10:50:25PM +0200, Stefan de Konink wrote: On Mon, 5 May 2008, Daniel P. Berrange wrote: It could be a question by some: 'why doesn't he write a simple implementation in C?' basically: I'll will do this, no worries about that one, but I would like to be able to prototype my programs first. While I understand your desire to be able to prototype things quickly I don't want to expose a generic scriptable plugin in the libvirt backend BTW, if you want any hints / advise / help with making the iSCSI stuff work on OpenSolaris let me know. I'm assuming the iSCSI admin tools on Linux are rather differnent in calling conventions, but the general principles of the Linux impl should still apply. I'm not running it *on* Open Solaris (although I would like to do this), I'm currently creating the tools to be able to talk to an arbritary 'storage backend' to 'create/clone/snapshot/destroy' and in our case: 'create/remove users'. Since this works for NetApp and ZFS now purely remote based it is rather dynamic. To implement the iSCSI connection to NetApp I would prefer to pass: netapp://username/partition I would prefer to let libvirt figure out where the lun can be found on the system. (This involves connecting to the fileserver, fetching the LUN, looking up the connection on the Linux side, reading the symlink). So you're wanting to pass this URL directly to the domain config, rather than the storage pool ? If so, then I'd suggest a different approach which is to extend the domain XML so it can refer to a libvirt managed storage volume explicitly Instead of doing disk type=block source dev=/dev/sdf/ /disk Refering to the storage pool and volume name (which are independant of the disk path) disk type=vol source pool=somepool vol=somelun/ /disk When starting the VM, libvirt can turn the pool + volume name into a path. The other way around would be to 'postprocess' my configurations before I push them inside libvirt. But then I get another problem, migration. Migration is one of the reasons for having a clear description of the In my humble opinion a scriptable way doesn't need to be something bad. Like with Xen the URI can be parsed or not. Would a patch be accepted? The problem with the Xen approach to storage is that there is no definition of the semantics of the URIs, other than the fact that the URI scheme maps to an arbitrary shell script. The semantics of the configuration are very important for apps to be able to interpret. The Xen scripts only setup the storage at the time the VM starts, so there is no way to validate apriori that the configuration is actually meaningful. With an iSCSI hotplug script there's not even any connection existing until the VM starts. For the iscsi backend, like we have discussed before, just discovery needs to be implemented. The problem with the NetApp implementation is that it exports all 'luns' at the same time. Technically this can be done 'host based', but still *far* from implementable in libvirt using the current configuration. I'm struggling to understand where there's needs to be a netapp specific impl of the iSCSI backend. Either netapp complies with iSCSI spec or it doesn't. The iSCSI backend is inteded to work with any compliant server. Or are you trying to use to netapp specific functionality that isn't actually part of its iSCSI support ? 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Mon, 5 May 2008, Daniel P. Berrange wrote: netapp://username/partition I would prefer to let libvirt figure out where the lun can be found on the system. (This involves connecting to the fileserver, fetching the LUN, looking up the connection on the Linux side, reading the symlink). So you're wanting to pass this URL directly to the domain config, rather than the storage pool ? If so, then I'd suggest a different approach which is to extend the domain XML so it can refer to a libvirt managed storage volume explicitly Instead of doing disk type=block source dev=/dev/sdf/ /disk Refering to the storage pool and volume name (which are independant of the disk path) disk type=vol source pool=somepool vol=somelun/ /disk When starting the VM, libvirt can turn the pool + volume name into a path. This would work indeed for NetApp. Where somelun would be the 'path' on the server, that should be resolved to a lun. For the iscsi backend, like we have discussed before, just discovery needs to be implemented. The problem with the NetApp implementation is that it exports all 'luns' at the same time. Technically this can be done 'host based', but still *far* from implementable in libvirt using the current configuration. I'm struggling to understand where there's needs to be a netapp specific impl of the iSCSI backend. Either netapp complies with iSCSI spec or it doesn't. The iSCSI backend is inteded to work with any compliant server. Or are you trying to use to netapp specific functionality that isn't actually part of its iSCSI support ? Short answer: NetApp puts *all* iSCSI luns on one connection. Add 'automatic' lunnumbering and no explicit exported comments in Vendor names etc. to the scenario and you see my ballpark. So to make it more simple: OpenSolaris NetApp All Luns exported Per hostgroup export of all assigned luns Maintains 'use' Doesn't know if a specifc lun is used Uses an identifier Uses one iSCSI identifier, needs rescanning lun can be fetched from 'configuration interface' 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 I guess the best way to see this device is as a 'already connected' scsi device, that has many disks that can be swapped around. And that it is connected to the network with an information service. For some obscure reason the 'information' service doesn't use the same IP address as the iSCSI connection. ...a lot of fun to put it all in C. Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] RFC 'xen like scripts'
On Tue, 6 May 2008, Daniel P. Berrange wrote: NetApp puts *all* iSCSI luns on one connection. Add 'automatic' lunnumbering and no explicit exported comments in Vendor names etc. to the scenario and you see my ballpark. So to make it more simple: OpenSolaris NetApp All Luns exported Per hostgroup export of all assigned luns Maintains 'use' Doesn't know if a specifc lun is used Uses an identifier Uses one iSCSI identifier, needs rescanning lun can be fetched from 'configuration interface' 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. 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. 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. 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.) Stefan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
