+++ This bug was initially created as a clone of Bug #1558709 +++ 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.3.8-0.1.el7 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 --- Additional comment from Michal Skrivanek on 2018-03-21 02:28:06 EDT --- This should be reproducible with any migration --- Additional comment from Arik on 2018-05-08 08:51:09 EDT --- 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. --- Additional comment from Polina on 2018-05-31 11:12:07 EDT --- 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)
The bug is verified in version rhvm-4.2.4-0.1.el7.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/RHSA-2018:2071
BZ<2>Jira Resync
sync2jira