James Cammarata wrote: > On Fri, 13 Mar 2009 14:46:13 -0400, Michael DeHaan <[email protected]> > wrote: > >> Cobbler currently generates random MAC ranges for Xen in the assigned >> XenSource space. >> >> The problem is, from what I can tell, the qemu space (which we should be >> using is much smaller... >> >> macaddr[0] = 0x52; >> macaddr[1] = 0x54; >> macaddr[2] = 0x00; >> macaddr[3] = 0x12; >> macaddr[4] = 0x34; >> macaddr[5] = 0x56 + idx; >> >> This doesn't look very good for nice enterprisey KVM usage when we're >> managing DHCP and DNS and have hundreds of system records. >> >> Should we just continue using the Xen range? Or is there a "private" >> space we should be using? >> >> VMware requires it's own space, so what little VMware support we have in >> koan should be generating macs in those ranges. >> >> The idea is to make one XMLRPC function (we have one now) that instead >> of generating a random mac in the Xen range that does not yet conflict, >> generates one in the appropriate range that does not yet conflict. >> >> --Michael >> >> >> _______________________________________________ >> cobbler mailing list >> [email protected] >> https://fedorahosted.org/mailman/listinfo/cobbler >> > > According to http://standards.ieee.org/regauth/oui/oui.txt, there are > multiple private ranges available: > > 00-00-6C (hex) PRIVATE > 00006C (base 16) > > 00-01-01 (hex) PRIVATE > 000101 (base 16) > > 00-05-4F (hex) PRIVATE > 00054F (base 16) > > 00-05-78 (hex) PRIVATE > 000578 (base 16) > > etc... > > Any one of those we should be able to use. > >
I move that we just one of these, and let VMware have it's own restrictions about creating macs in the right set. It simplies things, and we'd like folks to use the OSS virt tech anyway. Thoughts? --Michael _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
