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.
Michael, you did not specify this explicitly, but I assume that in step 3 your VM was NOT running. right?
(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)
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
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.
Meni, please see comments 3 and 4#
(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.
I think we can verify this one and open a new bug about the new issue.
(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.
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