Can you expand on that? What does "only been working" mean, and what do you mean by libvirt overriding the MAC?
As suggested by the code here: https://gitlab.com/libvirt/libvirt/-/blob/v10.0.0/src/qemu/qemu_interface.c#..., libvirt is overriding the MAC address for both the VM side interface and tap interface when `managed=yes`. So without libvirt, Nova would be setting the hardcoded mac address filled by networking-calico and thus resulting conflicts in mac address mapping, as multiple interface would have the same mac address.
Can you expand on "before (with `managed=yes`)" ? My understanding is that VIF_TYPE_TAP devices have never behaved successfully with `managed=yes`.
`managed=yes` was always the default and it works before the libvirt patch was introduced. Before, the function for creating the tap interface will not error out even if the tap interface exists before that patch. After that patch, libvirt will error out if the tap interface already exists. So in conclusion, we were always running `managed=yes` before the patch and it was working.
if that is the desired bevhior then we need to update the mech driver for calico to generate those two macs. nova should not have logic to do that transformation form fe to fa
Agreed. I was asking question to be clear where the bug report should land - and Nova is doing what it is supposed to do here, so I think the only thing we need to "fix" is to make sure networking-calico update the vif["details"] field with correct host-side TAP interface mac address, which we can still stay align with how libvirt does things, so it is easier to fix on existing cloud.