| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
> 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.
You could still presumably just have all the domains connecting directly
to the target via iSCSI? But I assume you wanted to re-export as VBDs
to avoid using any weird ramdisk-based hacks in order to get effectively
an iSCSI-based root filesystem in each guest, thus I realise this
wouldn't be the ideal. Maybe you could NFS (or local partitions,
possibly via the new virtual disk stuff) for each root fs and use that
just for the basics, then use an iSCSI initiator in each domain to
access all the interesting stuff?
There are some plans (here at Intel Research Cambridge) to implement an
iSCSI "virtual channel processor" (see paper at
http://www.intel-research.net/Publications/Cambridge/110720030446_176.pd
f), which would run the iSCSI protocol (with its own (optimised) net
stack) in a domain on top of Xen and also appear like a normal device to
guest Oses. This work won't be ready for some time, though. However,
it sounds like it would get exactly what you want (plus various other
benefits).
Another option might be to re-export the iSCSI devices from dom0 over
Xen's internal "network" using some other network-based protocol that
could be used as a root fs. Yes, that is a very icky idea ;-)
I imagine it would be possible to write some kind of user-space "proxy"
that would access devices in dom0 in the normal user program fashion and
then have XenoLinux drivers in guest domains talk to that proxy (either
through the internal network, or by the upcoming interdomain
communications facilities) - this could also be used to access weird
things like dom0 disk files as block devices. You'd expect penalties in
performance and quality of service provision by doing this. No-one's
currently working on this and I don't know what the feeling is as to how
worthwhile it would be...
The Virtual Channel Processors are the neatest solution but will take a
while.
Other people may have suggestions, also...
Mark
-------------------------------------------------------
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home