We're unable to reproduce in a clean environment. Please provide a reproducer with its relevant log files in a clean environment. Please state the load (memory and cpu) and the destination machine.
(In reply to Doron Fediuck from comment #3) > We're unable to reproduce in a clean environment. > Please provide a reproducer with its relevant log files in a clean > environment. > Please state the load (memory and cpu) and the destination machine. Bug #1467063 contains everything you've asked, logs and everything. Reproduction steps also mentioned within the original bug, e.g. 1.Clean deployment of SHE over NFS+addition of one or two NFS data storage domains on pair of ha-hosts. 2.Ensure you're running SHE VM on SPM ha-host. 3.Migrate SHE-VM to none-SPM. 4.Migrate SHE-VM back to SPM ha-host and run monitor hosted-engine --vm-status from CLI. 5.During migration of SHE-VM to SPM you expected to catch the score penalty being dropped to by 50 points due to migration retry.
Re-setting needinfo per comment 3
Created attachment 1310516 [details] sosreport from the engine
Created attachment 1310519 [details] puma18
Created attachment 1310520 [details] puma19
Puma 18 was the SPM host.
According to the engine logs the HE VM maanaged to migrate to the SPM host: 2017-07-02 07:03:15,175-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVDSCommand] (DefaultQuartzScheduler5) [601534c9] START, FullListVDSCommand(HostName = puma18.scl.lab.tlv.redhat.com, FullListVDSCommandParameters:{runAsync='true', hostId='4962ca54-b194-40c5-99fd-01a402cc9ecd', vmIds='[5d543bb5-edfe-4414-a507-c06ea2d25368]'}), log id: 75ba1ffc
(In reply to Doron Fediuck from comment #10) > According to the engine logs the HE VM maanaged to migrate to the SPM host: > 2017-07-02 07:03:15,175-04 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVDSCommand] > (DefaultQuartzScheduler5) [601534c9] START, FullListVDSCommand(HostName = > puma18.scl.lab.tlv.redhat.com, > FullListVDSCommandParameters:{runAsync='true', > hostId='4962ca54-b194-40c5-99fd-01a402cc9ecd', > vmIds='[5d543bb5-edfe-4414-a507-c06ea2d25368]'}), log id: 75ba1ffc And it also failed in the middle of migration, so there was a re-try and thus due to that re-try score was dropped by 50 points, then it was raised back to 3400, once re-try succeeded. This bug is about re-try and what caused it.
Tested on cleanly deployed ovirt-hosted-engine-setup-2.2.1-0.0.master.20171206172737.gitd3001c8.el7.centos.noarch with ovirt-engine-appliance-4.2-20171210.1.el7.centos.noarch, over Gluster storage and with one NFS datat storage domain. Original issue was not reproduced, hence moving to verified. See also screencast attached.
https://drive.google.com/a/redhat.com/file/d/1u0Z74jwESdOKPJqqOsAO1rL7XDvY_7KE/view?usp=sharing
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.