[Lxc-users] Converting openvz guests to lxc

John Drescher drescherjm at gmail.com
Tue Jan 19 17:01:37 UTC 2010


> On Tue, 2010-01-19 at 10:24 -0500, John Drescher wrote:
>> I have been testing converting working openvz guests to lxc without
>> success. I have two basic problems.
>
>> 1. The lxc guest is taking over the virtual terminals of the host.
>
> Why do you believe this?  I don't see anything below indicative of that.
> There are some errors that seem to indicate they're not getting set up
> properly.
>

When I switch virtual consoles under the virtual box container
(remember I am testing this under virtual box) the first 4 virtual
consoles answer as the guest.

>
>> 2. The lxc guest pauses randomly for a few seconds.
>
> This could be related to the virtual terminals.  If agetty is failling
> to open those  tty's, it will spin for a second till init complains that
> it's respawning too fast.
>
> Since you can get in using ssh, why not start out by disabling those
> consoles and see if that fixes the random pauses (I'm not seeing this on
> my Fedora based systems).
>
>> I am using gentoo as the host (under virtualbox for testing so I do
>> not disturb the real openvz host) and guest using containers that work
>> under openvz specifically 2.6.27 openvz kernels.
>
> I don't use gentoo so I don't know it very well at all.  But I can't
> think of anything that would be gentoo specific.
>
>> localhost ~ # equery l lxc
>> [ Searching for package 'lxc' in all categories among: ]
>>  * installed packages
>> [I--] [ ~] app-emulation/lxc-0.6.4-r2 (0)
>> localhost ~ # uname -a
>> Linux localhost 2.6.32-gentoo #10 SMP Sat Jan 16 23:50:38 Local time
>> zone must be set--see zic x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @
>> 2.83GHz GenuineIntel GNU/Linux
>>
>>
>> localhost ~ # lxc-start -n guest_1
>> INIT: version 2.86 booting
>> Loading /lib64/rc/console/keymap
>>
>>    OpenRC 0.5.2 is starting up Gentoo Linux (x86_64) [LXC]
>>
>> * /proc is already mounted, skipping
>> * Setting hostname to gentoo-openvz-~core2-2009-11-13...                  [ ok ]
>> * Configuring kernel parameters...                                        [ ok ]
>> * Creating user login records...                                          [ ok ]
>> * Cleaning /var/run...                                                    [ ok ]
>> * Wiping /tmp directory...                                                [ ok ]
>> * Setting terminal encoding [UTF-8]...
>> /etc/init.d/termencoding: line 31: /dev/tty5: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty6: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty7: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty8: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty9: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty10: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty11: Operation not permitted
>> /etc/init.d/termencoding: line 31: /dev/tty12: Operation not permitted    [ ok ]
>
> The previous lines are occurring because you only allowed 4 virtual
> terminals in the guest.  That's what I see with Debian as well.
>
>> * Loading key mappings [us]...                                            [ ok ]
>> * Setting keyboard mode [UTF-8]...
>> Couldnt open /dev/tty1
>> Couldnt open /dev/tty2
>> Couldnt open /dev/tty3
>> Couldnt open /dev/tty4
>
> Now the above 4 lines should NOT be happening.  Not sure in Gentoo what
> it is that's trying to open them, since it's part of a longer series and
> your modified inittab below didn't have entries for the following
> errors.
>
>> Couldnt open /dev/tty5
>> Couldnt open /dev/tty6
>> Couldnt open /dev/tty7
>> Couldnt open /dev/tty8
>> Couldnt open /dev/tty9
>> Couldnt open /dev/tty10
>> Couldnt open /dev/tty11
>> Couldnt open /dev/tty12                                                   [ ok ]
>
> No idea what's trying to open them.  It's not in the inittab below.
>
>> * Bringing up interface eth0
>> *   dhcp...
>> *     Running dhcpcd...
>> eth0: dhcpcd 4.0.13 starting
>> eth0: broadcasting for a lease
>> eth0: offered 192.168.1.102 from 192.168.1.1
>> eth0: acknowledged 192.168.1.102 from 192.168.1.1
>> eth0: checking 192.168.1.102 is available on attached networks
>> eth0: leased 192.168.1.102 for 86400 seconds                              [ ok ]
>> *     received address 192.168.1.102/24                                   [ ok ]
>> *   Adding routes
>> *     default via 192.168.1.1...
>> SIOCADDRT: File exists                                                    [ !! ]
>
> That's strange...
>
>> * Starting network                                                        [ ok ]
>> * Initializing random number generator...                                 [ ok ]
>> INIT: Entering runlevel: 3
>> * Mounting network filesystems...                                         [ ok ]
>> * Starting syslog-ng...
>> Jan 19 10:17:09 gentoo-openvz-~core2-2009-11-13 syslog-ng[329]:
>> syslog-ng starting up; version='3.0.4'
>>                    [ ok ]
>> * Starting sshd...
>> Jan 19 10:17:10 gentoo-openvz-~core2-2009-11-13 sshd[343]: Server
>> listening on 0.0.0.0 port 22.
>>                  [ ok ]
>> * Starting local...                                                       [ ok ]
>>
>>
>> This is gentoo-openvz-~core2-2009-11-13.unknown_domain (Linux x86_64
>> 2.6.32-gentoo) 10:17:11
>>
>> gentoo-openvz-~core2-2009-11-13 login:
>>
>>
>> localhost ~ # cat /lxc/guest_1/etc/inittab
>> #
>> # /etc/inittab:  This file describes how the INIT process should set up
>> #                the system in a certain run-level.
>> #
>> # Author:  Miquel van Smoorenburg, <miquels at cistron.nl>
>> # Modified by:  Patrick J. Volkerding, <volkerdi at ftp.cdrom.com>
>> # Modified by:  Daniel Robbins, <drobbins at gentoo.org>
>> # Modified by:  Martin Schlemmer, <azarah at gentoo.org>
>> #
>> # $Header: /var/cvsroot/gentoo-x86/sys-apps/sysvinit/files/inittab,v
>> 1.5 2005/12/22 02:03:23 vapier Exp $
>>
>> # Default runlevel.
>> id:3:initdefault:
>>
>> # System initialization, mount local filesystems, etc.
>> si::sysinit:/sbin/rc sysinit
>>
>> # Further system initialization, brings up the boot runlevel.
>> rc::bootwait:/sbin/rc boot
>>
>> l0:0:wait:/sbin/rc shutdown
>> l1:S1:wait:/sbin/rc single
>> l2:2:wait:/sbin/rc nonetwork
>> l3:3:wait:/sbin/rc default
>> l4:4:wait:/sbin/rc default
>> l5:5:wait:/sbin/rc default
>> l6:6:wait:/sbin/rc reboot
>> #z6:6:respawn:/sbin/sulogin
>>
>> # TERMINALS
>> #c1:12345:respawn:/sbin/agetty 38400 tty1 linux
>> #c2:2345:respawn:/sbin/agetty 38400 tty2 linux
>> #c3:2345:respawn:/sbin/agetty 38400 tty3 linux
>> #c4:2345:respawn:/sbin/agetty 38400 tty4 linux
>> #c5:2345:respawn:/sbin/agetty 38400 tty5 linux
>> #c6:2345:respawn:/sbin/agetty 38400 tty6 linux
>>
>> # SERIAL CONSOLES
>> #s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
>> #s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100
>>
>> # What to do at the "Three Finger Salute".
>> #ca:12345:ctrlaltdel:/sbin/shutdown -r now
>>
>> # Used by /etc/init.d/xdm to control DM startup.
>> # Read the comments in /etc/init.d/xdm for more
>> # info. Do NOT remove, as this will start nothing
>> # extra at boot if /etc/init.d/xdm is not added
>> # to the "default" runlevel.
>> x:a:once:/etc/X11/startDM.sh
>>
>> # Normally not reached, but fallthrough in case of emergency.
>> z6:6:respawn:/sbin/sulogin
>> 1:2345:respawn:/sbin/agetty 38400 console
>> c1:12345:respawn:/sbin/agetty 38400 tty1 linux
>> c2:12345:respawn:/sbin/agetty 38400 tty2 linux
>> c3:12345:respawn:/sbin/agetty 38400 tty3 linux
>> c4:12345:respawn:/sbin/agetty 38400 tty4 linux
>
> Ok, so you added 4 virtual terminal consoles back into inittab.  Comment
> those out and see if the errors change.
>
>> localhost ~ #
>
>> localhost ~ # cat /etc/lxc/guest_1.conf
>> lxc.utsname = guest_1
>> lxc.mount = /etc/lxc/guest_1.fstab
>> lxc.rootfs = /lxc/guest_1
>> lxc.tty = 4
>
> Here is where you get the 4 virtual consoles from (tty1 - tty4).
>
>> lxc.pts = 1024
>> lxc.network.type = veth
>> lxc.network.flags = up
>> lxc.network.link = br0
>> lxc.network.name = eth0
>> lxc.network.mtu = 1500
>> lxc.cgroup.devices.deny = a
>> # /dev/null and zero
>> lxc.cgroup.devices.allow = c 1:3 rwm
>> lxc.cgroup.devices.allow = c 1:5 rwm
>> # consoles
>> lxc.cgroup.devices.allow = c 5:1 rwm
>> lxc.cgroup.devices.allow = c 5:0 rwm
>> lxc.cgroup.devices.allow = c 4:0 rwm
>> lxc.cgroup.devices.allow = c 4:1 rwm
>
> This would SEEM to indicate you are only allowing /dev/tty (0)
> and /dev/tty1 through to the guest.  That doesn't agree with your
> allowed ttys, but I'm not sure it needs to agree since these get
> remapped.
>
>> # /dev/{,u}random
>> lxc.cgroup.devices.allow = c 1:9 rwm
>> lxc.cgroup.devices.allow = c 1:8 rwm
>> lxc.cgroup.devices.allow = c 136:* rwm
>> lxc.cgroup.devices.allow = c 5:2 rwm
>> # rtc
>> lxc.cgroup.devices.allow = c 254:0 rwm
>>
>> localhost ~ # cat /etc/lxc/guest_1.fstab
>> none /lxc/guest_1/dev/pts devpts defaults 0 0
>> none /lxc/guest_1/proc    proc   defaults 0 0
>> none /lxc/guest_1/sys     sysfs  defaults 0 0
>> none /lxc/guest_1/dev/shm tmpfs  defaults 0 0
>> /usr/portage /lxc/guest_1/usr/portage  none rw,bind 1 0
>
>> Any ideas what I am doing wrong?
>
> Have you tried using lxc-console yet?

No I have not tried that.

> I suspect it will fail (it'll
> just sit there) due to the /dev/tty? errors but it would be good to
> know.  Since sshd is running in the guest, have you tried ssh into it?

I believe that worked. But still pauses.

> If you can connect into it, I'd be interested in seeing what you get
> from:
>
> ps ax
>
> ls -l /dev/tty?
>
> df
>
> mount
>
> cat /proc/mounts
>
> Also a copy of the system log from within the VM (which, yeah, you can
> grab from outside of the VM).
>

I am now at work so I am going to have to try this and the other
suggestions when I get home.
Thank You,

John




More information about the lxc-users mailing list