On Wed, 2013-06-05 at 07:40 -0500, Serge Hallyn wrote: > > Now my question, could not lxc (at boot) setup a fixed MAC addr for the > > host port?
> Yeah, given how bad this was for libvirt/qemu I'm surprised I've not seen > this happen in lxc - but I haven't, and noone else has reported it. Actually, this has come up on both the -devel list and here, the last time about a year and a half ago: On the -devel list... Subject: "Set high byte of mac addresses for host veth devices to 0xfe" It had a patch and referenced an open bug associated with it: random veth device MAC addresses cause bridge problems - ID: 3411497 https://sourceforge.net/tracker/index.php?func=detail&aid=3411497&group_id=163076&atid=826303 Christian Seiler included a proposed patch with his original posting to the -devel list back in November of 2011 where he set the high order byte to FE for a private "locally administered" MAC and some discussion ensued. After a couple of bug fixes, it was Acked it on 01/03/2012. It looks like it was applied. Right around line 3109 of src/lxc/conf.c: static int setup_private_host_hw_addr(char *veth1) ... ifr.ifr_hwaddr.sa_data[0] = 0xfe; err = ioctl(sockfd, SIOCSIFHWADDR, &ifr); close(sockfd); The bug is still open. Is this not working? What version did it go into? Someone should probably close that bug with an annotation. Looks to have been fixed in the 0.8.0 release. Seems to be working for me: ip addr ls ... 7: vethNoBHvN: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lxcbr0 state UP qlen 1000 link/ether fe:57:fa:34:4c:35 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc57:faff:fe34:4c35/64 scope link valid_lft forever preferred_lft forever 9: vethFmslRq: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lxcbr0 state UP qlen 1000 link/ether fe:a8:39:d6:c2:ee brd ff:ff:ff:ff:ff:ff inet6 fe80::fca8:39ff:fed6:c2ee/64 scope link valid_lft forever preferred_lft forever 11: vethhw7OZw: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master lxcbr0 state UP qlen 1000 link/ether fe:6b:8e:9d:f2:4f brd ff:ff:ff:ff:ff:ff inet6 fe80::fc6b:8eff:fe9d:f24f/64 scope link valid_lft forever preferred_lft forever So this shouldn't be happening if all of the host side MAC addresses are beginning with fe:. What version of the lxc tools is in play here? 0.7.5 dates back to August of 2011 and would have predated that fix. There's still a lot of distros with 0.7.5 still running around out there. It was also discussed here under these threads here in this forum from around the time time frame (about a year and a half ago): Subject: New LXC Creation Script: lxc-ubuntu-x Subject: seeing a network pause when starting and stopping LXCs - how do I stop this ? Yes, I had seen the bug show up. It causes the network to hang, but only for a half a minute or less as the ARP caches settle. If you have frequent starting and stopping of containers, it can be a PITA. My solution was to assign a high "vendor field" (top 3 bytes) using some safe vendor value that was above my host card vendor value. I seem to recall some discussion a few years ago about also trying to get an official MAC vendor code assigned to this project in one of the earlier discussions. I don't think that went anywhere and I'm having a problem finding it now. I do remember participating in that discussion as well. I seem to recall that it was decided not to do this even though some other projects such as VMware and, maybe, VirtualBox did chose this route. > Since you mention lxcbr0, I assume you're using ubuntu? Until we > (somehow - netcf?) implement a distro-agnostic lxc bridge upstream, this > is not an upstream issue, but an ubuntu package issue. > Have you actually seen a hang as a result of this? If so, then please > open a bug at https://bugs.launchpad.net/ubuntu/+source/lxc/+filebug > as it should be trivially fixable in /etc/init/lxc-net.conf. See above. Opened on 09/19/2011 and still open. You'll find I commented in the bug the same day. There's been other discussions in several forum, including including these. I believe it has also come up on the OpenVZ forum (and is where a lot of my earlier information originated) and has been mentioned in some of the kernel lists, probably the net list. There is a reason it works that way, mostly because the bridge has to have an address and it has to be an address on the bridge so the kernel can know what's on the bridge and what's foreign to the bridge in order to manage local routing. So, it has to pick something. But, if you delete an interface from the bridge and the bridge is using that address, it has to pick another. The rule the followed was to always choose the lowest. The only downside to assigning a static bridge address to the bridge is the chance of that associated interface ever being deleted from the bridge. I think you also loose that static state if certain bridge operations are performed by brctl, based on some discussions I saw. Certainly shouldn't be a problem in a server hosting environment where the host MAC is used for the bridge MAC and unlikely to ever be removed from the bridge. AFAICT... This should be fixed in the current releases and no longer a problem. > -serge 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
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
