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:
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
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.