Bug 1410440 - MAC addresses are in use after moving VM to another cluster and removing the vNIC doesn't clear it
Summary: MAC addresses are in use after moving VM to another cluster and removing the ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.1.0
Hardware: x86_64
OS: Linux
low
medium vote
Target Milestone: ovirt-4.1.2
: 4.1.2
Assignee: Martin Mucha
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-05 13:47 UTC by Michael Burman
Modified: 2017-05-23 08:15 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-23 08:15:40 UTC
oVirt Team: Network
rule-engine: ovirt-4.1+


Attachments (Terms of Use)
engine log (45 bytes, application/x-gzip)
2017-01-05 13:47 UTC, Michael Burman
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 71295 master MERGED core: refactorings related to update cluster flow. 2020-06-23 18:11:54 UTC
oVirt gerrit 71296 master MERGED core: renamed class MoveMacsOfUpdatedCluster. 2020-06-23 18:11:53 UTC
oVirt gerrit 71297 master MERGED core: added bulk methods to MacPool 2020-06-23 18:11:53 UTC
oVirt gerrit 71298 None MERGED core: when moving VM to another cluster, update its macs… 2020-06-23 18:11:53 UTC
oVirt gerrit 74026 ovirt-engine-4.1 MERGED core: refactorings related to update cluster flow. 2020-06-23 18:11:53 UTC
oVirt gerrit 74027 ovirt-engine-4.1 MERGED core: renamed class MoveMacsOfUpdatedCluster. 2020-06-23 18:11:53 UTC
oVirt gerrit 74028 ovirt-engine-4.1 MERGED core: added bulk methods to MacPool 2020-06-23 18:11:53 UTC

Description Michael Burman 2017-01-05 13:47:24 UTC
Created attachment 1237660 [details]
engine log

Description of problem:
MAC addresses are in use after moving VM to another cluster and removing the vNIC doesn't clear it.

Now when we moved to use the MAC pool range per cluster and we moving the VM to another cluster in the DC, the MAC addresses are not freed and remain as used MACs, which is the correct behavior. BUt, removing the vNIC from the VM isn't clearing the MAC and it is still remain as used in the origin cluster.
Only restart engine after remove vNIC release it.

Version-Release number of selected component (if applicable):
4.1.0-0.4.master.20170104122005.git51b1bcf.el7.centos.noarch

How reproducible:
100

Steps to Reproduce:
1. Create cluster1 with only 1 MAC address in the pool
2. Create VM with 1 vNIC in this cluster
3. Move VM to cluster2
4. Create new VM in cluster1 and try to add vNIC
5. Remove the vNIC from the original VM and try to add vNIC to the new VM
6. Restart engine and try add vNIC to original VM

Actual results:
step 4. Engine complain about no MAC addresses left in the pool. 
step 5. Engine complain about no MAC addresses left in the pool.
step 6. Succeed

Expected results:
Not sure, but i think that  if we remove the vnic from the original VM, the Mac should be released without engine restart.

Comment 1 Dan Kenigsberg 2017-01-23 14:14:52 UTC
Michael, you did not specify this explicitly, but I assume that in step 3 your VM was NOT running. right?

Comment 2 Michael Burman 2017-01-23 14:18:02 UTC
(In reply to Dan Kenigsberg from comment #1)
> Michael, you did not specify this explicitly, but I assume that in step 3
> your VM was NOT running. right?

Right, you can't move VM to another cluster while it is running)

Comment 3 Martin Mucha 2017-04-27 10:10:54 UTC
michal tested this and it seemed to him, that this bug is not fixed, because after updating VM by moving it to different cluster having different pool with different ranges, mac which VM use still cannot be used in original pool.


But I believe this bug is ok, as this is implication of different changes. here was merged in different commit validation,
which verifies, that if current pool disallows duplicates, then there isn't same mac used in any other pool(I'm not sure if this validation is correct, because it lacks symmetry).



You have clusterA with related poolA. There is VM with 1 mac, and pool is now full. If you add new nic to VM you will get error, that poolA is full. Now you move this vm to clusterB. Mac is deallocated from poolA and allocated in poolB, but you cannot add this very mac into new VM residing in clusterA, because this very mac is already used in different pool, poolB. So even if this mac is free in poolA you cannot use it there again, because it's used elsewhere.

Do we want this behavior? This situation is created by patch: c439d0913fb907f8ac6534f8825cc1d80dabf511

Comment 4 Michael Burman 2017-04-27 10:12:38 UTC
Steps to Reproduce:
1. Create cluster1 with only 1 MAC address in the pool
2. Create VM with 1 vNIC in this cluster
3. Move VM to cluster2
4. Create new VM in cluster1 and try to add vNIC

step 4. Engine complain about MAC address already in use.

MAC address should be free on cluster1 after step 3. Now it seems that MAC has released(as the error message is different), but engine trying re-assign the same MAC(although the VM is on different cluster now), which is considered in use now and it's still a problem, as we can't add new vINCs to the VM.

Not sure it can be verified, let's discuss it.

Comment 5 Michael Burman 2017-04-27 10:13:36 UTC
Meni, please see comments 3 and 4#

Comment 6 Dan Kenigsberg 2017-04-27 10:40:02 UTC
(In reply to Martin Mucha from comment #3)

> here was merged in different commit validation,
> which verifies, that if current pool disallows duplicates, then there isn't
> same mac used in any other pool(I'm not sure if this validation is correct,
> because it lacks symmetry).

Me to. can you point us to the commit that introduces this behavior? I find it surprising that one cluster cares about anything but its single mac pool.

Comment 7 Meni Yakove 2017-04-27 14:03:45 UTC
I think we can verify this one and open a new bug about the new issue.

Comment 8 Martin Mucha 2017-04-27 14:21:52 UTC
(In reply to Dan Kenigsberg from comment #6)
> (In reply to Martin Mucha from comment #3)
> 
> > here was merged in different commit validation,
> > which verifies, that if current pool disallows duplicates, then there isn't
> > same mac used in any other pool(I'm not sure if this validation is correct,
> > because it lacks symmetry).
> 
> Me to. can you point us to the commit that introduces this behavior? I find
> it surprising that one cluster cares about anything but its single mac pool.

pach id in comment #3
gerrit: https://gerrit.ovirt.org/#/c/69618/
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1404130

we also have opened bug(s), which complaints about having same macs on same network, not sure if this cannot kinda help that situation (if some network spans more clusters)

Fix will be easy, but I currently don't know what we want. Please help me with that.

Comment 9 Michael Burman 2017-04-30 12:31:31 UTC
Based on all the previous comments above^^, i'm setting this report as verified and new bug has been reported for the new issue. 
See BZ - 1446913

Verified on - 4.1.2-0.1.el7


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