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