Peter Xu <[email protected]> wrote: > Migration bandwidth is a very important value to live migration. It's > because it's one of the major factors that we'll make decision on when to > switchover to destination in a precopy process. > > This value is currently estimated by QEMU during the whole live migration > process by monitoring how fast we were sending the data. This can be the > most accurate bandwidth if in the ideal world, where we're always feeding > unlimited data to the migration channel, and then it'll be limited to the > bandwidth that is available. > > However in reality it may be very different, e.g., over a 10Gbps network we > can see query-migrate showing migration bandwidth of only a few tens of > MB/s just because there are plenty of other things the migration thread > might be doing. For example, the migration thread can be busy scanning > zero pages, or it can be fetching dirty bitmap from other external dirty > sources (like vhost or KVM). It means we may not be pushing data as much > as possible to migration channel, so the bandwidth estimated from "how many > data we sent in the channel" can be dramatically inaccurate sometimes. > > With that, the decision to switchover will be affected, by assuming that we > may not be able to switchover at all with such a low bandwidth, but in > reality we can. > > The migration may not even converge at all with the downtime specified, > with that wrong estimation of bandwidth, keeping iterations forever with a > low estimation of bandwidth. > > The issue is QEMU itself may not be able to avoid those uncertainties on > measuing the real "available migration bandwidth". At least not something > I can think of so far. > > One way to fix this is when the user is fully aware of the available > bandwidth, then we can allow the user to help providing an accurate value. > > For example, if the user has a dedicated channel of 10Gbps for migration > for this specific VM, the user can specify this bandwidth so QEMU can > always do the calculation based on this fact, trusting the user as long as > specified. It may not be the exact bandwidth when switching over (in which > case qemu will push migration data as fast as possible), but much better > than QEMU trying to wildly guess, especially when very wrong. > > A new parameter "avail-switchover-bandwidth" is introduced just for this. > So when the user specified this parameter, instead of trusting the > estimated value from QEMU itself (based on the QEMUFile send speed), it > trusts the user more by using this value to decide when to switchover, > assuming that we'll have such bandwidth available then. > > Note that specifying this value will not throttle the bandwidth for > switchover yet, so QEMU will always use the full bandwidth possible for > sending switchover data, assuming that should always be the most important > way to use the network at that time. > > This can resolve issues like "unconvergence migration" which is caused by > hilarious low "migration bandwidth" detected for whatever reason. > > Reported-by: Zhiyi Guo <[email protected]> > Reviewed-by: Joao Martins <[email protected]> > Signed-off-by: Peter Xu <[email protected]>
Reviewed-by: Juan Quintela <[email protected]> > diff --git a/migration/options.h b/migration/options.h > index 045e2a41a2..93ee938ab8 100644 > --- a/migration/options.h > +++ b/migration/options.h > @@ -80,6 +80,7 @@ int migrate_decompress_threads(void); > uint64_t migrate_downtime_limit(void); > uint8_t migrate_max_cpu_throttle(void); > uint64_t migrate_max_bandwidth(void); > +uint64_t migrate_avail_switchover_bandwidth(void); > uint64_t migrate_max_postcopy_bandwidth(void); > int migrate_multifd_channels(void); > MultiFDCompression migrate_multifd_compression(void); This list of functions is alphabetically sorted, doing that during merge.
