Bug 2222243

Summary: Kubemacpool does not handle properly interfaces update on running VMs
Product: Container Native Virtualization (CNV) Reporter: Ram Lavi <ralavi>
Component: NetworkingAssignee: Petr Horáček <phoracek>
Status: CLOSED WONTFIX QA Contact: Nir Rozen <nrozen>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.14.0   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-24 08:42:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ram Lavi 2023-07-12 11:51:47 UTC 
Description of problem:
When a running VM changes (adds/removes/updates) an interface, the changes will occur on the VMI only after reboot, but kubemacpool performs the changes immediately, hence creating an inherent diff between the macMap and what is actually consumed.

For example, If a running VM removes an interface, the MAC will be removed from the macMap, while the VMI is still using it, effectively exposing the MAC for duplication.


Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Create a running VM (=VM1) with 1 secondary interface, remember the MAC assigned.
2. Remove the secondary interface
3. Create another VM (=VM2), using the MAC assigned to VM-1.

Actual results:
Kubemacpool should reject VM2

Expected results:
Kubemacpool allows creation of VM2.

Additional info:
Since Kubemacpool assigned MACs consecutively, the issue should not manifest unless one of the 2 occurs:
1. Kubemacpool assigned all the free MACs in the range, and circles back to this MAC.
2. The user specifically chooses the MAC, overriding the consecutive MAC assignment.
Comment 1 Petr Horáček 2023-07-24 08:42:20 UTC 
Considering the conditions under which this issue may turn into a real problem, how much effort fixing this would require, and that ideas about alternatives for MAC allocation have been circulating lately, I'm marking this as WONTFIX. If anybody would disagree about the low severity, please reopen this BZ.