Walter Stanish
<walter.stan...@saffrondigital.com>
writes:
> IMHO guest generation (lxc-* scripts) is a mess and
> could benefit from adopting a standard that allows for the
> specification of options such as guest network connectivity
> in a non distribution-specific way. OVF could be one
> mechanism to achieve this.
FWIW, I *like* that lxc doesn't force its own idea of how to do
e.g. network configuration down my throat (cf. libvirt, vmware-server).
i.e. LXC sits on top of my distro, rather than my distro having to
accomodate LXC's way of doing things.
> - Externalises and thus duplicates some of the virtual-system's
> configuration information that may or may not exist, and may or may
> not be in sync with what's actually inside the virtual machine (eg:
> hostname, IP, subnet, gateway, dns servers, etc.)
Ditto.
> - Specifically, [XML] will likely make parsing configuration with
> the present bash-format lxc-* scripts an annoyance
xmlstarlet.
> (Perhaps a specific, guest-readable, host-writable file made available
> to the container could be used to provide this configuration to the
> guest at boot time? Via /proc?)
I believe this works (Debian/Ubuntu flavoured):
lxc.mount.entry = /etc/lxc/foo.interfaces
/srv/lxc/foo/etc/network/interfaces bind,ro
The RH equivalent would be file(s) within /etc/sysconfig.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
