[PATCH] Add a check attribute on the mac address element

Michal Privoznik mprivozn at redhat.com
Mon Jul 13 12:08:59 UTC 2020

On 7/13/20 1:50 PM, Bastien Orivel wrote:
> On 13/07/2020 13:41, Michal Privoznik wrote:
>> On 7/13/20 11:44 AM, Bastien Orivel wrote:
>>> This is only used in the ESX driver where, when set to "no", it will
>>> ignore all the checks libvirt does about the origin of the MAC address
>>> (whether or not it's in a VMWare OUI) and forward the original one to
>>> the ESX server telling it not to check it either.
>>> This allows keeping a deterministic MAC address which can be useful for
>>> licensed software which might dislike changes.
>> While you get bonus points for remembering to document this change, it
>> should go into a separate patch, because keeping it in a single one
>> usually leads to conflicts on backports.
> Oops, didn't know about that, will split in a v2 once we resolved the
> other question.
>> But anyway, looking at virVMXFormatEthernet() - why don't we set all
>> MACs 'static'? Alternatively, we can use @mac_generated member to
>> determine whether the MAC address was provided by user or
>> automagically generated (and use static/generated addressType
>> accrodingly)?
> Mostly because I didn't want to break any existing script/setup that
> relies on the fact that libvirt would set the address type to what it is
> right now. For example, right now, providing a MAC address in the
> @00:0c:29@ range makes the ESXi server generate a new MAC address on
> define.

> I can imagine that some people outside always provide the same
> MAC address to define their machine and rely on libvirt/ESXi to generate
> a new one in that range for them.

This doesn't sound right. If they provide a MAC address we should 
guarantee it, if they don't provide address we should generate one, that 
suits hypervisor's needs.

Pino, you have more experience with ESX than I do, do you know whether 
we could do the switch to mark MAC addresses static/generated according 
to @mac_generated?


More information about the libvir-list mailing list