Created attachment 1410813 [details] logs and screenshot Description of problem:VM remains migrating forever with no Host (actually doesn't exist) after StopVmCommand fails to DestroyVDS Version-Release number of selected component (if applicable):rhv-release-4.2.2-6-001.noarch How reproducible:30% Steps to Reproduce: 1. Create affinity group under given cluster with {'name': 'affinity_enforcement_01', 'cluster_name': 'golden_env_mixed_1', 'vms_rule': {'enabled': False}, 'hosts_rule': {'positive': True, 'enforcing': True}, 'hosts': ['host_mixed_1'], 'vms': ['golden_env_mixed_virtio_1_0']} 2. RunOnce VM on host host_mixed_2 3. Wait for balancing to migrate the VM to the host_mixed_1. 4. Stop VM Actual result: sometimes this scenario ends with failure: 'org.ovirt.engine.core.bll.StopVmCommand' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to DestroyVDS, error = Virtual machine does not exist: {'vmId': '8114111b-dc24-4321-ab50-97f9b6fa1f6b'}, code = 1 (Failed with error noVM and code 1) ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-24) [vms_syncAction_0af46fa7-91b9-450c] EVENT_ID: USER_FAILED_STOP_VM(56), Failed to power off VM golden_env_mixed_virtio_1_0 (Host: host_mixed_2, User: admin@internal-authz). StopVmCommand] (default task-1) [vms_syncAction_2d443c2e-323e-4f67] Strange, according to the status 'MigratingTo' virtual machine '8114111b-dc24-4321-ab50-97f9b6fa1f6b' should be running in a host but it isn't. Expected: The VM is stopped with no errors logs and screenshot from UI are attached. Additional info: logs attached
This should be reproducible with any migration
Increase the severity as the user has no way of recovering from this state (VM in MigratingTo state while run_on_vds=NULL) without manually changing the database.
The bug is verified in version rhvm-4.2.4-0.1.el7.noarch The Steps according to the description and also automation test (TestEnforcementUnderHostAffinity01/02 classes in art/tests/rhevmtests/compute/sla/scheduler_tests/affinity_host_to_vm/affinity_host_to_vm_test.py)
Verified on ovirt-engine-4.3.0-0.4.master.20181231193012.git1f27a84.el7.noarch , vdsm-4.30.4-84.gita708fe4.el7.x86_64, libvirt-4.5.0-10.el7_6.3.x86_64. According to the description and also automation test run art/tests/rhevmtests/compute/sla/scheduler_tests/affinity_host_to_vm/affinity_host_to_vm_test.py.
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.0 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.