[lxc-users] Hotplug new network interfaces not working

Michael H. Warfield mhw at WittsEnd.com
Tue May 13 23:57:53 UTC 2014


On Tue, 2014-05-13 at 18:13 -0400, CDR wrote: 
> Dear Mike
> You are right, I only see one line.

> ls rootfs/etc/systemd/system/getty.target.wants -l
> total 0
> lrwxrwxrwx 1 root root 38 Apr 30 11:16 getty at tty1.service ->
> /usr/lib/systemd/system/getty at .service

Ok...

> You wouldn't have the script to fix this around?

I think Fajar pointed you to it.  It's in the template.

> I created my Fedora 20 containers from within a Fedora box, like this:

> #!/bin/sh
> source /etc/profile
> container=nat-1
> mkdir -p /var/lib/lxc/${container}/rootfs
> yum -y --releasever=20 --nogpg --installroot=/var/lib/lxc/$container/rootfs \
>           install systemd autofs passwd yum fedora-release vim-minimal
> openssh-server openssh-clients gcc autogen automake\
> subversion procps-ng initscripts net-tools ethtool nano dhcp dhclient
> lsof bind-utils psmisc bash-completion policycoreutils\
> libvirt libcap-devel lxc deltarpm bridge-utils strace git rpm-build
> docbook2X graphviz man netstat-nat
> cp /usr/src//ifup-local /var/lib/lxc/$container/rootfs/sbin/
> cp /etc/sysconfig/network /var/lib/lxc/$container/rootfs/etc/sysconfig
> cp /usr/src/ifcfg-eth0
> /var/lib/lxc/$container/rootfs/etc/sysconfig/network-scripts/ifcfg-eth0
> cp /usr/src/ifcfg-eth1
> /var/lib/lxc/$container/rootfs/etc/sysconfig/network-scripts/ifcfg-eth1
> echo "pts/0" >> /var/lib/lxc/$container/rootfs/etc/securetty
> cp /usr/src/config /var/lib/lxc/$container/
> cp /usr/src/lxc*.rpm /var/lib/lxc/$container/rootfs/usr/src
> touch  /var/lib/lxc/$container/rootfs/etc/resolv.conf
> chroot /var/lib/lxc/$container/rootfs /bin/passwd root

Oh, that explains a LOT and tells me you will have much bigger problems.
These templates are designed to not only copy the distros into root file
systems but to fine tune some of the peculiarities of running in a
container, which can be (definitely IS) dependent on the startup init
process.  You should read through some of these template scripts and
understand, very thoroughly, how and why (I DO try and comment my
templates about WHY I'm doing something that's non-intuitive) they are
doing what they're doing before you attempt to create a script like
this.

> Yours

> Federico

Regards,
Mike

