+ +#vxml.LXCXML +LXC_init_path = os.path.join(_image_dir)
Containers don't boot from an image like Xen and KVM do. You can think of containers as a way of encapsulating a process or a group of processes. So the init_path for a container needs to be a process or a group of processes you can run inside the container.
Something to try would be to create a script and run something like exec /bin/bash in the script.
I'm not sure what to run inside the container. May I fill it optionally now?
It's fairly trivial to write a script that runs exec /bin/bash. You can then run that script within the container.
+LXC_default_file_src = '/tmp' +LXC_default_file_tar = '/tmp'
All this does is mount the /tmp dir as /tmp within the container, which is redundant. I can't think of a good reason to use the filesystem tag for a test guest. Thoughts?
+LXC_default_tty = '/tmp'
/tmp isn't a valid value for the console. For this, you'd want to specify /dev/ptmx, which creates a pseudo terminal to use for the
console.
Then I would like to define lxc guest like below, any thoughts?
<domain type='lxc'> <name>lxc</name> <os> <init>/home/dev/lxc/lxc_rcinit</init>
/home/dev/lxc is not a good path name. We can't guarantee that all of the systems will have this path. Instead, I'd recommend using /tmp as the path for your script. Also, what will the lxc_rcinit script do?
</os> <memory>65536</memory> <devices> <console tty='/dev/ptmx'/> </devices> </domain>
-- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com