[Lxc-users] libvirtd / virt-manager and LXC guests

Christian Parpart trapni at gmail.com
Thu Oct 20 18:05:59 UTC 2011


Hey,

I also ran into an issue I could not actually google for, that is, trying to
get a operating system LXC container running via virt-manager.

Following the creation-wizard, and in the end clicking on "create" results
into a popup dialog with the following contents:

Unable to complete install: 'internal error guest failed to start:
PATH=/bin:/sbin TERM=linux
LIBVIRT_LXC_UUID=590aa6d4-82d6-7b18-3fdd-0610e22d6059 LIBVIRT_LXC_NAME=ialu
/sbin/init
19:35:29.518: 1: info : libvirt version: 0.9.6
19:35:29.518: 1: error : lxcContainerUnmountOldFS:889 : Failed to unmount
'/.oldroot/sys/kernel/security': Too many levels of symbolic links
19:35:29.518: 29960: info : libvirt version: 0.9.6
19:35:29.518: 29960: error : lxcControllerRun:940 : error receiving signal
from container: Success
'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in
cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1899, in
do_install
    guest.start_install(False, meter=meter)
  File "/usr/lib64/python2.7/site-packages/virtinst/Guest.py", line 1223, in
start_install
    noboot)
  File "/usr/lib64/python2.7/site-packages/virtinst/Guest.py", line 1291, in
_create_guest
    dom = self.conn.createLinux(start_xml or final_xml, 0)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2077, in
createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed',
conn=self)
libvirtError: internal error guest failed to start: PATH=/bin:/sbin
TERM=linux LIBVIRT_LXC_UUID=590aa6d4-82d6-7b18-3fdd-0610e22d6059
LIBVIRT_LXC_NAME=ialu /sbin/init
19:35:29.518: 1: info : libvirt version: 0.9.6
19:35:29.518: 1: error : lxcContainerUnmountOldFS:889 : Failed to unmount
'/.oldroot/sys/kernel/security': Too many levels of symbolic links
19:35:29.518: 29960: info : libvirt version: 0.9.6
19:35:29.518: 29960: error : lxcControllerRun:940 : error receiving signal
from container: Success

It seems, that virt-manager is running through my host mounts and wants them
to be visible inside the guest's /.oldroot directory (just a guess).

my host mount tab looks like this (lots of dirs mounted via systemd):
rootfs on / type rootfs (rw)
/dev/root on / type btrfs (rw,noatime,ssd)
devtmpfs on /dev type devtmpfs
(rw,relatime,size=10240k,nr_inodes=1005036,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs
(rw,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,clone_children,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset,clone_children)
cgroup on /sys/fs/cgroup/cpu type cgroup
(rw,nosuid,nodev,noexec,relatime,cpu,clone_children)
cgroup on /sys/fs/cgroup/cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,clone_children)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory,clone_children)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices,clone_children)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer,clone_children)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls,clone_children)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio,clone_children)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
systemd-1 on /sys/kernel/security type autofs
(rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
systemd-1 on /sys/kernel/debug type autofs
(rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
systemd-1 on /dev/mqueue type autofs
(rw,relatime,fd=34,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
systemd-1 on /dev/hugepages type autofs
(rw,relatime,fd=35,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
tmpfs on /var/run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda3 on /mnt/windows type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)

Is there anything I can do to avoid this?

Thanks in advance,
Christian Parpart.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20111020/52085e8b/attachment.html>


More information about the lxc-users mailing list