This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] iscsi

To: Kip Macy <kmacy@xxxxxxxxxxx>
Subject: Re: [Xen-devel] iscsi
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 21 Jan 2004 17:43:49 +0000
Cc: Rolf Neugebauer <rn@xxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Wed, 21 Jan 2004 17:45:01 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Wed, 21 Jan 2004 09:22:56 PST." <20040121090723.F49761@xxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> 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

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.


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.
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>