> On Tue, May 13, 2014 at 1:42 PM, CDR <venefax at gmail.com> wrote:
> > Let me digest all this.
> > You must be right, because Fedora 20 containers are the only ones that
> > use systemd, in my box
> >
> > many thanks
> >
> > Federico
> >
> > On Tue, May 13, 2014 at 1:24 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> >> On Tue, 2014-05-13 at 13:00 -0400, CDR wrote:
> >>> I am forced to use libvirt-lxc only because nobody can help me solve
> >>> this issue. If somebody can figure this out, then I will only use lXC.
> >>> In a Fedora20 container, if I start it with the "-d" flag, then it
> >>> never let's me enter the container via the console, it times out on me
> >>> when I use
> >>> lxc-console -n mycontainer.
> >>
> >> I guess the problem is, here, that this doesn't make sense (to me).  I
> >> work and develop under Fedora (17,18,19,20,rawhide).  I have containers
> >> of virtually every guest distro, even Gentoo and SUSE and a few others
> >> (NST, Kali) which are not supported.  I've got Fedora20 containers of
> >> both x86_64 and i686 archs.  I'm not seeing this problem.  I've started
> >> them without the -d as well as with the -d and currently start them
> >> using lxc-autostart and I'm just not seeing this problem.
> >>
> >> The problem is in trying to decide why your setup is (or your containers
> >> are) different or what you are doing different so we might address it
> >> (either in code or documentation).
> >>
> >> These are Fedora20 containers you are trying to start?  Under what rev
> >> where they created (not what you're running now)?  I know I had to add
> >> some code to the Fedora template to create the console devices...
> >>
> >> Look here:
> >>
> >> /var/lib/lxc/{container}/rootfs/etc/systemd/system/getty.target.wants
> >>
> >> Now look for a series of symlinks like this:
> >>
> >> [root at hydra getty.target.wants]# pwd
> >> /var/lib/lxc/Fedora20/rootfs/etc/systemd/system/getty.target.wants
> >> [root at hydra getty.target.wants]# ls -l
> >> total 0
> >> lrwxrwxrwx. 1 root root 17 Mar  7 19:02 getty at tty1.service -> ../getty at .service
> >> lrwxrwxrwx. 1 root root 17 Mar  7 19:02 getty at tty2.service -> ../getty at .service
> >> lrwxrwxrwx. 1 root root 17 Mar  7 19:02 getty at tty3.service -> ../getty at .service
> >> lrwxrwxrwx. 1 root root 17 Mar  7 19:02 getty at tty4.service -> ../getty at .service
> >>
> >> If you don't have them, that's your problem.  The lxc-fedora template
> >> now creates these automatically.  This is systemd stuff.  The
> >> pre-systemd Fedora template did not do this.  If you want more than
> >> four, you're going to have to create them yourself and add the changes
> >> to the config file for the vty's.
> >>
> >> If you don't have them, you probably DON'T have the properly munged
> >> getty at .service file in the parent directory, so you can't just copy the
> >> systemd default or blindly create them
> >>
> >> This change has to be made!
> >>
> >> [root at hydra rootfs]# diff lib/systemd/system/getty at .service etc/systemd/system/getty at .service
> >> 24c24
> >> < ConditionPathExists=/dev/tty0
> >> ---
> >>> # ConditionPathExists=/dev/tty0
> >>
> >> If you don't have that...  That's your problem.
> >>
> >>> This happens only in Fedora 20 containers. But that does not happen
> >>> under libvirt. I have 3  different OS' containers, and the other two
> >>> work fine under pure LXC.
> >>
> >> It's not just under Fedora 20 containers but will impact any containers
> >> running systemd in a container, which has proven to be a black art for
> >> me.
> >>
> >> Regards,
> >> Mike
> >>
> >>> I think that the bug is in LXC. If I ask Libvirt, they will respond
> >>> "it does work, doesn't it?
> >>> Any idea?
> >>> Philip
> >>>
> >>> On Tue, May 13, 2014 at 12:35 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> >>> > On Tue, May 13, 2014 at 12:29:07PM -0400, Michael H. Warfield wrote:
> >>> >> On Tue, 2014-05-13 at 12:09 -0400, CDR wrote:
> >>> >> > Dear Friends
> >>> >> > I have a Fedora 20 LXC (libirt) container in production and I cannot reboot it.
> >>> >> > So I used "virsh edit mycontainer" and added several
> >>> >> >
> >>> >> > <interface type='direct'>
> >>> >> >       <mac address='00:5A:0C:18:C9:E9'/>
> >>> >> >       <source dev='eth1' mode='bridge'/>
> >>> >> >     </interface>
> >>> >>
> >>> >> Ok...  But that's libvirt LXC, not LXC-Tools LXC.
> >>> >>
> >>> >> > The problem is that after it gets saved, the new interfaces never show
> >>> >> > up in ip link, and I have no idea how to make Fedora under LXC to
> >>> >> > check for the new hardware.
> >>> >>
> >>> >> > Is this a limitation of LXC in general?
> >>> >>
> >>> >> The term "LXC" in this case is ambiguous.  Are you talking about libvirt
> >>> >> lxc or this project.  They are not the same.
> >>> >>
> >>> >> > I bet there is a workaround.
> >>> >>
> >>> >> Only if you're skilled at creating hotplug and udev rules.  It has to be
> >>> >> done under the host and the host has to transfer that device into the
> >>> >> container.  It's not something that's really controllable from the
> >>> >> container per se.  I can run devices and such in and out of LXC
> >>> >> containers (NOT libvirt) with some scripting and some rules in the host,
> >>> >> but I doubt that would help you (I take advantage of some of the
> >>> >> devtmpfs stuff I wrote for this project).  Libvirt may have a way to
> >>> >> work around that but you'll have to consult with them.
> >>> >>
> >>> >> I think Stéphane also had some utility for moving devices (interfaces,
> >>> >> I'm not so sure) but, again, that's for this project, not libvirt.
> >>> >
> >>> > Correct, lxc-device will let you do that with our LXC.
> >>> >
> >>> >>
> >>> >> > Yours
> >>> >> > Philip
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
> >>> >>    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
> >>> >>    NIC whois: MHW9          | An optimist believes we live in the best of all
> >>> >>  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> >> _______________________________________________
> >>> >> lxc-users mailing list
> >>> >> lxc-users at lists.linuxcontainers.org
> >>> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> >>> >
> >>> >
> >>> > --
> >>> > Stéphane Graber
> >>> > Ubuntu developer
> >>> > http://www.ubuntu.com
> >>> >
> >>> > _______________________________________________
> >>> > lxc-users mailing list
> >>> > lxc-users at lists.linuxcontainers.org
> >>> > http://lists.linuxcontainers.org/listinfo/lxc-users
> >>> _______________________________________________
> >>> lxc-users mailing list
> >>> lxc-users at lists.linuxcontainers.org
> >>> http://lists.linuxcontainers.org/listinfo/lxc-users
> >>
> >> --
> >> Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
> >>    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
> >>    NIC whois: MHW9          | An optimist believes we live in the best of all
> >>  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
> >>
> >>
> >> _______________________________________________
> >> lxc-users mailing list
> >> lxc-users at lists.linuxcontainers.org
> >> http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140513/d7b41378/attachment.sig>


More information about the lxc-users mailing list