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
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
