Re: [PATCH v5 2/9] migration: Implement switchover ack logic

[Avihai Horon <avihaih@nvidia.com>]

On 08/06/2023 21:32, Alex Williamson wrote:
> External email: Use caution opening links or attachments
>
>
> On Tue, 6 Jun 2023 15:12:13 +0300
> Avihai Horon <avihaih@nvidia.com> wrote:
>> On 06/06/2023 1:06, Alex Williamson wrote:
>>> On Tue, 30 May 2023 17:48:14 +0300
>>> Avihai Horon <avihaih@nvidia.com> wrote:
>>>> @@ -2700,6 +2713,20 @@ static void migration_update_counters(MigrationState *s,
>>>>                                  bandwidth, s->threshold_size);
>>>>    }
>>>>
>>>> +static bool migration_can_switchover(MigrationState *s)
>>>> +{
>>>> +    if (!migrate_switchover_ack()) {
>>>> +        return true;
>>>> +    }
>>>> +
>>>> +    /* No reason to wait for switchover ACK if VM is stopped */
>>>> +    if (!runstate_is_running()) {
>>>> +        return true;
>>>> +    }
>>> Is it possible for QEMU to force the migration to continue regardless
>>> of receiving an ack from the target and is this the check that would
>>> allow that?
>> Yes. If you stop the source VM then migration will not wait for an ACK
>> to do the switchover.
>>
>>> It seems that we don't know the downtime allowed for the VM in any of
>>> this, nor do we know how much time the target device will require to
>>> generate an ack, but we could certainly have conditions where the
>>> priority is moving the VM from the source host regardless of the
>>> resulting downtime.
>> In such cases you can keep the switchover-ack capability off.
> How is that accomplished?

You simply don't enable the switchover-ack migration capability (it is 
disabled by default).

>
>>> Also does the return path requirement preclude offline migration or
>>> does the above again take care of that if we pause the VM for an
>>> offline migration (ex. save to and restore from file)?
>> I suppose that by offline migration you mean migration where you stop
>> the source VM first and then do migration?
> Yes.
>
>> If so, offline migration should work and in that case we don't care
>> about the ACK as downtime is not a concern.
>>
>> However, migrating to a file doesn't work with return-path, as you don't
>> have the destination side responding to the source via the return path.
>> For this reason, using return-path when migrating to a file doesn't make
>> sense.
> So we require return-path for switchover-ack, but switchover-ack is
> only required for pre-copy, therefore why do we require return-path for
> an offline migration?

We don't. See below.

>
> If there's a way to turn off switchover-ack capability, is there also a
> way to turn off return-path and therefore enable migration to file?

Yes.

By default, return-path and switchover-ack migration capabilities are 
disabled.

So for an offline migration nothing needs to be done -- you simply run 
migration.

For an online migration, you can choose to use switchover-ack or not.
If you want to use switchover-ack, then you need to enable return-path 
and switchover-ack capabilities first and then run migration.
If you don't want (e.g., you don't have a VFIO device assigned to the 
VM, so there is no reason to), then you keep return-path and 
switchover-ack capabilities disabled.

I hope that's clear now.

Thanks.