[Lxc-users] Cannot start a container with a new MAC address

[Brian K. White]

On 8/27/2010 8:20 AM, Matto Fransen wrote:
> Hi,
>
> On Fri, Aug 27, 2010 at 11:27:16AM +0200, Sebastien Douche wrote:
>> I created a container with an interface. I stop it, I change the MAC
>> address, restart it:
>>
>> lxc-start: ioctl failure : Cannot assign requested address
>> lxc-start: failed to setup hw address for 'eth0'
>> lxc-start: failed to setup netdev
>> lxc-start: failed to setup the network for 'vsonde43'
>> lxc-start: failed to setup the container
>> lxc-start: invalid sequence number 1. expected 2
>>
>>
>> Have I Missed a step?
>
> This happens to me when I choose a 'wrong' mac-address.
>
> Example:
> lxc.network.hwaddr = 4a:59:43:49:79:bf works fine
> lxc.network.hwaddr = 4b:59:43:49:79:bfA results in a errormessage like above.
>
> Perhaps it is best to keep the first three pairs the same as in
> the LXC exampels.

Picking mac addresses is always going to require a little special care.
You can't just use anything.
Based on looking at what openvz and various other virtualization systems 
and/or their front-ends, and reading the rules for mac addresses, I do 
this to generate a valid mac from a desired ip address.
It uses only the mac address space reserved for local/virtual use and 
will never collide with any real nic, and will usually be unique 
automatically because even grocery-bagger-by-day admins are used to 
worrying about keeping ip's unique within a lan.
If the IP is 192.168.20.115:

$ printf "02:00:%x:%x:%x:%x" 192 168 20 115

Or as part of a script where you can enter the ip or read it out of a 
config file in normal format:

$ IP=192.168.20.115
$ HA=`printf "02:00:%x:%x:%x:%x" ${IP//./ }`
# echo $HA
02:00:c0:a8:14:73

macs are expected to be stable and ip's mutable, so it's a bit backwards 
to define a mac from an ip, but it's easier for most people in most 
cases that way. Everyone already is used to tracking ip's and making 
sure they're unique and recognizing immediately when there is an 
collision. Not so with mac's. I guess the downside will come when you 
generate a mac for a vm, then change that vm's ip, and then generate a 
new vm with the same IP that you just freed up. In that case the new vm 
will get the same mac as the old one.

The real answer of course is to track all your macs, virtual and real, 
in a spreadsheet or purpose designed app so you can sort and find dupes, 
prevent entering new dupes, and prevent entering invalid macs and merely 
unwise macs. An app might even be able to probe the network and try to 
determine if a proposed new mac is visible at the moment, and maybe even 
try to find past evidence in arp caches, syslog, etc.

-- 
bkw