Re: [Iscsitarget-devel] Online target database?

[Ross S. W. W. <RW...@me...>]

Jeff Waller wrote:

> On Jun 27, 2008, at 12:34 PM, Ross S. W. Walker wrote:
> 
> >
> > Instead of making the software more complex why not figure out
> > a simple change that can be made to the existing system that
> > would provide the functionality you desire?
> 
> Requirements eh? Yep, one again I got the cart before the horse.
> Here's what I would like to see from a  user's perspective in the  
> future.
> 
> 1) An API which would allow me to update ietd not having to
> use ietadm, or having root privs necessarily -- probably from the
> initiator.  Although I have to say that one of the the very first
> things I'd use it for is to couple LVM admin which would require
> root privs and not on the initiator.  Maybe a means of displaying
> status information (blocks in/out maybe) certainly exported luns
> in a nice user desktop kind of way (some 3rd party deal using
> the API).
> 
> 2) Some online way to cause ietd to recognize LVM device
> changes (resizes).  Maybe it does already?  My first test didn't
> go so well though I hardly spent time on it.
> 
> All of these possible future changes seem to have the feel of
> being more about online updates rather than config  files
> which is kind of how I got here.

Ah, ok, well I think the idea is great, there is already 1
published API for managing SANs remotely called VDS from
Microsoft.

In fact a VDS daemon to interact with ietd, lvm, etc. would
be great for Linux as a whole. Setup it up to work with MS
RPC and have these RPC calls manage the services. You could
even make it open-ended so it doesn't rely on IET, but can
use different iSCSI target software by designing it to
make calls to ietadm and lvm to perform the actions. Then
one can substitute ietadm for whatever, or substitute lvm
for evms, etc.

Such a service could be used to have lvm take a volume
snapshot, then have IET export it as a read-only target. Or
to have a Windows operator create a logical volume and
export it without having access to the Linux box.

As for #2 you could modify ietd to respond to signals sent
to it. 1 signal to re-read ietd.conf and update the
running configuration non-destructively, and another
signal to re-read ietd.conf and do a full reset which
would cause it to drop the luns, re-add them reading
their new size, or to drop targets altogether if they
are no longer in ietd.conf.

-Ross

______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.