Continuing my previous post on how to address possible MAC address conflicts with vSphere, now is the time to explain how this will work with XenServer.
XenServer as other virtualization solutions will cope with virtual interfaces MAC addresses management as VMs traffic will be sent onto the wire medium access layer either on bridged interfaces or virtual switching implementations. On any case, the ARP tables will need to know where to send back and forth all VM’s traffic.
XenServer as opposed to other vendors, will not have it’s own Organizationally Unique Identifier (OUI), manufacturers “burn-in” MAC addresses, in which the first three octets indicate which company manufactured the device. It generates MAC addresses automatically, being locally administered addresses.
XenServer generates a MAC addresses randomly based on the random seed parameter of the VM generated on VM creation (VM.other-config:mac-seed) and the device number of the virtual interface.
A combination of a MAC seed and a VIF number should result in the same MAC address. So, even upon VIF removal, a new generated interface will preserve the previous MAC address associated to the same previous device ID. Meaning, in case I remove virtual interface 1 and create a new virtual interface with device ID 1, I will get the same MAC address associated to the new virtual interface.
The MAC address seed is as 128 bit number that is randomly generated. That is then used to deterministically produce the MAC address of each VIF interface. From this seed, a 48 bit MAC is produced, only 46 bits of which can be unique (the other 2 bits specify that the interface is locally administered, and that it is unicast).
To put it another way, if you generate one seed, then generate another one, the probability of the second seed colliding with the first is 2^(82-128), or 1 in 2^46, which is roughly 1 in 10 trillion.
In a pool, when a new MAC is generated, we check that it’s not already in existence. That of course won’t help on a cross-pool deployment, but would be a small safety measure. Having dedicated networks or VLANs segregating your network pool-wise would certainly eliminate any very unlikely collision, where on a large XenDesktop deployment as for 40,000 desktops will require network segregation based on architecture definitions; either pool, blocks, hosts or network based criteria.
In a 40,000 desktops deployment, your chances of collision would increase to roughly 5 in 10 billion.
The probability of any two MAC addresses colliding in a 40,000 desktops deployment is approximately:
= 1 – e^-([40000^2]/2^47)
= 1.14 x 10^-5
In other words, there’s a one in a 100,000 chance that you’ll get a MAC address collision in a deployment of 40,000 hosts.
From field experience, I haven’t yet seen a production subnet with more than 4096 hosts IP addresses. This is due to network guys trying to minimize any possible major broadcast impact on switches, flooding them and bending them down to their knees.
So even on large deployments, where network segregation setup will be necessary, the likelihood of MAC collisions is roughly not an easy thing to occur. However, you always have the choice of setting up your own MAC addresses based on a Unique Identifier of your choice in case you really want to keep control and management of your medium access layer addresses.
There would be another post on best practices on Hyper-V. So stay tuned!