Display valid hosts to migrate

Registered by Facundo Maldonado

Currently all the available hypervisors are shown in destination host list of a live migration procedure. If the new host is not able to host the vm (i.e. different hypervisor) the error is thrown after the form is submitted.
It's desirable to filter out those hypervisors that are not able to host the migrated vm.

Use case 1: Different hypervisors
- given a deployment of 1 controller node and 5 compute nodes with 2 different hypervisors (two KVM, three Hyper-V).
- when a KVM instance is requested to be live migrated
- then in destination host list should only be displayed only one hypervisor (the other beside the current host).

Use case 2: Insuficient memory in destination host
- given a deployment of 2 compute nodes with same hypervisors but different amount of available memory
(i.e current host 2048MB, dest host 512Mb).
- when a KVM instance is requested to be live migrated
- then in destination host list should be empty.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Facundo Maldonado
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
David Lyle

Related branches

Sprints

Whiteboard

Great idea. I'm trying to make my mind whether it is desirable to:
1) see all the hosts and have a warning displayed for those hosts that are not suitable for the migration, or
2) (perhaps better) to make the cpu and hypervisor checks when the dialog is first created, and removing all not-suitable hosts from the list. This would naturally imply some sort of info message indicating the kind of limitations that exclude hosts from the list. I would go for this.

On one hand, this may end up in a redundant check, but on the other hand, it saves operational time, as the amount of errors due to host limitations is signifficantly reduced.

What do you think?
(--andres-buraschi)

---------------------------------------
I like option #1. Regarding use case #2, that's really something hard to control. The instance may fit anyways on the target-compute if having fewer memory but not actually required for that instance.
Maybe showing memory of target when selected may help, but no limiting the options. (--leandro-i-costantino)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.