From: Nic J. F. <nfe...@ta...> - 2006-10-12 21:39:47
Attachments:
macserv.py
|
In my quest for the perfect network setup for a VM here is a piece of code that will allocate mac addresses from a pool. It's not that polished yet. So far you can only allocate based on the pool: fe:fd:12:aa:bb:cc where aa:bb:cc are the pool. However, that is 17 million different mac addresses so it's quite a lot. The code forms a REST webservice that accepts a POST to / and responds with a Location header indicating the new mac address. That mac address resources accept a DELETE to return the address to the pool. There are other options that define a client for the webservice. So the idea is that you do this on 'someserver': python macserv.py start and then later, when you want to start a VM: MACADDR=`python macserv.py clientpost someserver 8000` ./umlkernel ubda=fs eth0=tuntap,,$MACADDR ... and when the VM stops you do: python macserv.py clientdelete $MACADDR someserver 8000 This doesn't help you discover IP addresses (my other obsession) but it does deletgate control over macs to a central point. Obtaining a mac is such an infrequent operation (I have some apps where VMs are highly disposable but I still don't create macs that often) that a single server like this could easily handle a network of hundreds of machines. If anyone uses it let me know... my personal publishing systems (for code and such) are in a little bit of flux right now but it will go into source control eventually. -- Nic Ferrier http://www.tapsellferrier.co.uk for all your tapsell ferrier needs |
From: Ryan F. <ry...@fi...> - 2006-10-12 21:56:35
|
On 10/12/06, Nic James Ferrier <nfe...@ta...> wrote: > In my quest for the perfect network setup for a VM here is a piece of > code that will allocate mac addresses from a pool. I took a simpler route for pseudo-random non-varying mac address generation. Here you go: echo $(hostname)${UMID} | md5sum | \ awk '{print "00:08:93:"substr($1,1,2)":"substr($1,3,2)":"substr($1,5,2)}' This combines the umid you expect you assign to the instance with the hostname of the host. That way, the mac address will be the same each time it boots, but if I have 2 instances on different hosts both named "test", they won't clobber each other. For non-temporary instances, my homebrew system has a field for mac addresses. If it is empty, the above code is used. But for permanent instances, I create a completely random mac ahead of time: dd if=/dev/urandom bs=1k count=1 2>/dev/null | md5sum | \ awk '{print "00:08:93:"substr($1,1,2)":"substr($1,3,2)":"substr($1,5,2)}' Ryan |
From: Nic J. F. <nfe...@ta...> - 2006-10-12 22:19:57
|
"Ryan Finnie" <ry...@fi...> writes: > I took a simpler route for pseudo-random non-varying mac address > generation. Here you go: > > echo $(hostname)${UMID} | md5sum | \ > awk '{print "00:08:93:"substr($1,1,2)":"substr($1,3,2)":"substr($1,5,2)}' > > This combines the umid you expect you assign to the instance with the > hostname of the host. That way, the mac address will be the same each > time it boots, Not if it boots off a different host it won't. > For non-temporary instances, my homebrew system has a field for mac > addresses. If it is empty, the above code is used. But for permanent > instances, I create a completely random mac ahead of time: > > dd if=/dev/urandom bs=1k count=1 2>/dev/null | md5sum | \ > awk '{print > "00:08:93:"substr($1,1,2)":"substr($1,3,2)":"substr($1,5,2)}' This is a good system but incomplete - how do you ensure that you don't get duplicates? It's very difficult to know what hw addresses are on the network (ie: what macs are already taken) because not all hosts respond to broadcast pings (UMLs don't for example). -- Nic Ferrier http://www.tapsellferrier.co.uk for all your tapsell ferrier needs |
From: Ryan F. <ry...@fi...> - 2006-10-12 22:44:38
|
On 10/12/06, Nic James Ferrier <nfe...@ta...> wrote: > > This combines the umid you expect you assign to the instance with the > > hostname of the host. That way, the mac address will be the same each > > time it boots, > > Not if it boots off a different host it won't. You quoted everything in my message except the part where I essentially say ", unless it's on a different host". Besides, the automatic generation is only for temporary guests. If I intend for a guest to be permanent, I give it a static mac address. > This is a good system but incomplete - how do you ensure that you > don't get duplicates? It's very difficult to know what hw addresses > are on the network (ie: what macs are already taken) because not all > hosts respond to broadcast pings (UMLs don't for example). I am willing to bet against the 1 in 2^24 chance that there is an collision. (On a related note, we all do whenever we buy a new network card. Every time a nic manufacturer makes 16,777,216 cards, they should request a new OUI from the IEEE... but they don't always. Sometimes they just re-use an old OUI from years ago. So not all MAC addresses are globally unique; there's just a statistically tiny chance that the same 2 network cards appear on the same broadcast domain.) Ryan |
From: Nic J. F. <nfe...@ta...> - 2006-10-13 00:09:49
|
"Ryan Finnie" <ry...@fi...> writes: >> Not if it boots off a different host it won't. > > You quoted everything in my message except the part where I > essentially say ", unless it's on a different host". Apologies. I didn't mean to misrepresent you. > Besides, the automatic generation is only for temporary guests. If > I intend for a guest to be permanent, I give it a static mac > address. Gothca. I use the UML daemon for temporary guests. I run a dhcp server on the same tun as the UML daemon. But my server could help you eliminate the need to allocate (and coordinate) a static mac. > I am willing to bet against the 1 in 2^24 chance that there is an collision. > > (On a related note, we all do whenever we buy a new network card. > Every time a nic manufacturer makes 16,777,216 cards, they should > request a new OUI from the IEEE... but they don't always. Sometimes > they just re-use an old OUI from years ago. So not all MAC addresses > are globally unique; there's just a statistically tiny chance that the > same 2 network cards appear on the same broadcast domain.) I've actually seen this happen. About 10 years ago I was working at a UK government agency; we introduced a machine onto the net with the exact same mac as an existing machine. It was a problem that was extreemly difficult to discover at the time. I and a colleague had to go round looking at hub stats with a serial terminal (we had no centralized IP management consoles back then). -- Nic Ferrier http://www.tapsellferrier.co.uk for all your tapsell ferrier needs |