[lxc-users] lxc-start failing in Fedora 20

Serge Hallyn serge.hallyn at ubuntu.com
Mon Jun 30 13:46:31 UTC 2014 

Quoting Michael H. Warfield (mhw at WittsEnd.com):
> On Sat, 2014-06-28 at 20:12 +0530, Ajith Adapa wrote:
> > Thanks @Michael
> 
> > I am running lxc 1.0.3 version in rawhide.
> 
> Ah.  Ok...  Understand that lxc-autostart is not fully functional in
> 1.0.3 and will not autoboot containers on host boot.  That's in 1.0.4
> which should be in there rsn.
> 
> > My fedora 20 setup is a VM and hasn't got libvirtd running. As you
> > mentioned earlier thats the reason why virbr0 is not created by
> > default.
> 
> > Why doesn't lxc directly support creating virbr0 ? Might be one more
> > option in the template.
> 
> For that, I think I'll have to defer to Serge or Stéphane for a
> definitive answer but, IMHO, it's largely because libvirt is already
> responsible for virbr0 and we could result in conflicts.  Not saying we
> would but just that there could be.  Worse case would be a race
> condition between us in lxc-autostart-helper and the libvirt service in
> trying to create that bridge.  It could result in a failure in one
> service or the other.
> 
> It's also possible that we've just never really looked into it.  Perhaps
> there should be a run-time dependency on libvirt running that we could
> detect and document better.  The error message leaves a little bit to be
> desired.

Right, the setup of host bridges is not for lxc-start to do, but for the
distro-dependent init scripts.  In Ubuntu we create lxcbr0 - perhaps the
fedora/centos/oracle scripts should do the same?  If they depend on virbr0
then indeed they should depend on libvirt being started before proceeding
to autostart containers.

We're definately open to patches that make for clearer error messages,
Stéphane pushed one like that recently.  It'd be nice if you didn't have
to understand every detail about container startup to debug why a
container failed.

