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

Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks from Xenstore



Antti Kantee writes ("Re: RFC: Configuring rumprun-xen application stacks from 
Xenstore"):
> user-visible != internally visible.  We can for example build /etc into 
> the image as data and mount it as a memory file system at runtime or 
> symlink /etc/resolv.conf to /resolv.conf.  I'd completely avoid 
> modifying libc until there's a better understanding of the role of /etc 
> with experience from dozens of varying applications.  Modifying over 
> upstream is a balancing act, because then we stop getting the 
> *pre-tested* code for free.

I agree that having rumprun-xen create a suitable /etc image and feed
it to the guest is a very good idea.

I wonder if this mechanism could be used for some or all of the things
that you're currently using xenstore for.  Specifying which virtual
block devices to mount where, or what network configuration to use,
are things that other rump kernel runners would want to do.  Putting
that information in a stunt /etc seems like it might make more
commonality.

Another observation I had was: perhaps we can make some of this
configuration unnecessary, or at least we could provide sensible
defaults.  If the guest has been given a single network interface it
probably ought to do DHCPv4 and IPv6 autoconf on it, unless it has
been told otherwise.

Feel free to tell me I'm wrong about both of the above.

Ian.

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