iSCSI

iSCSI

[Ian Pratt]

Has anyone got any experience using the new 'open-iscsi' initiator?
(either on Xen or native) http://www.open-iscsi.org/

We've been using the cisco iscsi stack
http://linux-iscsi.sourceforge.net/ for some time, but the performance
isn't great. open-iscsi claims good performance, so it might be worth
switching over.

BTW: gnbd works great, but I wish it used checksums over and above the
ip csum / ethernet crc32. 

Cheers,
Ian

Re: iSCSI

[Mike Christie]

Ian Pratt wrote:
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
> 
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.
>


You will need to switch sooner or later since the cisco driver as you
know it is about to die.

What help is needed in this area?

> BTW: gnbd works great, but I wish it used checksums over and above the
> ip csum / ethernet crc32. 
> 
> Cheers,
> Ian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: iSCSI

[Adam Heath]

On Sun, 10 Apr 2005, Mike Christie wrote:

> Ian Pratt wrote:
> > Has anyone got any experience using the new 'open-iscsi' initiator?
> > (either on Xen or native) http://www.open-iscsi.org/
> >
> > We've been using the cisco iscsi stack
> > http://linux-iscsi.sourceforge.net/ for some time, but the performance
> > isn't great. open-iscsi claims good performance, so it might be worth
> > switching over.
> >
>
>
> You will need to switch sooner or later since the cisco driver as you
> know it is about to die.

Odd, seeing as how it's now part of 2.6.11.

(yes, I know you are listed at the author)

Re: iSCSI

[Mike Christie]

Adam Heath wrote:
> On Sun, 10 Apr 2005, Mike Christie wrote:
> 
> 
>>Ian Pratt wrote:
>>
>>>Has anyone got any experience using the new 'open-iscsi' initiator?
>>>(either on Xen or native) http://www.open-iscsi.org/
>>>
>>>We've been using the cisco iscsi stack
>>>http://linux-iscsi.sourceforge.net/ for some time, but the performance
>>>isn't great. open-iscsi claims good performance, so it might be worth
>>>switching over.
>>>
>>
>>
>>You will need to switch sooner or later since the cisco driver as you
>>know it is about to die.
> 
> 
> Odd, seeing as how it's now part of 2.6.11.
> 

The cisco driver should not be in there. What filename?
The iSCSI transport class is in 2.6.11. That is just common
code though.

open-iscsi is in some -mm versions.


> (yes, I know you are listed at the author)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: iSCSI

[Kip Macy]

I've looked at it, but had some issues building it. If the cisco
initiator is going away I'll definitely give it a spin this week.

                            -Kip

On Apr 10, 2005 12:04 PM, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> 
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
> 
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.
> 
> BTW: gnbd works great, but I wish it used checksums over and above the
> ip csum / ethernet crc32.
> 
> Cheers,
> Ian
>

Re: iSCSI

[Adam Heath]

On Sun, 10 Apr 2005, Ian Pratt wrote:

>
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
>
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.

Anyone have pointers on an uptodate iscsi target?  Most I find are old.

Re: iSCSI

[Jacob Gorm Hansen]

Adam Heath wrote:
> 
> Anyone have pointers on an uptodate iscsi target?  Most I find are old.

How about: http://iscsitarget.sourceforge.net/

It's been about six months since I used it last, but back then it worked 
really well.

Best regards,
Jacob

Re: iSCSI

[Nils Toedtmann]

Am Sonntag, den 10.04.2005, 20:04 +0100 schrieb Ian Pratt:
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/
> 
> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.

Is there a introducing comparison of the different network blockdevice
techniques like NBD/ENBD/GNBD, DRDB or iSCSI? You seem to prefer iSCSI 
- why?

