It depends on the exact API call that is used to trigger the live migration. See [1] for the full API ref. But in short:
a) if ``host`` is provided in the API call with API microversion < 2.30 then scheduling will be skipped so the VM can be moved to an invalid host
b) if the ``host`` is provided in the API call with API microversion > 2.30 but < 2.67 and the ``force`` flag is set to True in the API request then the scheduling will be skipped so the VM can be moved to an invalid host
c) with API microversion >=2.30 < 2.67 and ``force`` False the scheduler should prevent the move to an invalid host
d) with API microversion >= 2.67 the ``force`` flag has been removed so the scheduler should always prevent the move to an invalid host.
I set this bug to Invalid as I assume that it was only a configuration issue. But feel free to set it back to New if you see scheduling problems in case of c) or d).
It depends on the exact API call that is used to trigger the live migration. See [1] for the full API ref. But in short:
a) if ``host`` is provided in the API call with API microversion < 2.30 then scheduling will be skipped so the VM can be moved to an invalid host
b) if the ``host`` is provided in the API call with API microversion > 2.30 but < 2.67 and the ``force`` flag is set to True in the API request then the scheduling will be skipped so the VM can be moved to an invalid host
c) with API microversion >=2.30 < 2.67 and ``force`` False the scheduler should prevent the move to an invalid host
d) with API microversion >= 2.67 the ``force`` flag has been removed so the scheduler should always prevent the move to an invalid host.
I set this bug to Invalid as I assume that it was only a configuration issue. But feel free to set it back to New if you see scheduling problems in case of c) or d).
[1] https:/ /docs.openstack .org/api- ref/compute/ ?expanded= live-migrate- server- os-migratelive- action- detail# live-migrate- server- os-migratelive- action