3:15 p.m.
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
3:24 p.m.
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 :|
3:50 p.m.
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
4:16 p.m.
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 :|
4:39 p.m.
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
10:32 p.m.
On Mon, May 05, 2008 at 11:39:44PM +0200, Stefan de Konink wrote:
On Mon, 5 May 2008, Daniel P. Berrange wrote:
> > 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 where does the information mapping netapp pathnames to the the LUNs
come from ? 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.
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 ?
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 :|
12:53 a.m.
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
7:03 a.m.
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 :|
7:44 a.m.
On Tue, 6 May 2008, Daniel P. Berrange wrote:
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.
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.
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.
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.
> > 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.
I don't consider iSCSI discoveries nor DNS look-ups non-starters. Nor I
find an informative lookup to a (v)filer a nonstarter. What you are
suggesting is that one is allowed to 'lookup' using its VPS-solution, but
not when starting the machine.
> 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.
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?
Stefan
7:52 a.m.
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
8:22 a.m.
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 :|
8:29 a.m.
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 :|
8:37 a.m.
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
8:43 a.m.
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 :|
6079
days inactive
6080
days old
13 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Stefan de Konink