> Given that, it's not a template issue at all and wouldn't (shouldn't)
> require any container config changes.  It would need to be some sort of
> lxc service startup option to precreate the needed bridges or a helper.
> 
> Given all that, 1.0.4 may very well resolve (or may compound) the
> problem as the lxc.service systemd service uses a script that waits for
> virbr0 from libvirt to settle before autobooting containers (there's
> where your race conditions would live).  I'm not sure how that's going
> to play out if libvirt is not running.  It looks like we may need to add
> code to /usr/libexec/lxc/lxc-autostart-helper to insure that the default
> lxc network bridge is running.  I'd be reluctant to adding it to the
> lxc-start code as it would be difficult to insure it would always be
> doing the right thing including cases like unpriv containers.
> 
> This is a corner case that, maybe, Dwight and I may need to address or
> punt it over to Serge or Stéphane.  It's complicated in that we don't
> always know the bridges that are needed or even if they are need if a
> site is using "macvlan" or "physical" network types.  It definitely
> needs to be tested.
> 
> > I will try out the steps given regarding password.
> 
> Cool.
> 
> > Regards,
> > Ajith
> 
> Regards,
> Mike
> 
> > On Sat, Jun 28, 2014 at 7:13 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > > On Sat, 2014-06-28 at 15:34 +0530, Ajith Adapa wrote:
> > >> Hi,
> > >
> > >> lxc-start is failing in latest fedora 20 saying virbr0 is not found.
> > >
> > > What version of LXC?  AFAIK, it's still 0.9.0 with 1.0.3 (hopefully
> > > 1.0.4 real soon now) in rawhide.
> > >
> > >> 1. Is it madatory for the admin to create virbr0 interface before
> > >> starting a container ?
> > >
> > > Yes.  You have two ways to do this.
> > >
> > > 1) [Preferred] have libvirt running.  That's the default bridge for
> > > libvirt and it wills set it up and manage it for you.
> > >
> > > 2) Create the bridge manually.
> > >
> > > If you have another bridge already on the system, you can change the
> > > bridge name in the configuration files and in /etc/lxc/default.conf.
> > > Personally, I keep libvirt and virbr0 up and running for my nat'ed
> > > bridge while I have a static lxcbr0 to which the primary interface has
> > > been added for a true bridge to the outer network (but I have lots of
> > > IPv4 addresses so I can allow them direct access to the address pool.
> > >
> > >> 2. How can I create a container with a default password for root
> > >> rather than auto-generating the same ?
> > >
> > > It's a tuning knob in the template.  Read the comments in
> > > the /usr/share/lxc/templates/lxc-fedora file starting around line 32...
> > >
> > > --
> > >
> > > # Some combinations of the tunning knobs below do not exactly make sense.
> > > # but that's ok.
> > > #
> > > # If the "root_password" is non-blank, use it, else set a default.
> > > # This can be passed to the script as an environment variable and is
> > > # set by a shell conditional assignment.  Looks weird but it is what it is.
> > > #
> > > # If the root password contains a ding ($) then try to expand it.
> > > # That will pick up things like ${name} and ${RANDOM}.
> > > # If the root password contians more than 3 consecutive X's, pass it as
> > > # a template to mktemp and take the result.
> > > #
> > > # If root_display_password = yes, display the temporary root password at exit.
> > > # If root_store_password = yes, store it in the configuration directory
> > > # If root_prompt_password = yes, invoke "passwd" to force the user to change
> > > # the root password after the container is created.
> > > #
> > > # These are conditional assignments...  The can be overridden from the
> > > # preexisting environment variables...
> > > #
> > > # Make sure this is in single quotes to defer expansion to later!
> > > # :{root_password='Root-${name}-${RANDOM}'}
> > > : ${root_password='Root-${name}-XXXXXX'}
> > >
> > > # Now, it doesn't make much sense to display, store, and force change
> > > # together.  But, we gotta test, right???
> > > : ${root_display_password='no'}
> > > : ${root_store_password='yes'}
> > > # Prompting for something interactive has potential for mayhem
> > > # with users running under the API...  Don't default to "yes"
> > > : ${root_prompt_password='no'}
> > >
> > > --
> > >
> > > Stated plainly, create your container with the following:
> > >
> > > export root_store_password='no'
> > > export root_password='my_root_password'
> > > lxc-create -n container1 -t fedora
> > > lxc-create -n container2 -t fedora
> > >
> > > etc, etc, etc...  Each container will have the root password set to
> > > "my_root_password".
> > >
> > > Or this:
> > >
> > > export root_prompt_password='yes'
> > >
> > > Then run lxc-create and it will then prompt you for the new root
> > > password.
> > >
> > > NOTE: This only works for the Fedora and CentOS templates.  It has not
> > > been ported to any of the other templates at this time!
> > >
> > >>
> > >> # lxc-create -n test -t fedora
> > >> Host CPE ID from /etc/os-release: cpe:/o:fedoraproject:fedora:20
> > >> Checking cache download in /var/cache/lxc/fedora/x86_64/20/rootfs ...
> > >> Cache found. Updating...
> > >> No packages marked for update
> > >> Update finished
> > >> Copy /var/cache/lxc/fedora/x86_64/20/rootfs to /var/lib/lxc/test/rootfs ...
> > >> Copying rootfs to /var/lib/lxc/test/rootfs ...
> > >> Storing root password in '/var/lib/lxc/test/tmp_root_pass'
> > >> Expiring password for user root.
> > >> passwd: Success
> > >> installing fedora-release package
> > >> Package fedora-release-20-3.noarch already installed and latest version
> > >> Nothing to do
> > >>
> > >> Container rootfs and config have been created.
> > >> Edit the config file to check/enable networking setup.
> > >>
> > >> The temporary root password is stored in:
> > >>
> > >>         '/var/lib/lxc/test/tmp_root_pass'
> > >>
> > >>
> > >> The root password is set up as expired and will require it to be changed
> > >> at first login, which you should do as soon as possible.  If you lose the
> > >> root password or wish to change it without starting the container, you
> > >> can change it from the host by running the following command (which will
> > >> also reset the expired flag):
> > >>
> > >>         chroot /var/lib/lxc/test/rootfs passwd
> > >>
> > >> # lxc-start -n test
> > >> lxc-start: failed to attach 'vethKOT10G' to the bridge 'virbr0' : No such device
> > >> lxc-start: failed to create netdev
> > >> lxc-start: failed to create the network
> > >> lxc-start: failed to spawn 'test'
> > >>
> > >> ======================================================
> > >> configuration
> > >> ======================================================
> > >>
> > >> # yum install lxc*
> > >> Loaded plugins: langpacks
> > >> Package lxc-extra-1.0.3-2.fc21.x86_64 already installed and latest version
> > >> Package lxc-templates-1.0.3-2.fc21.x86_64 already installed and latest version
> > >> Package lxc-libs-1.0.3-2.fc21.x86_64 already installed and latest version
> > >> Package lxc-1.0.3-2.fc21.x86_64 already installed and latest version
> > >> Package lxc-doc-1.0.3-2.fc21.noarch already installed and latest version
> > >> Package lxc-devel-1.0.3-2.fc21.x86_64 already installed and latest version
> > >>
> > >> -------------------------------------------
> > >>
> > >> # lxc-checkconfig
> > >> Kernel configuration not found at /proc/config.gz; searching...
> > >> Kernel configuration found at /boot/config-3.14.5-200.fc20.x86_64
> > >> --- Namespaces ---
> > >> Namespaces: enabled
> > >> Utsname namespace: enabled
> > >> Ipc namespace: enabled
> > >> Pid namespace: enabled
> > >> User namespace: enabled
> > >> Network namespace: enabled
> > >> Multiple /dev/pts instances: enabled
> > >>
> > >> --- Control groups ---
> > >> Cgroup: enabled
> > >> Cgroup clone_children flag: enabled
> > >> Cgroup device: enabled
> > >> Cgroup sched: enabled
> > >> Cgroup cpu account: enabled
> > >> Cgroup memory controller: enabled
> > >> Cgroup cpuset: enabled
> > >>
> > >> --- Misc ---
> > >> Veth pair device: enabled
> > >> Macvlan: enabled
> > >> Vlan: enabled
> > >> File capabilities: enabled
> > >>
> > >> Note : Before booting a new kernel, you can check its configuration
> > >> usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
> > >>
> > >> Regards,
> > >> Ajith
> > >
> > > Regards,
> > > Mike
> > > --
> > > 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!
> 



> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

More information about the lxc-users mailing list