Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1685088 - multiple VMs can be created with same macAddress
Summary: multiple VMs can be created with same macAddress
Keywords:
Status: NEW
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Networking
Version: 1.4
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: 2.1
Assignee: Sebastian Scheinkman
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-04 10:42 UTC by Vatsal Parekh
Modified: 2019-04-16 14:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-05 13:57:27 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Vatsal Parekh 2019-03-04 10:42:27 UTC
Description of problem:
Multiple VMs can be created with passing the same macAddress like this from VM object
```
          Interfaces:
            Boot Order:  1
            Bridge:
            Mac Address:  0a:58:0a:82:00:18
            Name:         default
```

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

How reproducible:


Steps to Reproduce:
1.Create multiple VMs with diff name but with same mac address
2.
3.

Actual results:
Successfully creates multiple VMs with showing same mac address 

Expected results:
Kubevirt should have a validator to not let this happen

Additional info:

Comment 1 Dan Kenigsberg 2019-03-04 13:25:58 UTC
I am not sure that we should handle this bug.

We plan to have a MAC pool https://github.com/SchSeba/kubemacpool so that users would not have to invent.

However, if a user really really want to specify a MAC address may have a good reason to do so (e.g the guest requires this specific address, and the user KNOWS that the two interfaces are on different networks)

Comment 2 Federico Simoncelli 2019-03-05 09:10:14 UTC
(In reply to Dan Kenigsberg from comment #1)
> I am not sure that we should handle this bug.
> 
> We plan to have a MAC pool https://github.com/SchSeba/kubemacpool so that
> users would not have to invent.
> 
> However, if a user really really want to specify a MAC address may have a
> good reason to do so (e.g the guest requires this specific address, and the
> user KNOWS that the two interfaces are on different networks)

Would it make sense to have a webhook validation even later (with MAC pool) to make sure there are no duplicates?

Comment 3 Dan Kenigsberg 2019-03-05 10:13:51 UTC
It is possible to do, no doubt about that.

I just think that it might be wrong for a certain use case, and I prefer the rhv behavior:  mac is usually generated by the system, and is never dup. On the rare case a customer wants to set a Mac, manually, allow her to shoot herself in the foot.

Comment 4 Federico Simoncelli 2019-03-05 11:23:40 UTC
(In reply to Dan Kenigsberg from comment #3)
> It is possible to do, no doubt about that.
> 
> I just think that it might be wrong for a certain use case, and I prefer the
> rhv behavior:  mac is usually generated by the system, and is never dup. On
> the rare case a customer wants to set a Mac, manually, allow her to shoot
> herself in the foot.

Is there a dependency on the configuration of a mac range pool then?
So that you know you shouldn't allocate from the automatic mac pool range?

Comment 6 Dan Kenigsberg 2019-03-05 13:57:27 UTC
I am closing this bug, since I believe that we should not add a validation for manually-fed MAC addresses.
We do have to have a MAC pool to make sure that manual feeding is very rare.

Comment 7 Franck Baudin 2019-03-05 14:44:31 UTC
Re-Open: we want to guide users in a simple workflow, and help mainstream users. Mainstream users don't need to use duplicated MAC addresses, only advanced users for testing purpose or at some point NFV. But we should prioritise mainstream users for CNV, knowing that advanced users are likely to come with their own CNI and even their own MAC-Pool.


Note You need to log in before you can comment on or make changes to this bug.