mlsorensen commented on PR #7878:
URL: https://github.com/apache/cloudstack/pull/7878#issuecomment-1684058897
> @mlsorensen have you considered an out of bounds migration scenario? this
might give an undesirable effect if the VM was started on another host, would
it?.
Good point. Whatever is happening in this code during out of band migration,
this doesn't change that. I don't know if anyone is looking at the message bus
that is currently already publishing, or if there are existing issues with how
it handles the VM state, but maybe publishing to the event system will make it
more obvious if there's an existing bug here.
I don't know that anyone using KVM at least is doing out of band migration
because the tools aren't great for that, and in many cases simply not possible
due to storage and network plugins needing to run and make storage/network
accessible on the host. Perhaps useful for someone using VMware, where there is
a separate system to manage VMs independently. I don't know that a test via KVM
is going to really exercise it in the same way the VMware integration does.
Worst case, we see an event for VMware users indicating the VM was removed
from its host out of band, but we aren't making a change to how the VM state is
handled and synced up for these kinds of migrations.
With the existing code what I see is during live migration, both source and
destination hypervisors send a report that the VM is powered on, and both
systems are updating the VM power state when they send pings. Thus the VM's
`power_host` flip flops back and forth, but the `host_id` is already set to the
new host. When the VM finally migrates, it doesn't complain that the VM is
powered off because the host complaining the VM is gone is not matching the
`host_id`. With out of band, we need to make sure we understand how the
`host_id` will get updated and that this is compatible.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
