[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel



On 18/03/15 19:05, Anil Madhavapeddy wrote:
This fits in with a couple of things I hope to make time to work on in the
next couple of months:

1. Introspection of Rump Kernel domUs for ops purposes, i.e. get some
    basic "ps", "top", "vmstat"-like information about what the domU is
    doing from the dom0.

2. Connecting up multiple Rump Kernel domUs and/or Mirage domUs. The
    general idea here is that you can have e.g. a Mirage domU running a
    HTTP+TLS frontend, communicating with a Rump Kernel domU running PHP +
    FastCGI.

    The Mirage folks are already doing something similar in their
    Jitsu work, using a protocol called Conduit which runs over vchan.

Yeah, this is currently requiring a couple of things:

- kicking the tires with Vchan and its associated machinery, which has
   taken some time.  Dave Scott has built a complementary system for
   the xentropyd which simply sets up a console ring instead of vchan.
   This has the drawback of being a single fixed page, but far simpler.

- A XenStore protocol for setting up stream connections.  This could
   indeed quite easily turn into a AF_VCHAN that could be transparently
   used by rump/Mirage/HaLVM and normal domUs for VM<->VM comms.

This is not an argument for or against; if you want to expose AF_WHATEVER to applications running on a rump kernel, you need to sell AF_WHATEVER to NetBSD, not to rumpkernel-users. Well, preferably you need to sell it to everyone implementing sockets and running on some sort of hypervisor, but of course gotta start from somewhere.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.