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
