Hi Ian > I think what you are doing is a bit odd. I would almost expect the > two identically named VMs to be failover for each other or something. > (If they share a hostname, do they share IPv6 and IPv4 addresses?) > Anyway, I'll assume you have a good reason...
It was more of an accident while doing some experiments. The whole thing really isn't meant to be used in production, and as Axel wrote earlier, it shouldn't and wouldn't be used as a default option. The way the MAC address is generated now and the reasons behind it make sense, I just wanted to add another option. > Firstly, IMO such an option is not harmful, but its use should be > discouraged. And it probably isn't the right answer for you. More > detailed explanation of why, below. > If you do generate a random MAC address, you should not generate it as > 48 random bits. Ethernet addresses have structure. See: > https://en.wikipedia.org/wiki/Mac_address > > I think at the very least you want to force the bits representing > "unicast" and "locally administered". > As only the last three octets are randomized and the standard Xen prefix remains the same, that shouldn't be an issue. > More on why not to do this: > > When used in automation, actual randomness can lead to random > failures. With a 46-bits-of-random MAC address, collisions start to > have nonnegligible probability at around 10^5 hosts (dependong on your > definition of "nonnegligible probability"). I'll trust your math because I'm too lazy to do it myself. With 24 random bits the probability of collisions will be even greater, but I hope an admin would think about the consequences of creating a domU with this optio. > If you want to perserver with the random generate idea I suggest the > addition of some caveat to the documentation. Agreed, documentation is always nice :) Regards, Pietro
