Description of problem: While importing the VM from the storage domain in the DR site and starting the same using ovirt-ansible-disaster-recovery role, the VM may fail to start with the error below. === 2018-11-26 02:02:53,670-05 WARN [org.ovirt.engine.core.bll.RunVmCommand] (default task-38) [05a1b0c9-a098-413f-9a93-9d086096c345] Validation of action 'RunVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_VM_LEASE 2018-11-26 02:02:53,670-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-38) [05a1b0c9-a098-413f-9a93-9d086096c345] EVENT_ID: USER_FAILED_RUN_VM(54), Failed to run VM ha_vm due to a failed validation: [Cannot run VM. Invalid VM lease. Please note that it may take few minutes to create the lease.] (User: admin@internal-authz). === The ansible is trying to start the VMs immediately after registering the same. However, by this time, the storage lease addition operation will be still going on for the VM and it will fail with the mentioned error. Version-Release number of selected component (if applicable): ovirt-ansible-roles-1.1.5-2.el7ev.noarch RHV 4.2.7 How reproducible: 100 % Steps to Reproduce: 1. Test the failover using ovirt-ansible-disaster-recovery role which is having HA VMs with the lease. 2. We can observe that these VMs will fail to start with the mentioned error. Actual results: HA VMs with the lease is failing to start during Active Passive DR failover. Expected results: HA VMs should start. Additional info:
Tested using: ovirt-engine-4.3.0.2-0.1.el7.noarch A running HA VM on the primary site failover (and start) successfully on the secondary site. Same result for failback. Moving to VERIFIED
In addition to comment #2: Tested using: ovirt-engine-4.3.0.2-0.1.el7.noarch ansible-2.7.6-1.el7ae.noarch ovirt-ansible-disaster-recovery-1.1.4-1.el7ev.noarch
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-2019:1064
sync2jira