Re: iscsi

[Rolf Neugebauer <rn@acm.org>]

On Tue, 2004-01-20 at 19:34, Kip Macy wrote:
> > I've just added the SCSI menu option from arch/i386/config.in
> > (see attached), and built a xenolinux with SCSI and SCSI disk
> > support compiled in. I'm not sure how you enable iSCSI support
> > (of indeed if the standard kernel even has iSCSI support).
> 
> Great - thanks. There is no stock support of iSCSI in Linux.
> The Redhat and Suse distributions both have one. I've always used
> the one from Cisco on sourceforge. The question is what do you do
> for a target? I believe that one has been written for Linux, but
> have never used it. I've written one for FreeBSD that could be easily
> ported to Linux. If the company that I've done it for doesn't pay me
> for the last bit of work I've done, I'd probably rather open-source
> it than take the time and energy to pursue the more common alternative.

it was pointed out to me yesterday that the Intel iSCSI code for Linux
(http://sourceforge.net/projects/intel-iscsi/) has a target driver. a
quick glance through the readme suggests that the the target can be
either a ram disk or a raw disk device (in which case the target driver
runs in userland), I have never used this software so can't comment on
completeness nor performance.

> >
> > Exporting disks to domains via iSCSI would be cool. There's
> > always the alternative of the much simpler 'enbd', but iSCSI
> > sounds nicer. I wander if there's support for iSCSI root devices?
> > (if not, it's possible something could be bodged with an initrd
> > initial ramdisk).
> 
> iSCSI is the more general of the two. DataOnTap now supports exporting
> LUNs over FCP and iSCSI. One can create a LUN as "golden image" and
> clone it arbitrarily many times. Thanks to the COW nature of WAFL the
> only additional space required by the cloned LUNs is for modifications.

to clarify, you are talking about netapp solutions here not generic
iSCSI features, right? as i understand it you can configure block-level
networked access to virtual disks on a netapp filer via iSCSI, and the
filer can be configured to do COW for these virtual disks.

if this is correct why don't you not just configure each domain to talk
iSCSI to the filer directly via their virtual network interfaces instead
of exporting the virtual disks (LUNs) through VBDs from dom0 as your
initial email seem to indicate? or is the root partition problem the
issue?

Cheers
Rolf

> The only way for an iSCSI root to work out of the box is to have an
> initiator with a BIOS, none that I know of currently do. One could
> play clever tricks by initially having a ramdisk and then switching.
> 
> My intention is to have domain 0 boot from local disk, but have all of
> the non-privileged domains boot off of iscsi backed VBDs.
> 
> 			-Kip
> 
> 
> >
> >
> > xenolinux-2.4.24-sparse/arch/xeno/config.in: 1.12 1.13 iap10 04/01/20
> 18:24:17 (modified, needs delta)
> >
> > @@ -108,6 +108,17 @@
> >
> >  endmenu
> >
> > +mainmenu_option next_comment
> > +comment 'SCSI support'
> > +
> > +tristate 'SCSI support' CONFIG_SCSI
> > +
> > +if [ "$CONFIG_SCSI" != "n" ]; then
> > +   source drivers/scsi/Config.in
> > +fi
> > +endmenu
> > +
> > +
> >  if [ "$CONFIG_NET" = "y" ]; then
> >     source net/Config.in
> >  fi
> >
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn