Provide a default network and configurations

Bug #801002 reported by Robert Collins
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
lxc (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

A simple lxcbr0 bridge forwarded to the default route, with private dnsmasq, would suffice. The original description is another good suggestion.

Original Description:
libvirt-bin is needed for the usual setup of a container - it offers the local bridge network and dhcp server, lxc not depending on it leads to confusion.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I think a better solution would be to add some scipts to the package to set up bridges as per

http://s3hh.wordpress.com/2011/05/17/lxc-with-bridged-network/

and

http://s3hh.wordpress.com/2011/05/17/lxc-containers-on-a-host-with-wireless/

Would you agree with that? If so I can just retitle this bug accordingly

Revision history for this message
Robert Collins (lifeless) wrote :

Well, libvirt-bin seems to JustWork with the one exception of not permitting ingress traffic - but then kvm has the same issue.

It seems to me that fixing libvirt-bin to have a mode where you get bridged to the container/vm + NAT for ingress traffic would help lxc, kvm etc - better than just helping lxc, and shouldn't be any harder.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

(Marking this Medium priority, since bootstrapping new users without adding complications is pretty important)

Changed in lxc (Ubuntu):
importance: Undecided → Medium
summary: - lxc would save users some confusion if it depended / recommended
- libvirt-bin
+ Provide a default network and configurationss
summary: - Provide a default network and configurationss
+ Provide a default network and configurations
description: updated
Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 801002] Re: Provide a default network and configurationss

forwarding is definitely not equivalent. Consider offline
(train/plane/park) usage and wifi usage (two separate cases). In the
former there is no default route to forward too. In the second case
you have to do iptables SNAT to avoid firmware limits on forwarded MAC
addresses.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Quoting Robert Collins (<email address hidden>):
> forwarding is definitely not equivalent. Consider offline
> (train/plane/park) usage and wifi usage (two separate cases). In the
> former there is no default route to forward too. In the second case
> you have to do iptables SNAT to avoid firmware limits on forwarded MAC
> addresses.

I've had no troubles with the forwarded bridge with wireless NIC. Still
it might be worth discussing this at UDS. Stéphane Graber offers a
default network in arkose which he had mentioned offering as example/demo
in lxc. At the last UDS Orlando, it was decided that (for then) we did
not want lxc to get mired down in such details, and we should indeed
use libvirt.

Stéphane, do you object to depending on libvirt and installing a default
/etc/lxc.conf using virbr0 for O? Would you prefer to follow the route
Arkose uses as you'd mentioned at the sprint? Or should we just do
nothing for O?

In any case we can discuss at UDS and change course for P.

-serge

Revision history for this message
Stéphane Graber (stgraber) wrote :

On 09/12/2011 10:20 AM, Serge E. Hallyn wrote:
> Quoting Robert Collins (<email address hidden>):
>> forwarding is definitely not equivalent. Consider offline
>> (train/plane/park) usage and wifi usage (two separate cases). In the
>> former there is no default route to forward too. In the second case
>> you have to do iptables SNAT to avoid firmware limits on forwarded MAC
>> addresses.
>
> I've had no troubles with the forwarded bridge with wireless NIC. Still
> it might be worth discussing this at UDS. Stéphane Graber offers a
> default network in arkose which he had mentioned offering as example/demo
> in lxc. At the last UDS Orlando, it was decided that (for then) we did
> not want lxc to get mired down in such details, and we should indeed
> use libvirt.
>
> Stéphane, do you object to depending on libvirt and installing a default
> /etc/lxc.conf using virbr0 for O? Would you prefer to follow the route
> Arkose uses as you'd mentioned at the sprint? Or should we just do
> nothing for O?
>
> In any case we can discuss at UDS and change course for P.
>
> -serge

I think it's a bit late for O as doing that dependency change will
effectively bring libvirt-bin on all Edubuntu systems (as arkose and LXC
are part of our default see).

I indeed think it'd be great having LXC up and running immediately when
installed but don't think depending on libvirt is the right way of doing
it, especially as libvirt ships its own "lxc" and that would likely
confuse a lot of users.

So I'd prefer we don't do anything for O expect maybe shipping a script
in /usr/share/doc/lxc to setup a bridge (you can look at the one from my
lxc-demo.sh script).

For P we can rediscuss the situation at UDS but I'd much rather have the
LXC init script initialize a bridge and setup iptables (assuming that
feature is enabled in /etc/lxc.conf) than depend on libvirt for doing it.

--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

Changed in lxc (Ubuntu):
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lxc - 0.7.5-3ubuntu4

---------------
lxc (0.7.5-3ubuntu4) precise; urgency=low

  * add a default bridge for lxc to use. (LP: #801002)
  * Add debian/lxc.conf, which gets installed as /etc/lxc/lxc.conf as a
    sample, usable, default config. (LP: #823862)
  * Add precise to the list of distros
  * Add -updates and -security to /etc/apt/sources.list after debootstrap
    for container creation (LP: #820715)
 -- Serge Hallyn <email address hidden> Thu, 10 Nov 2011 16:00:44 -0600

Changed in lxc (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.