qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-8.2 v2 2/2] migration: Allow user to specify migration sw


From: Peter Xu
Subject: Re: [PATCH for-8.2 v2 2/2] migration: Allow user to specify migration switchover bandwidth
Date: Fri, 1 Sep 2023 10:40:55 -0400

On Fri, Sep 01, 2023 at 09:37:32AM +0100, Daniel P. Berrangé wrote:
> > Hi Peter. I'm curious if we specify max-switchover-bandwidth to 5Gbps over a
> > 10Gbps network, in the completion stage will it send the remaining data in 
> > 5Gbps
> > using downtime_limit time or in 10Gbps (saturate the network) using the
> > downtime_limit / 2 time? Seems this parameter won't rate limit the final 
> > stage:)
> 
> Effectively the mgmt app is telling QEMU to assume that this
> much bandwidth is available for use during switchover. If QEMU
> determines that, given this available bandwidth, the remaining
> data can be sent over the link within the downtime limit, it
> will perform the switchover. When sending this sitchover data,
> it will actually transmit the data at full line rate IIUC.

Right, currently it's only a way for QEMU to do more accurate calculations
on the switchover decision, while we always use full speed to transfer
during switchover.

The old name "available-bandwidth" might reflect more on that side (telling
qemu the available bandwidth QEMU can use only), but it might be unclear on
when the value will be used (only during making decisions for switchover).
So it seems there's no ideal name for it.

To be explicit, see migration_completion() has a call there with:

        migration_rate_set(RATE_LIMIT_DISABLED);

And this patch won't change that behavior (to use full line speed).

Interestingly this question let me also notice that when switchover for
postcopy we did it slightly different.  I believe postcopy also use line
speed because we put mostly everything needed in the package, and flushed
in qemu_savevm_send_packaged() with line speed too.

Thanks,

-- 
Peter Xu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]