Description of problem: The code contains a bug that reads all the candidate hosts back if they were filtered out because of none of the selected hosts passed the filtering stage. The if block around org.ovirt.engine.core.bll.scheduling.SchedulingManager line 391 is the culprit here. Version-Release number of selected component (if applicable): 3.6 snapshot as of today + master branch Reproducer: 1) Install three hosts 2) Create VMs A and B. 3) Create an affinity group containing A and B and set it to negative, enforcing 4) Start both VMs 5) Select VM A, Click Migrate and select the host where B is running as the target Actual results: The migration fails with destination host UNKNOWN. Expected results: Dialog telling me I cannot do the migration, because the host I selected has a VM from conflicting affinity group. Other info: - This does not happen when Run Once is used because Run Once uses the whitelist (org.ovirt.engine.core.bll.RunVmOnceCommand#getVdsWhiteList) together with destHostIdList. - MigrateToServer also uses the whitelist, but only for the inherited run method from MigrateVmCommand (which uses getVdsWhitelist to get it). - MigrateToServer's canDoAction is also inherited from MigrateVmCommand but uses getInitialHosts to fill the whitelist field of canSchedule... and the initialHosts argument is never used by anyone. - So the bad line in selectBestHost is actually causing harm only in the MigrateToServer case as all other cases never pass any hosts to SchedulingManager#selectBestHost that would not be also in the destHostIdList. Which renders the referenced if line ineffective (when the list is empty, add all elements from empty list back to the list..).
Martin, IIRC this was resolved as a part of pin to multiple hosts. Can you please verify?
Actually, it is still a bug. I submitted a patch for it now - https://gerrit.ovirt.org/52676
Verified on 3.6.3-2