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

Bug 1546907

Summary:	External LUN disks mapping for register VM should be mapped using logical unit id instead of disk id
Product:	[oVirt] ovirt-engine	Reporter:	Maor <mlipchuk>
Component:	Backend.Core	Assignee:	Maor <mlipchuk>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.2.0	CC:	amureini, bugs, ebenahar, lveyde, tnisan
Target Milestone:	ovirt-4.2.2	Flags:	rule-engine: ovirt-4.2+
Target Release:	4.2.2.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-engine-4.2.2.1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-30 08:02:24 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-02-20 01:05:40 UTC

Description of problem:
Based on recent changes which was done in ovirt-ansible-DR the mapping
of external LUN disks is done using the logical unit id as the key element instead of the disk id.
This change should be aligned also in oVirt for the external LUN disks will be mapped properly.

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


How reproducible:
100%

Steps to Reproduce:
1. Try to import VM from the REST and add a mapping file containing external LUN disks
2.
3.

Actual results:
The registration will fail

Expected results:
The registration should succeed

Additional info:

Comment 2 Elad 2018-04-28 21:56:23 UTC

Direct LUN registration, is now being done with the LUN id.

Tested as part of DR failback scenario.

Generate mapping:

ansible-playbook dr_ovirt_setup.yml  --tags "generate_mapping" --extra-vars "site='https://rhv-dr1.scl.lab.tlv.redhat.com/ovirt-engine/api' username='admin@internal' password='123456' ca='/home/ebenahar/rhv-dr1-ca' var_file='/tmp/tmp.yml'" --ask-vault-pass -vvv


DR var mapping file direct LUN section:

# Mapping for external LUN disks
dr_lun_mappings:
- logical_unit_alias: vm-1_Disk3
  logical_unit_description: 056a
  wipe_after_delete: False
  shareable: False
  primary_logical_unit_id: 3514f0c5a5160056a
  primary_storage_type: iscsi
  primary_logical_unit_address: 10.35.146.129
  primary_logical_unit_port: 3260
  primary_logical_unit_portal: "1"
  primary_logical_unit_target: iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00
  # Fill in the following properties of the external LUN disk in the secondary site
  secondary_storage_type: iscsi
  secondary_logical_unit_id: 3514f0c5a5160056a
  secondary_logical_unit_address: 10.35.146.129
  secondary_logical_unit_port: 3260
  secondary_logical_unit_portal: "1"
  secondary_logical_unit_target: iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00


Fail over:

~/git/ansible/bin/ansible-playbook dr_ovirt_setup.yml  --tags "fail_over" --extra-vars "dr_target_host='secondary' dr_source_map='primary' vars='/tmp/tmp.yml'" --ask-vault-pass -vvv


===============
Result:
VM with direct LUN registration succeeded.

Used:
rhvm-4.2.3-0.1.el7.noarch
ovirt-ansible-disaster-recovery-0.3-1.el7ev.noarch

Comment 3 Sandro Bonazzola 2018-04-30 08:02:24 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.