Re: [PATCH v2 01/27] migration: Network Failover can't work with a paused guest

[Juan Quintela]

"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Dec 02, 2020 at 05:31:53AM -0500, Michael S. Tsirkin wrote:
>> On Wed, Dec 02, 2020 at 10:27:18AM +0000, Daniel P. Berrangé wrote:
>> > On Wed, Dec 02, 2020 at 05:13:18AM -0500, Michael S. Tsirkin wrote:
>> > > On Wed, Nov 18, 2020 at 09:37:22AM +0100, Juan Quintela wrote:
>> > > > If we have a paused guest, it can't unplug the network VF device, so
>> > > > we wait there forever.  Just change the code to give one error on that
>> > > > case.
>> > > > 
>> > > > Signed-off-by: Juan Quintela <quintela@redhat.com>
>> > > 
>> > > It's certainly possible but it's management that created
>> > > this situation after all - why do we bother to enforce
>> > > a policy? It is possible that management will unpause immediately
>> > > afterwards and everything will proceed smoothly.
>> > > 
>> > > Yes migration will not happen until guest is
>> > > unpaused but the same it true of e.g. a guest that is stuck
>> > > because of a bug.
>> > 
>> > That's pretty different behaviour from how migration normally handles
>> > a paused guest, which is that it is guaranteed to complete the migration
>> > in as short a time as network bandwidth allows.
>> > 
>> > Just ignoring the situation I think will lead to surprise apps / admins,
>> > because the person/entity invoking the migration is not likely to have
>> > checked wether this particular guest uses net failover or not before
>> > invoking - they'll just be expecting a paused migration to run fast and
>> > be guaranteed to complete.
>> > 
>> > Regards,
>> > Daniel
>> 
>> Okay I guess. But then shouldn't we handle the reverse situation too:
>> pausing guest after migration started but before device was
>> unplugged?
>> 
>
> Thinking of which, I have no idea how we'd handle it - fail
> pausing guest until migration is cancelled?
>
> All this seems heavy handed to me ...

This is the minimal fix that I can think of.

Further solution would be:
- Add a new migration parameter: migrate-paused
- change libvirt to use the new parameter if it exist
- in qemu, when we do start migration (but after we wait for the unplug
  device) paused the guest before starting migration and resume it after
  migration finish.

My understanding talking with Laine is that they use this functionality
by default for migration, saving, etc, i.e. it is not an isolated case.

Later, Juan.