From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Joao Martins <joao.m.martins@oracle.com>,
Elena Ufimtseva <elena.ufimtseva@oracle.com>,
qemu-devel@nongnu.org, eduardo@habkost.net,
marcel.apfelbaum@gmail.com, philmd@linaro.org,
wangyanan55@huawei.com, farosas@suse.de, eblake@redhat.com,
armbru@redhat.com
Subject: Re: [PATCH RFC 2/2] migration: abort on destination if switchover limit exceeded
Date: Tue, 25 Jun 2024 19:37:42 +0100 [thread overview]
Message-ID: <ZnsOdiHACtL90f3J@redhat.com> (raw)
In-Reply-To: <ZnrZ9W6WpvmDBpgv@x1n>
On Tue, Jun 25, 2024 at 10:53:41AM -0400, Peter Xu wrote:
> Then the question is how should we suggest the user to specify these two
> parameters.
>
> The cover letter used:
>
> migrate_set_parameter downtime-limit 300
> migrate_set_parameter switchover-limit 10
What this means is that in practice the total downtime limit
is 310 ms, however, expressing this as two parameters is
incredibly inflexible.
If the actual RAM transfer downtime only took 50 ms, then why
should the switchover downtime still be limited to 10ms, when
we've still got a budget of 250 ms that was unused.
IOW, if my VM tolerates a downtime of 310ms, then I want that
310ms spread across the RAM transfer downtime and switchover
downtime in *any* ratio. ALl that matters is the overall
completion time.
IMHO exposing 2 distinct parameters is horrible from a
usability POV.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-06-25 21:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 14:32 [PATCH RFC 0/2] migration: introduce strict SLA Elena Ufimtseva
2024-06-21 14:32 ` [PATCH RFC 1/2] migration: abort when switchover limit exceeded Elena Ufimtseva
2024-06-24 19:19 ` Peter Xu
2024-06-25 19:05 ` Daniel P. Berrangé
2024-06-21 14:32 ` [PATCH RFC 2/2] migration: abort on destination if " Elena Ufimtseva
2024-06-24 19:41 ` Peter Xu
2024-06-25 11:38 ` Joao Martins
2024-06-25 14:53 ` Peter Xu
2024-06-25 16:31 ` Joao Martins
2024-06-25 19:03 ` Peter Xu
2024-06-26 11:04 ` Joao Martins
2024-06-26 18:41 ` Peter Xu
2024-07-26 7:41 ` Elena Ufimtseva
2024-08-21 19:45 ` Peter Xu
2024-06-25 18:37 ` Daniel P. Berrangé [this message]
2024-06-26 11:29 ` Joao Martins
2024-06-26 11:34 ` Daniel P. Berrangé
2024-06-26 12:12 ` Joao Martins
2024-06-26 12:20 ` Daniel P. Berrangé
2024-06-25 19:12 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZnsOdiHACtL90f3J@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=elena.ufimtseva@oracle.com \
--cc=farosas@suse.de \
--cc=joao.m.martins@oracle.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).