Bug 1258960 - MigrateToServer can fail with destination host unknown (the underlying issue is deeper though).
Summary: MigrateToServer can fail with destination host unknown (the underlying issue ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ovirt-3.6.3
: 3.6.3.1
Assignee: Martin Sivák
QA Contact: Petr Matyáš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-01 15:30 UTC by Martin Sivák
Modified: 2016-02-18 11:06 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: A bug in and internal code inheritance. Consequence: When migrate to specific server was attempted with destination that was not available, the user did not get nice message. There was a confusing error instead. Fix: Bug fixed. Result: The user sees a nice error message with explanation when migration to explicit server is attempted and the destination is not available.
Clone Of:
Environment:
Last Closed: 2016-02-18 11:06:03 UTC
oVirt Team: SLA
rule-engine: ovirt-3.6.z+
mgoldboi: exception+
mgoldboi: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 45448 master ABANDONED scheduling: Clarify and fix the pinning/whitelist logic 2016-01-25 10:00:34 UTC
oVirt gerrit 52676 master MERGED Use the proper whitelist for MigrateVmCommand.canDoAction 2016-01-27 12:08:42 UTC
oVirt gerrit 52800 ovirt-engine-3.6 MERGED Use the proper whitelist for MigrateVmCommand.canDoAction 2016-01-28 08:01:50 UTC
oVirt gerrit 52848 refs/tags/ovirt-engine-3.6.3 ABANDONED Use the proper whitelist for MigrateVmCommand.canDoAction 2016-02-03 12:33:22 UTC
oVirt gerrit 53038 ovirt-engine-3.6.3 MERGED Use the proper whitelist for MigrateVmCommand.canDoAction 2016-02-03 13:16:33 UTC

Description Martin Sivák 2015-09-01 15:30:09 UTC
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..).

Comment 1 Doron Fediuck 2016-01-24 08:46:19 UTC
Martin,
IIRC this was resolved as a part of pin to multiple hosts.
Can you please verify?

Comment 2 Martin Sivák 2016-01-25 09:59:40 UTC
Actually, it is still a bug. I submitted a patch for it now - https://gerrit.ovirt.org/52676

Comment 3 Petr Matyáš 2016-02-11 10:16:58 UTC
Verified on 3.6.3-2


Note You need to log in before you can comment on or make changes to this bug.