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

Michael H. Warfield mhw at WittsEnd.com
Sat Jun 28 15:12:20 UTC 2014 

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.

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!

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

More information about the lxc-users mailing list