Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1533439

Summary:	[DR] - We should allow to send reset macs on register VM with a optional flag
Product:	[oVirt] ovirt-ansible-collection	Reporter:	Maor <mlipchuk>
Component:	disaster-recovery	Assignee:	Maor <mlipchuk>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	lsvaty, mlipchuk, ylavi
Target Milestone:	ovirt-4.2.2	Flags:	rule-engine: ovirt-4.2+ ylavi: exception+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	DR
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-14 15:10:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Maor 2018-01-11 10:59:50 UTC

Description of problem:
To avoid any mac pool mismatch register a VM with reset macs flag as true by default

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Allon Mureinik 2018-02-08 10:43:09 UTC

Maor, this PR is merged. Are we waiting for anything else, or should this be MODIFIED?

Comment 2 Elad 2018-05-13 11:05:56 UTC

VM registration is sent with reset MAC as default (written in /usr/share/ansible/roles/oVirt.disaster-recovery/defaults/main.yml).

Tested DR failover with a VM that its NIC MAC is not part of the target setup DC's MAC pool.
VM registration succeeded and its NIC got a MAC from the new DC's MAC pool.
Start VM succeeded.


Used:
ovirt-ansible-disaster-recovery-0.4-1.el7ev.noarch
ansible-2.5.2-1.el7ae.noarch
rhvm-4.2.3.3-0.1.el7.noarch

Comment 3 Sandro Bonazzola 2018-05-14 15:10:53 UTC

This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE.

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