Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this ?
Dear Michael, I always hate replying to my own posts but I have stumbled onto some interesting clarification as I've continued to play with this... Below in-line. [...] Again a well-done investigation. For everyone who don't have the time to carefully read this threads, i want to sum the (imho) key statements: * With kernel 2.6.27ff, one MAY make a MAC sticky to a bridge using standard tools, e.g. ifconfig br0 hw ether 12:34:56:78:90:ab This will turn off the auto-select-the-lowest-MAC-algorithm. * But the MAC MUST be one of the attached NICs to get the stacks layer2 packet routing working. The problem is that the bridge only thinks a packet is local if it arrives with destination hw addr == incoming device address. You might have more than one bridge and they may attached to different groups of NICs. Therefore, there have to be a layer 2 instrument (the MAC) to find the right bridge by its table of MACs spanned by the attached interfaces. For us LXC-users it means, we should make the MAC of the hosts interface sticky to the attached bridge. Unfortunately, there's no support by the brctrl command for it (, like 'brctrl addif bridge interface [--sticky]'). Therefore, one have to use something like ifconfig $BRIDGE hw ether `LANG= ifconfig $HOSTNIC | sed -ne /HWaddr/ s/.* HWaddr \(.*\)$/\1/p` in an ifup-post-script. greetings Guido -- Dr. Guido Jäkel Deutsche Nationalbibliothek IT SG 2.2 (Infrastruktur Unix) Adickesallee 1 60322 Frankfurt am Main Tel. +49-69-1525-1750 Fax +49-69-1525-1799 mailto:g.jae...@dnb.de http://www.dnb.de -- Cloud Computing - Latest Buzzword or a Glimpse of the Future? This paper surveys cloud computing today: What are the benefits? Why are businesses embracing it? What are its payoffs and pitfalls? http://www.accelacomm.com/jaw/sdnl/114/51425149/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this ?
I always hate replying to my own posts but I have stumbled onto some interesting clarification as I've continued to play with this... Below in-line. On Tue, 2011-12-13 at 01:30 -0500, Michael H. Warfield wrote: On Mon, 2011-12-12 at 08:43 +0100, Ulli Horlacher wrote: On Sun 2011-12-11 (19:48), Derek Simkowiak wrote: The problem is not related to the setfd option. It is caused by the bridge acquired a new MAC address. Libvirt already has a fix for this, and there is a patch in the works for the LXC tools. I am wonder why I do not have this problem: I really often start new containers and I do not have this patch, but no network freeze at all. Look to your MAC addresses. If the MAC address of the new container is greater than the MAC address of the bridge, you will never see this problem. If it's less than the bridge MAC address, the MAC address will change and, if you have any active network traffic, you WILL see this problem. The problem is old and related to a design decision wrt the bridges in the Linux kernel. I don't really agree with where the decision went but I understand the problem and their concerns (IIRC). The problem is the bridge NEEDS a MAC address but has no intrinsic address. So, they started out by assigning the MAC address of the first device assigned to the bridge. That worked but had a problem. The bridge is an independent autonomous object within the kernel and must be independent of the connected devices. Sooo, what happens to the MAC address if you delete that device from the bridge? It can't stay the same. Now, my memory is very fuzzy after about a decade (and Google searches are NOT helping my research) and anyone is welcome to correct me if I recall incorrect but... The arbitrary decision was made to always use the lowest MAC address on the bridge. The trouble is that they did that when they added devices. The problem really only occurs when you delete devices and, even then, only when the MAC of the bridge matches the MAC of the device being deleted and there is no other device with that MAC address (multihomed SPARCs) on that bridge. I would have chosen differently but this was not my shot to call and I didn't have any strong arguments to even insert into the discussion. They chose to always use the lowest MAC address. The choice was arbitrary but a choice had to be made. No choice was a non-starter and all choices had some downside to them. There are actually TWO solutions to this problem. The first one people have already glommed onto. You have to set your MAC address of your containers to be greater than the MAC address of the bridge. Problems there are that 1) we don't have our own vendor code and 2) we have to make sure we're higher than ANY vendor code and 3) the locally administered bit is NOT the highest order bit in the MAC address (that really would have made it too easy to fix but that's and even more ancient bad choice). The good point is that we CAN auto assign anything we WANT as long as that locally administered bit is set and we can then set the vendor code as high as we want. THAT works. Use FF:FF:F2:: and you are gold. Play with the remaining bits all you want. There is another. When creating the bridge, assign it a MAC address that's very LOW. You can do that with ifconfig or ip. It doesn't HAVE to have a MAC address that matches ANY interface attached to it. That's a misconception. It merely has to HAVE a MAC address. The problem with this solution is that technically that MAC address is then locally administered so the locally administered bit SHOULD be set (00:02::) but then anything of the vendor codes from 00:00:00:: through 00:00:ff:: would be less than that (00:01:: is the multicast bit). Grrr... But it's only 256 old vendors. Using 00:00:00:: for the vendor code works and is sooo unlikely to conflict with Xerox Corporation (vendor code 00:00:00) or their Ethernet cards (I know I'll get HATE MAIL from purists on THAT comment) that it's really NOT worth worrying about. According to this post, I may be mistaken that it doesn't have to be an address of a connected interface. http://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports/ In my testing I've certainly found that it does NOT have to be a MAC of a connected interface for IPv6 to work. My results for IPv4 have been mixed where, in one case, it did not and, in another case, it did. IPv6 worked in both cases but there are some peculiar filtering paths down in the kernel bridging logic that could well be coming into play here. It may also have to do with the MAC address detection logic and spanning tree algorithms. So be cautious there. But there was this remark: -- Fortunately, there is a way to ensure that the bridge's MAC address is fixed and never changes, thus entirely avoiding the problem. Thanks to this thread
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
On 12/12/2011 04:48 AM, Derek Simkowiak wrote: When there are only one bridge on the system or the bridges are not connected together, this option is pointless and we can set the delay to '0'. That makes the port to be enabled instantaneously, hence the container can access the network immediately after the start. As previously posted, this is not what causes the network freeze with LXC. The problem is not related to the setfd option. It is caused by the bridge acquired a new MAC address. Libvirt already has a fix for this, and there is a patch in the works for the LXC tools. See my post about this four days ago at this URL, which includes a link to the patch and a link to a possible workaround: http://osdir.com/ml/lxc-chroot-linux-containers/2011-12/msg00029.html Yes, I was aware of that. I was just explaining why disabling setfd was useful. I have queued the patch to set an higher mac address. Thanks -- Daniel Thanks, Derek On 12/11/2011 02:21 PM, Daniel Lezcano wrote: On 12/08/2011 09:25 AM, Ulli Horlacher wrote: On Thu 2011-12-08 (07:39), Daniel Lezcano wrote: On 12/08/2011 12:38 AM, Joseph Heck wrote: I've been seeing a pause in the whole networking stack when starting and stopping LXC - it seems to be somewhat intermittent, but happens reasonably consistently the first time I start up the LXC. I'm using ubuntu 11.10, which is using LXC 0.7.5 I'm starting the container with lxc-start -d -n $CONTAINERNAME That could be the bridge configuration. Did you do 'brctl setfd br0 0' ? I have this in my /etc/network/interfaces (Ubuntu 10.04): auto br0 iface br0 inet static address 129.69.1.227 netmask 255.255.255.0 gateway 129.69.1.254 bridge_ports eth0 bridge_stp off bridge_maxwait 5 post-up /usr/sbin/brctl setfd br0 0 I have never noticed a network freeze and I really often start/stop LXC containers. Does this brctl setfd br0 0 prevent the freeze? I do not remember why I have added it :-} The setfd delay is used when there are several bridge setup on the system to detect if the packet are looping across the bridges and to learn the spawning tree control. AFAIR, a packet is transmitted on the new port and the bridge waits fordelay to see if the packet goes out of the bridge and came back from another port. During this delay, the port is not enabled. When there are only one bridge on the system or the bridges are not connected together, this option is pointless and we can set the delay to '0'. That makes the port to be enabled instantaneously, hence the container can access the network immediately after the start. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this ?
On Mon, 2011-12-12 at 08:43 +0100, Ulli Horlacher wrote: On Sun 2011-12-11 (19:48), Derek Simkowiak wrote: The problem is not related to the setfd option. It is caused by the bridge acquired a new MAC address. Libvirt already has a fix for this, and there is a patch in the works for the LXC tools. I am wonder why I do not have this problem: I really often start new containers and I do not have this patch, but no network freeze at all. Look to your MAC addresses. If the MAC address of the new container is greater than the MAC address of the bridge, you will never see this problem. If it's less than the bridge MAC address, the MAC address will change and, if you have any active network traffic, you WILL see this problem. The problem is old and related to a design decision wrt the bridges in the Linux kernel. I don't really agree with where the decision went but I understand the problem and their concerns (IIRC). The problem is the bridge NEEDS a MAC address but has no intrinsic address. So, they started out by assigning the MAC address of the first device assigned to the bridge. That worked but had a problem. The bridge is an independent autonomous object within the kernel and must be independent of the connected devices. Sooo, what happens to the MAC address if you delete that device from the bridge? It can't stay the same. Now, my memory is very fuzzy after about a decade (and Google searches are NOT helping my research) and anyone is welcome to correct me if I recall incorrect but... The arbitrary decision was made to always use the lowest MAC address on the bridge. The trouble is that they did that when they added devices. The problem really only occurs when you delete devices and, even then, only when the MAC of the bridge matches the MAC of the device being deleted and there is no other device with that MAC address (multihomed SPARCs) on that bridge. I would have chosen differently but this was not my shot to call and I didn't have any strong arguments to even insert into the discussion. They chose to always use the lowest MAC address. The choice was arbitrary but a choice had to be made. No choice was a non-starter and all choices had some downside to them. There are actually TWO solutions to this problem. The first one people have already glommed onto. You have to set your MAC address of your containers to be greater than the MAC address of the bridge. Problems there are that 1) we don't have our own vendor code and 2) we have to make sure we're higher than ANY vendor code and 3) the locally administered bit is NOT the highest order bit in the MAC address (that really would have made it too easy to fix but that's and even more ancient bad choice). The good point is that we CAN auto assign anything we WANT as long as that locally administered bit is set and we can then set the vendor code as high as we want. THAT works. Use FF:FF:F2:: and you are gold. Play with the remaining bits all you want. There is another. When creating the bridge, assign it a MAC address that's very LOW. You can do that with ifconfig or ip. It doesn't HAVE to have a MAC address that matches ANY interface attached to it. That's a misconception. It merely has to HAVE a MAC address. The problem with this solution is that technically that MAC address is then locally administered so the locally administered bit SHOULD be set (00:02::) but then anything of the vendor codes from 00:00:00:: through 00:00:ff:: would be less than that (00:01:: is the multicast bit). Grrr... But it's only 256 old vendors. Using 00:00:00:: for the vendor code works and is sooo unlikely to conflict with Xerox Corporation (vendor code 00:00:00) or their Ethernet cards (I know I'll get HATE MAIL from purists on THAT comment) that it's really NOT worth worrying about. You do have to be forewarned that tinkering with MAC addresses at runtime can be even MORE disasterous when dealing with IPv6 and autoconf addresses. Assigning a fixed MAC address to a bridge should only be done at boot time and not changed after (one of the arguments against that earlier decision). Which points out another PITA associated with that early decision regarding MAC addresses. It makes a MESS out of IPv6! Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! signature.asc Description: This is a digitally signed message part -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment.
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
On 12/08/2011 09:25 AM, Ulli Horlacher wrote: On Thu 2011-12-08 (07:39), Daniel Lezcano wrote: On 12/08/2011 12:38 AM, Joseph Heck wrote: I've been seeing a pause in the whole networking stack when starting and stopping LXC - it seems to be somewhat intermittent, but happens reasonably consistently the first time I start up the LXC. I'm using ubuntu 11.10, which is using LXC 0.7.5 I'm starting the container with lxc-start -d -n $CONTAINERNAME That could be the bridge configuration. Did you do 'brctl setfd br0 0' ? I have this in my /etc/network/interfaces (Ubuntu 10.04): auto br0 iface br0 inet static address 129.69.1.227 netmask 255.255.255.0 gateway 129.69.1.254 bridge_ports eth0 bridge_stp off bridge_maxwait 5 post-up /usr/sbin/brctl setfd br0 0 I have never noticed a network freeze and I really often start/stop LXC containers. Does this brctl setfd br0 0 prevent the freeze? I do not remember why I have added it :-} The setfd delay is used when there are several bridge setup on the system to detect if the packet are looping across the bridges and to learn the spawning tree control. AFAIR, a packet is transmitted on the new port and the bridge waits for delay to see if the packet goes out of the bridge and came back from another port. During this delay, the port is not enabled. When there are only one bridge on the system or the bridges are not connected together, this option is pointless and we can set the delay to '0'. That makes the port to be enabled instantaneously, hence the container can access the network immediately after the start. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
When there are only one bridge on the system or the bridges are not connected together, this option is pointless and we can set the delay to '0'. That makes the port to be enabled instantaneously, hence the container can access the network immediately after the start. As previously posted, this is not what causes the network freeze with LXC. The problem is not related to the setfd option. It is caused by the bridge acquired a new MAC address. Libvirt already has a fix for this, and there is a patch in the works for the LXC tools. See my post about this four days ago at this URL, which includes a link to the patch and a link to a possible workaround: http://osdir.com/ml/lxc-chroot-linux-containers/2011-12/msg00029.html Thanks, Derek On 12/11/2011 02:21 PM, Daniel Lezcano wrote: On 12/08/2011 09:25 AM, Ulli Horlacher wrote: On Thu 2011-12-08 (07:39), Daniel Lezcano wrote: On 12/08/2011 12:38 AM, Joseph Heck wrote: I've been seeing a pause in the whole networking stack when starting and stopping LXC - it seems to be somewhat intermittent, but happens reasonably consistently the first time I start up the LXC. I'm using ubuntu 11.10, which is using LXC 0.7.5 I'm starting the container with lxc-start -d -n $CONTAINERNAME That could be the bridge configuration. Did you do 'brctl setfd br0 0' ? I have this in my /etc/network/interfaces (Ubuntu 10.04): auto br0 iface br0 inet static address 129.69.1.227 netmask 255.255.255.0 gateway 129.69.1.254 bridge_ports eth0 bridge_stp off bridge_maxwait 5 post-up /usr/sbin/brctl setfd br0 0 I have never noticed a network freeze and I really often start/stop LXC containers. Does this brctl setfd br0 0 prevent the freeze? I do not remember why I have added it :-} The setfd delay is used when there are several bridge setup on the system to detect if the packet are looping across the bridges and to learn the spawning tree control. AFAIR, a packet is transmitted on the new port and the bridge waits fordelay to see if the packet goes out of the bridge and came back from another port. During this delay, the port is not enabled. When there are only one bridge on the system or the bridges are not connected together, this option is pointless and we can set the delay to '0'. That makes the port to be enabled instantaneously, hence the container can access the network immediately after the start. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
On 08/12/11 19:39, Daniel Lezcano wrote: On 12/08/2011 12:38 AM, Joseph Heck wrote: I've been seeing a pause in the whole networking stack when starting and stopping LXC - it seems to be somewhat intermittent, but happens reasonably consistently the first time I start up the LXC. I'm using ubuntu 11.10, which is using LXC 0.7.5 I'm starting the container with lxc-start -d -n $CONTAINERNAME That could be the bridge configuration. Did you do 'brctl setfd br0 0' ? FWIW, I see the same issue following [1], which has 'brctl setfd br0 0'. [1] http://www.activestate.com/blog/2011/10/virtualization-ec2-cloud-using-lxc -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
On Thu, 2011-12-08 at 19:47 +1300, Gary Ballantyne wrote: On 08/12/11 19:39, Daniel Lezcano wrote: On 12/08/2011 12:38 AM, Joseph Heck wrote: I've been seeing a pause in the whole networking stack when starting and stopping LXC - it seems to be somewhat intermittent, but happens reasonably consistently the first time I start up the LXC. I'm using ubuntu 11.10, which is using LXC 0.7.5 I'm starting the container with lxc-start -d -n $CONTAINERNAME That could be the bridge configuration. Did you do 'brctl setfd br0 0' ? FWIW, I see the same issue following [1], which has 'brctl setfd br0 0'. [1] http://www.activestate.com/blog/2011/10/virtualization-ec2-cloud-using-lxc That just sets the bridge delay to zero (which could have an impact) but does not change the MAC address policy of assigning the lowest MAC address to the bridge itself. If the bridge mac address changes then any OTHER nodes or routers on the network have to fail out their ARP caches and re-ARP for the new MAC address, resulting in the delay. The only way to work around this problem is to assign very high MAC addresses to the nodes on the bridge to keep them from changing the MAC address of the bridge itself. Setting the locally administered (0200 in first word) bit in the MAC address helps but may not be sufficient (warning - DO NOT set the MULTICAST bit (0100 in first word)!). This was a design decision made many years ago in the Linux kernel for reasons I did not agree with and do not agree with but it is what it is and I doubt it will ever change. I think there's a patch going into the lxc-tools to avoid this problem. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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! signature.asc Description: This is a digitally signed message part -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
/I've been seeing a pause in the whole networking stack/...
It's because you use bridged networking. A Linux host bridge will
sometimes inherit a new MAC address, causing a ~4 second network
blackout while ARP tables refresh. This is inconvenient for
server-based virtualization platforms, which create and destroy new
bridges frequently. Libvirt has implemented a workaround for this
problem, and a patch for LXC has been submitted but is not yet published
(outside the development list).
See the proposed patch issue summary (and links to further details) at:
*http://article.gmane.org/gmane.linux.kernel.containers.lxc.devel/1184/match=*
In particular, there's a possible workaround described here (by
manually setting the mac address), in the SourceForge bug report:
http://sourceforge.net/tracker/index.php?func=detailaid=3411497group_id=163076atid=826303
The last post about this on the dev list was yesterday; Serge asked
for a bugfix to the patch before commiting it. I assume the patch
author (Christian S.) will make the requested bugfix and commit it,
hopefully for the next release of the LXC tools.
For now, I think your best option is to use the workaround linked
above, or else to manually apply the patch and compile it yourself.
Cheers,
Derek Simkowiak
http://derek.simkowiak.net
On 12/07/2011 03:38 PM, Joseph Heck wrote:
I've been seeing a pause in the whole networking stack when starting
and stopping LXC - it seems to be somewhat intermittent, but happens
reasonably consistently the first time I start up the LXC.
I'm using ubuntu 11.10, which is using LXC 0.7.5
I'm starting the container with lxc-start -d -n $CONTAINERNAME
The configuration file:
-
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br-v10
lxc.utsname = mysql
lxc.tty = 4
lxc.pts = 1024
lxc.rootfs = /var/lib/lxc/mysql/rootfs
lxc.mount = /var/lib/lxc/mysql/fstab
lxc.arch = amd64
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
# /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
#fuse
lxc.cgroup.devices.allow = c 10:229 rwm
# loopback
lxc.cgroup.devices.allow = b 7:* rwm
-
Any ideas why the host system would appear to totally pause networking
(ping doesn't respond, etc) for up to ~15 seconds when you're starting
or stopping a container?
I'm assuming it is some configuration mistake I've made, but I'm at a
loss to find out why it's happening.
-joe
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] seeing a network pause when starting and stopping LXCs - how do I stop this?
On 12/08/2011 12:38 AM, Joseph Heck wrote: I've been seeing a pause in the whole networking stack when starting and stopping LXC - it seems to be somewhat intermittent, but happens reasonably consistently the first time I start up the LXC. I'm using ubuntu 11.10, which is using LXC 0.7.5 I'm starting the container with lxc-start -d -n $CONTAINERNAME That could be the bridge configuration. Did you do 'brctl setfd br0 0' ? -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
