Bug 1485688 - [downstream clone - 4.1.7] [Pool] VMs are still created with duplicate MAC addresses after 4.0.7 upgrade
Summary: [downstream clone - 4.1.7] [Pool] VMs are still created with duplicate MAC ad...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.7
Hardware: x86_64
OS: Linux
high
urgent
Target Milestone: ovirt-4.1.7
: ---
Assignee: Martin Mucha
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1435485
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-27 08:07 UTC by rhev-integ
Modified: 2021-08-30 12:06 UTC (History)
17 users (show)

Fixed In Version: ovirt-engine-4.1.7.2
Doc Type: Bug Fix
Doc Text:
This update fixes a Manager issue that allowed duplicate MAC addresses even when duplicates are disallowed.
Clone Of: 1435485
Environment:
Last Closed: 2017-11-07 17:27:54 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2775081 0 None None None 2017-08-27 08:09:42 UTC
Red Hat Product Errata RHEA-2017:3138 0 normal SHIPPED_LIVE Red Hat Virtualization Manager (ovirt-engine) 4.1.7 2017-11-07 22:22:33 UTC
oVirt gerrit 75063 0 'None' 'MERGED' 'core: added logging message to MacPool' 2019-11-15 09:14:43 UTC
oVirt gerrit 76309 0 'None' 'MERGED' 'core: removing ''berserk'' forceAddMac method' 2019-11-15 09:14:43 UTC
oVirt gerrit 78132 0 'None' 'MERGED' 'core: fixes & simplifications in MoveMacs.java' 2019-11-15 09:14:43 UTC
oVirt gerrit 78146 0 'None' 'MERGED' 'core: removal of addForce method from cluster and DC update.' 2019-11-15 09:14:43 UTC
oVirt gerrit 78191 0 'None' 'MERGED' 'core: simplified parameters passed to VmInterfaceManager#add' 2019-11-15 09:14:43 UTC
oVirt gerrit 78192 0 'None' 'MERGED' 'core: remove forceAddMac from VmInterfaceManager,ImportVmCommandBase' 2019-11-15 09:14:43 UTC
oVirt gerrit 78193 0 'None' 'ABANDONED' 'core: add validation for duplicate macs when importing vm' 2019-11-15 09:14:44 UTC
oVirt gerrit 80450 0 'None' 'MERGED' 'core: when initializing MacPool also register in it nics in snapshots' 2019-11-15 09:14:44 UTC
oVirt gerrit 81566 0 'None' 'MERGED' 'core: fixes & simplifications in MoveMacs.java' 2019-11-15 09:14:44 UTC
oVirt gerrit 81567 0 'None' 'MERGED' 'core: removal of addForce method from cluster and DC update.' 2019-11-15 09:14:44 UTC
oVirt gerrit 81568 0 'None' 'MERGED' 'core: simplified parameters passed to VmInterfaceManager#add' 2019-11-15 09:14:44 UTC
oVirt gerrit 81569 0 'None' 'MERGED' 'core: remove forceAddMac from VmInterfaceManager,ImportVmCommandBase' 2019-11-15 09:14:45 UTC
oVirt gerrit 81570 0 'None' 'MERGED' 'core: removing ''berserk'' forceAddMac method' 2019-11-15 09:14:45 UTC
oVirt gerrit 81571 0 'None' 'MERGED' 'core: when initializing MacPool also register in it nics in snapshots' 2019-11-15 09:14:45 UTC
oVirt gerrit 81654 0 'None' 'MERGED' 'core: Prevent an init race between Beans and Backend' 2019-11-15 09:14:45 UTC

Description rhev-integ 2017-08-27 08:07:04 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1435485 +++
======================================================================

Description of problem:

We have a report of the following BZ not being fixed by it's 4.0.7 clone:
BZ1400043 - [Vm Pool] VMs are created with duplicate MAC addresses

First try of new version (4.0.7) resulted in 12 VMs with Duplicate MACs.

Version-Release number of selected component (if applicable):
rhevm-4.0.7.4-0.1.el7ev.noarch

(Originally by Germano Veit Michel)

Comment 7 rhev-integ 2017-08-27 08:07:40 UTC
Upgrade to 4.0.7 was from 4.0.6

(Originally by Germano Veit Michel)

Comment 8 rhev-integ 2017-08-27 08:07:47 UTC
One interesting thing is that they have 5-6 VM Pools. Could this increase the probability of hitting the bug? It seems very easy to hit in that environment.

(Originally by Germano Veit Michel)

Comment 10 rhev-integ 2017-08-27 08:07:59 UTC
A possible reproduction of the bug -

-Make sure the MacPool used by the dc doesn't allow duplicates.

1. Create a template with one vnic ('tmp1').
2. Create VmPool ('pool') from 'tmp1' with 2 vms ('pool-1' and 'pool-2'). Set the number of prestarted vms as 2.
3. Wait for the vms to be up.
4. Unplug the nic from vm 'pool-1' (lets call its current mac address 'x'). Change its mac address (new mac 'y'). Plug it back.
5. Add a vnic to vm 'pool-2' and set its mac address to 'x' (the old mac address of the vnic we uplugged and plugged).
6. Stop vm 'pool-1'.

Result - Both vms 'pool-1' and 'pool-2' have vnic with 'x' mac.


Explanation of what causes the bug - when stopping a vm that was started by the pool, the original snapshot (before the run) is restored. The macs of the vnics in the original snapshot are added to the mac pool using 'forceAdd'. It means that it ignores if the mac is already in the pool.
So if a mac in the original snapshot was taken by another vm. We will end up with duplicate macs.

(Originally by Alona Kaplan)

Comment 11 rhev-integ 2017-08-27 08:08:05 UTC
Latest logs after a new test (with the snapshot related errors fixed) do not show the problem anymore.

I believe we are hitting the scenario Alona described, as the MAC Pool was close to been exhausted therefore the chances of another VM taking the MAC of the original snapshot were quite high.

(Originally by Germano Veit Michel)

Comment 26 Michael Burman 2017-10-01 06:56:20 UTC
Verified on -  4.1.7.2-0.1.el7

Summary and results:

Stateless scenarios - PASS
Statefull/snapshot scenarios - PASS
Regression - All new regression bugs which has been caused by the fix for this report has been verified

Comment 28 errata-xmlrpc 2017-11-07 17:27:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:3138


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