cold migration shouldn't spin up the vm ins a resize step

[Ian Kumlien]

disable a compute node

run migration on a vm not running, it will still have to start on that compute node to do resize...

next imagine that the compute node has gone down, why can't it just do a new scheduling and start running on a existing/not-disabled node?

this is with shared storage btw...

[melanie witt (melwitt)]

I had a quick-ish look through the code and did not see any explicit starting of the guest before migrating ... so far, it does not appear to be an intended behavior. I may have missed something though.

I will try to investigate more when I get a chance.

[Artom Lifshitz (notartom)]

Cold migration assumes that the source compute host is up (and I think has checks in the code for that). A cold migration will fail if the source compute host is actually down and not disabled. The correct thing to do in that case is an evacuation.

[Ian Kumlien (pomac)]

This is not my experience, the eventual practical solution was to modify the database directly.

The nodes in question failed, they were disabled but the vm:s that had once been on those nodes could not be migrated or started via the api:s.

Also, a vm that has been shelved will prefer to restart on the node that once had it even if there is no room. IMHO any non-running vm should be rescheduled directly if there is anything in the way.