Is network blockdevice sharing (that's meant with "multipath", right?)
necessary for "xm migrate"?


> BTW: gnbd works great, but I wish it used checksums over and above the
> ip csum / ethernet crc32. 

As the ethernet checksum is (afaik) over the hole frame it should be ok
as long as GNDB is done within a L2 segment, correct?

/nils.

iSCSI

[Harald Hoyer]

with the new iSCSI module I was able to do the block testcase over iSCSI
that means:

root filesystem on an encrypted LVM PV over ISCSI

I used:
"root=/dev/dracut/root rw 
iscsiroot=192.168.2.2::::iqn.2004-04.com.qnap:TS-439:iSCSI.test.8CCAFA ip=dhcp"

to create the encrypted LVM PV on a iscsi disk and boot from it.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iSCSI

[Harald Hoyer]

On 06/02/2009 01:25 PM, Harald Hoyer wrote:
> with the new iSCSI module I was able to do the block testcase over iSCSI
> that means:
>
> root filesystem on an encrypted LVM PV over ISCSI
>
> I used:
> "root=/dev/dracut/root rw
> iscsiroot=192.168.2.2::::iqn.2004-04.com.qnap:TS-439:iSCSI.test.8CCAFA
> ip=dhcp"
>
> to create the encrypted LVM PV on a iscsi disk and boot from it.
>

Oh, actually that was a LVM on an encrypted RAID-5 on a iSCSI disk..
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: iSCSI

[Ian Pratt]

> Is there a introducing comparison of the different network 
> blockdevice techniques like NBD/ENBD/GNBD, DRDB or iSCSI? You 
> seem to prefer iSCSI
> - why?

GNBD is definitely the best of the *NBD's. 

DRDB is good for network mirroring.

iSCSI is the preferred option if you have access to a hardware target,
otherwise you might use GNBD.
 
> Is network blockdevice sharing (that's meant with 
> "multipath", right?) necessary for "xm migrate"?

You don't require multipath for migration, e.g. if your rootfs is
available via GNBD or iSCSI. If you're trying to do something fancy with
network mirroring then DRDB works OK, but true in-kernel mutipath
support would probably be better.

> > BTW: gnbd works great, but I wish it used checksums over 
> and above the 
> > ip csum / ethernet crc32.
> 
> As the ethernet checksum is (afaik) over the hole frame it 
> should be ok as long as GNDB is done within a L2 segment, correct?

Depends how paranoid you are.
Having block-level CRCs makes me feel safer.

Ian

Re: iSCSI

[Mark Williamson]

> You don't require multipath for migration, e.g. if your rootfs is
> available via GNBD or iSCSI. If you're trying to do something fancy with
> network mirroring then DRDB works OK, but true in-kernel mutipath
> support would probably be better.

Didn't a patch for in kernel multipath get submitted recently?  I thought it 
was being merged fairly soon (i.e. I thought it was in Linus' tree).

> > As the ethernet checksum is (afaik) over the hole frame it
> > should be ok as long as GNDB is done within a L2 segment, correct?
>
> Depends how paranoid you are.
> Having block-level CRCs makes me feel safer.

It's not paranoia if they are out to get you ;-)

Cheers,
Mark

RE: iSCSI

[James Harper]

> 
> Anyone have pointers on an uptodate iscsi target?  Most I find are
old.
> 

I'm using the 'Enterprise Target'
(http://sourceforge.net/projects/iscsitarget) which is the only one I've
found that makes claims to greatness. The only other one I'm aware of is
the unh target but according to the docs that target was only created to
test the unh initiator against.

I've had no problems with it in terms of reliability, but haven't really
measured performance. I'm only using gigabit ethernet though.

James

RE: iSCSI

[Adam Heath]

On Mon, 11 Apr 2005, James Harper wrote:

> I'm using the 'Enterprise Target'
> (http://sourceforge.net/projects/iscsitarget) which is the only one I've
> found that makes claims to greatness. The only other one I'm aware of is
> the unh target but according to the docs that target was only created to
> test the unh initiator against.

Hmm, yeah, that seems easy to get going.  I'll make a debian package.

RE: iSCSI

[James Harper]

> 
> Has anyone got any experience using the new 'open-iscsi' initiator?
> (either on Xen or native) http://www.open-iscsi.org/

I'd never even heard of it, and I've looked hard for iscsi initiators...
my search skills obviously aren't what they used to be!!!

> We've been using the cisco iscsi stack
> http://linux-iscsi.sourceforge.net/ for some time, but the performance
> isn't great. open-iscsi claims good performance, so it might be worth
> switching over.

I'm using the cisco stack too, remote boot is a PITA but otherwise it
runs well, and I can even do a reboot of the target (iet) and
linux-iscsi picks up the pieces quite nicely.

The unh initiator remote boots very nicely but I couldn't make it play
with iet, and it didn't cope with the target going down and coming back
up again.

I'll download and build the open-iscsi initiator now!

James

[ANNOUNCE] multipath-tools-0.4.0

[christophe varoqui]

Hello,

here goes multipath-tools-0.4.0

This is bugfix release.
An important checker file descriptor leak fix, and checker context
allocation size fix. 
Don't print unchanged maps anymore and display adaptative human friendly
map size units.


Full ChangeLog for the release :

        * [checkers] forgot to return back to caller the newly
          allocated context. Lead to fd leak notably.
        * [checkers] heavy check logic fix
        * [checkers] really malloc the checker context size,
          not the pointer size (stupidy may kill)
        * [multipathd] check more sysfs calls return values
        * [multipathd] search for sysfs mount point only once,
          not on each updatepaths() iteration
        * [multipathd] plug (char *) leak in the daemon
        * [multipath] change pgcmp logic : we want to reload a
          map only if a path is in computed map but not in cur
          map (ie accept to load a map if it brings more paths)
        * [multipath] undust coalesce_paths()
        * [multipath] don't print unchanged multipath
        * [multipath] store the action to take in the multipath
          struct
        * [multipath] print mp size with kB, MB, GB or TB units
        * [multipath] compilation fix for merge_words() (Andy)
        * [multipath] don't feed the kernel DM maps with paths of
          different sizes : DM fails and we end up with an empty
          map ... not fun
        * [multipath] cover a new corner case : path listed in
          status string but disappeared from sysfs
        * [multipath] remove the "-D" command line flag : now
          we can pass major:minor directly as last argument, like
          device names or device map names. Update multipathd
          accordingly.
        * [multipath] try reinstate again paths after a switchpg
        * [multipath] reinstate condition change :

As usual, doc and download at :
http://christophe.varoqui.free.fr/

regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

ISCSI

[Guy]

I have a SCSI tape drive on my Linux system.  I want to use the tape drive
from another system with another (evil) OS.  I have found more than 1 source
forge project related to ISCSI.  These projects seem to only talk about disk
access (SAN), not tape access.  I can't determine which I should use, if
any.

Does anyone know which is best?
I have kernel 2.4.28, but would be willing to attempt an upgrade if needed.

Thanks,
Guy

Re: ISCSI

[Ming Zhang]

i suggest u to use UNH iSCSI + SCST. it provides a bypass mode which fit
you needs. IET will support a bypass interface later.

Ming

On Sun, 2004-12-12 at 13:08, Guy wrote:
> I have a SCSI tape drive on my Linux system.  I want to use the tape drive
> from another system with another (evil) OS.  I have found more than 1 source
> forge project related to ISCSI.  These projects seem to only talk about disk
> access (SAN), not tape access.  I can't determine which I should use, if
> any.
> 
> Does anyone know which is best?
> I have kernel 2.4.28, but would be willing to attempt an upgrade if needed.
> 
> Thanks,
> Guy
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ISCSI

[Guy]

As suggested, I am attempting to install UNH iSCSI, but having some
problems.

Readme says:
- The appropriate way to install this package is :
   1. mkdir <name> ; tar -zxf <tarball>
   2. cd <name>/unh_iscsi/src/
   3. ./Configure
   4. make rpm
   5. rpm -ivh  /usr/src/redhat/RPMS/i386/unh_iscsi-1.5-0X.i386.rpm

When I do "make rpm" I get this error:
tar cf /usr/src/redhat/SOURCES/unh_iscsi.tar  .
tar: /usr/src/redhat/SOURCES/unh_iscsi.tar: Cannot open: No such file or
directory
tar: Error is not recoverable: exiting now
make: *** [rpm] Error 2

Are there some prerequisites that are needed?
Or am I just doing something wrong.

Also, could you give me a link to SCST?  Or is this included in UNH iSCSI?

Thanks,
Guy


-----Original Message-----
From: Ming Zhang [mailto:mingz@ele.uri.edu] 
Sent: Sunday, December 12, 2004 1:55 PM
To: Guy
Cc: linux-scsi
Subject: Re: ISCSI

i suggest u to use UNH iSCSI + SCST. it provides a bypass mode which fit
you needs. IET will support a bypass interface later.

Ming

On Sun, 2004-12-12 at 13:08, Guy wrote:
> I have a SCSI tape drive on my Linux system.  I want to use the tape drive
> from another system with another (evil) OS.  I have found more than 1
source
> forge project related to ISCSI.  These projects seem to only talk about
disk
> access (SAN), not tape access.  I can't determine which I should use, if
> any.
> 
> Does anyone know which is best?
> I have kernel 2.4.28, but would be willing to attempt an upgrade if
needed.
> 
> Thanks,
> Guy
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: ISCSI

[Ming Zhang]

for scst, go http://scst.sourceforge.net/

for questions about unh iscsi, pls go and ask at
http://sourceforge.net/forum/forum.php?forum_id=265256

ming

On Sun, 2004-12-12 at 16:07, Guy wrote:
> As suggested, I am attempting to install UNH iSCSI, but having some
> problems.
> 
> Readme says:
> - The appropriate way to install this package is :
>    1. mkdir <name> ; tar -zxf <tarball>
>    2. cd <name>/unh_iscsi/src/
>    3. ./Configure
>    4. make rpm
>    5. rpm -ivh  /usr/src/redhat/RPMS/i386/unh_iscsi-1.5-0X.i386.rpm
> 
> When I do "make rpm" I get this error:
> tar cf /usr/src/redhat/SOURCES/unh_iscsi.tar  .
> tar: /usr/src/redhat/SOURCES/unh_iscsi.tar: Cannot open: No such file or
> directory
> tar: Error is not recoverable: exiting now
> make: *** [rpm] Error 2
> 
> Are there some prerequisites that are needed?
> Or am I just doing something wrong.
> 
> Also, could you give me a link to SCST?  Or is this included in UNH iSCSI?
> 
> Thanks,
> Guy
> 
> 
> -----Original Message-----
> From: Ming Zhang [mailto:mingz@ele.uri.edu] 
> Sent: Sunday, December 12, 2004 1:55 PM
> To: Guy
> Cc: linux-scsi
> Subject: Re: ISCSI
> 
> i suggest u to use UNH iSCSI + SCST. it provides a bypass mode which fit
> you needs. IET will support a bypass interface later.
> 
> Ming
> 
> On Sun, 2004-12-12 at 13:08, Guy wrote:
> > I have a SCSI tape drive on my Linux system.  I want to use the tape drive
> > from another system with another (evil) OS.  I have found more than 1
> source
> > forge project related to ISCSI.  These projects seem to only talk about
> disk
> > access (SAN), not tape access.  I can't determine which I should use, if
> > any.
> > 
> > Does anyone know which is best?
> > I have kernel 2.4.28, but would be willing to attempt an upgrade if
> needed.
> > 
> > Thanks,
> > Guy
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iscsi

[Jan van Rensburg]

Hi Ian,

What kind of timeframes are we talking, more or less, to get the ring-1 
I/O model stable? In what branch of Xen does this development happen, 
1.3?

Thanks,
Jan

On 22 Jan 2004, at 6:04 AM, xen-devel-request@lists.sourceforge.net 
wrote:

> Fortunately, this kind of thing is going to be quite a bit easier
> under the ring-1 I/O model. I think the performance will be
> pretty good -- we'll never copy data, and attempt to minimize the
> number of protection domain switches through pipelining.



-------------------------------------------------------
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

Re: iscsi

[Ian Pratt]

> What kind of timeframes are we talking, more or less, to get the ring-1 
> I/O model stable? In what branch of Xen does this development happen, 
> 1.3?

The work is just starting, and will occur in the 1.3 unstable
branch. I don't think it will take too long (4-8 weeks) to get
equivalent functionality to 1.2, but bells and whistles will take
longer...

Ian 




-------------------------------------------------------
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

Re: iscsi

[Rolf Neugebauer]

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

Re: iscsi

[Kip Macy]

>
> 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.

Correct.

>
> 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?
>

For the first pass where I'm only running Linux that will, at least in
principle, work. There are a couple of issues that make that approach
more work. From a configuration standpoint I want the virtual machines
that act as sandboxes for developers to look like a normal machine.
This entails the iSCSI backing looking like a normal disk for all
intents and purposes. Second, I want to be able to map a developer to a
LUN and then build a domain backed by that on an arbitrary physical
machine. This would have the additional benefit of fully anonymizing the
hardware.

In the near future I want to be able to run other operating systems that
do not have iscsi initiator support, nor ever will, in virtual machines.
For this NFS/RAMDISK root is not an option. Thus I need to take the LUN
mapping approach. I'll just have to hope that I can pull the Adaptec
iSCSI HW initator driver into Xen, and that all the configuration tools
will work.


			-Kip


-------------------------------------------------------
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

Re: iscsi

[Ian Pratt]

> In the near future I want to be able to run other operating systems that
> do not have iscsi initiator support, nor ever will, in virtual machines.
> For this NFS/RAMDISK root is not an option. Thus I need to take the LUN
> mapping approach. I'll just have to hope that I can pull the Adaptec
> iSCSI HW initator driver into Xen, and that all the configuration tools
> will work.

On a more general note, Xen currently assumes that all vbds are
backed by local disk. We need a mechanism to 'plumb' a specified
vbd such that read/write requests go to another domain (where
arbitrary processing can be performed) rather than out to local
disk.

We need this for a whole bunch of different applications people
want to use Xen for (honeypots, debugging, fault injection,
hardware transparency etc.).

Fortunately, this kind of thing is going to be quite a bit easier
under the ring-1 I/O model. I think the performance will be
pretty good -- we'll never copy data, and attempt to minimize the
number of protection domain switches through pipelining.

Ian



-------------------------------------------------------
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

Re: iscsi

[Keir Fraser]

> On a more general note, Xen currently assumes that all vbds are
> backed by local disk. We need a mechanism to 'plumb' a specified
> vbd such that read/write requests go to another domain (where
> arbitrary processing can be performed) rather than out to local
> disk.
> 
> We need this for a whole bunch of different applications people
> want to use Xen for (honeypots, debugging, fault injection,
> hardware transparency etc.).
> 
> Fortunately, this kind of thing is going to be quite a bit easier
> under the ring-1 I/O model. I think the performance will be
> pretty good -- we'll never copy data, and attempt to minimize the
> number of protection domain switches through pipelining.

Exactly. VBD requests will go directly to the domain containign teh
device driver (via some shared memory comms model). That domain can
implement whatever it needs without having to bloat Xen at all (e.g.,
you could run a full-blown OS, with a TCP stack and anything else you
need). 

In future I don't think that any of the block-device or network code
(not even the VBD interface) will reside in Xen -- it can all be done
in driver domains.

 -- Keir


-------------------------------------------------------
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

RE: iscsi

[Williamson, Mark A]

If you wanted to get something up and running straight away, you might
also want to look at unfsd (runs in user space, so can re-export the
LUNs you import with iSCSI - I don't think kernel NFSd will).

To ease the pain of using NFS to manage multiple machines, you could try
ClusterNFS (an enhancement of unfsd to make it easier to manage clusters
- may be useful for you - this was mentioned by Bin Ren in an earlier
thread).  Also, the user level copy-on-write nfsd (mentioned by Ian
Pratt in another thread) might be good although I don't know who's doing
that or when it'll be ready...

Mark

> -----Original Message-----
> From: Kip Macy [mailto:kmacy@fsmware.com] 
> Sent: 20 January 2004 20:03
> To: Williamson, Mark A
> Cc: xen-devel@lists.sourceforge.net
> Subject: RE: [Xen-devel] iscsi 
> 
> 
> >
> > To re-export iSCSI drives from dom0, I think you'd 
> currently need to use
> > NFS or something similar - to re-export them appearing as 
> "just another
> > VBD" to the guest would require extra code.
> 
> And extra layers + latency etc.
> 
> 
> >
> > Is this relevant or do I have the wrong end of the stick?
> 
> What you're saying sounds exactly right. Plus we can't stick a SW
> initiator in Xen without a TCP stack. My only hope would be a HW
> initiator. How annoying. I wonder how much work it would be to
> support what I'm thinking about? Managing NFS root for n virtual
> machines is much more annoying to manage. It would also make this
> a much harder sell internally.
> 
> 			-Kip
> 
> 
> 


-------------------------------------------------------
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

RE: iscsi

[Jacob Gorm Hansen]

On Wed, 2004-01-21 at 12:05, Williamson, Mark A wrote:
> If you wanted to get something up and running straight away, you might
> also want to look at unfsd (runs in user space, so can re-export the
> LUNs you import with iSCSI - I don't think kernel NFSd will).
> 
> To ease the pain of using NFS to manage multiple machines, you could try
> ClusterNFS (an enhancement of unfsd to make it easier to manage clusters
> - may be useful for you - this was mentioned by Bin Ren in an earlier
> thread).  Also, the user level copy-on-write nfsd (mentioned by Ian
> Pratt in another thread) might be good although I don't know who's doing
> that or when it'll be ready...

The debian 'diskless' packages used to be good for this task too, but I
do not know if they are still being kept alive.

Jacob



-------------------------------------------------------
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