Adding documentation about current bugs (FIXME).

Signed-off-by: Daniel Baumann <daniel.baumann@open-infrastructure.net>

1 files changed, 51 insertions, 0 deletions

diff --git a/share/doc/bugs.txt b/share/doc/bugs.txt
new file mode 100644
index 0000000..a49f9d8
--- /dev/null
+++ b/share/doc/bugs.txt
@@ -0,0 +1,51 @@
+container-tools: Bugs
+=====================
+
+
+1. veth not removed on container stop
+-------------------------------------
+
+When stopping a container, it irregularly but reproducibly happen that the
+corresponding veth device of the container is not shutdown, making it
+impossible to start the container again.
+
+This is caused by a kernel bug not cleaning up veth devices on container
+collapsing. The veth device is supposed to be go away automatically after
+some time, definitely after a reboot though.
+
+A manual workaround is to shutdown the veth device manually with:
+
+# ip link delete ${VETH_DEVICE}
+
+There is a patch for it, see for more information:
+http://lists.linuxfoundation.org/pipermail/containers/2012-October/030533.html
+
+FIXME: add nspan message about it here
+
+2. bug with machine.slices etc
+------------------------------
+
+FIXME
+
+3. veth length
+--------------
+
+systemd creates veth devices on the fly and names them vb-$NAME, where NAME is the
+container name truncated to the first 10 characters.
+
+Problem: if you have several containers named with the first 10 characters to be
+identical, systemd will not be able to create a new veth device.
+
+4. root console
+---------------
+
+# Let's attach a console to the example container.
+#
+# Note: we did not create a user in the container,
+# logging in as root over a pseudo-terminal is
+# considered insecure by pam and will fail.
+cnt console -n example.net
+# Let's disable pam_securetty.so for demonstration purpose only.
+vi /var/lib/machines/example.net/etc/pam.d/login
+# Now login as root will work.
+cnt console -n example.net