9:35 a.m.
Hi all,
as part of the effort to enhance the migration convergence [1] we are proposing a
semaphore for incoming migrations [2] (similar to outgoing).
It's purpose is to protect the destination host from migration storms where too many
migrations are coming to it from different sources.
There are basically 3 ways how to do it (with pros/cons):
1: when the destination host refuses the migration, the source host tries it again later
(considering no migration will take forever after some time the migration will succeed to
start)
(+) pros:
(+) if the engine wants to migrate to a specific host (and only to the specific host
because user did pick it) than it only sends the command and it will happen (now or
later)
(+) will not interfere with engine re-runs since the migration will fail only when
there is a real issue
(+) will be consistent with the current outgoing semaphore (since the outgoing
semaphore also waits until has capacity and than starts the migration)
(+) VDSM is more autonomous because after the engine sends the command, VDSM will do it
even if engine disappears in this moment
(-) cons:
(-) re-try on VDSM is not common
(-) if the user does not pick a specific destination and he just wants to migrate the
machine out of the source, waiting on the destination to have capacity can be wasteful
since failing the migration and picking a different host could lead to better results
2: when the destination host refuses the migration, the source host returns to engine
"migration failed" and the engine will have to handle it somehow
(+) pros:
(+) simpler vdsm (try to migrate, if the destination does not have capacity, fail)
(+) lets the engine to pick a different destination host
(-) cons:
(-) not consistent with the outgoing migration semaphore (since if there are more VMs
waiting for outgoing migrations semaphore, the migration does not fail but waits)
(-) engine would have to handle different kinds of migration failed reasons
(-) VDSM is not autonomous - if the engine disappears the migration will not be
started
(-) Here I'm not sure about the consequences to scheduler but I think it would have
to be reworked to accommodate the different kinds of re-run. Any ideas from someone more
familiar with this? Roy, Martin?
3: (hybrid) - if the user picks a specific host, VDSM will use the first way, if the user
will not pick a specific host, VDSM will use the second option
(+) pros:
(+) works well with both cases when the intention is to migrate the machine TO A
SPECIFIC host and when the intention is just to migrate the VM out to ANY host
(-) cons:
(-) more complicated VDSM
(-) still will interfere with engine scheduling
(-) not consistent with current VDSM's outgoing semaphore
The currently proposed patch [2] is the first option.
Please note that we would also like to enrich the scheduler to be aware of max incoming
migrations limit thus preventing the storms, but it is a separate topic (no patches around
yet).
Here the question is that when the storm happens, how should VDSM protect itself.
Any ideas?
Thank you,
Tomas
[1]: www.ovirt.org/Features/Migration_Enhancements
[2]: https://gerrit.ovirt.org/#/c/45954/