t;
> > Remove:
> > - RDMA handling from migration
> > - dependencies on libibumad, libibverbs and librdmacm
> >
> > Keep the RAM_SAVE_FLAG_HOOK definition since it might appears
> > in old migration streams.
> >
> > Cc: Peter Xu
> > Cc: Li Zh
can keep that for two more
releases. Hopefully that can ring a louder alarm to the current users with
such warnings, so that people can either stick with old binaries, or invest
developer/test resources to the community.
Thanks,
--
Peter Xu
___
Devel mailing
, but my understanding is
it's pretty easy to fetch modern NIC to outperform RDMAs, then it may make
little sense to maintain multiple protocols, considering RDMA migration
code is so special so that it has the most custom code comparing to other
protocols.
Thanks,
--
Peter Xu
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
On Mon, Apr 08, 2024 at 04:07:20PM +0200, Jinpu Wang wrote:
> Hi Peter,
Jinpu,
Thanks for joining the discussion.
>
> On Tue, Apr 2, 2024 at 11:24 PM Peter Xu wrote:
> >
> > On Mon, Apr 01, 2024 at 11:26:25PM +0200, Yu Zhang wrote:
> > > Hello Peter und Zhjian,
On Tue, Apr 09, 2024 at 09:32:46AM +0200, Jinpu Wang wrote:
> Hi Peter,
>
> On Mon, Apr 8, 2024 at 6:18 PM Peter Xu wrote:
> >
> > On Mon, Apr 08, 2024 at 04:07:20PM +0200, Jinpu Wang wrote:
> > > Hi Peter,
> >
> > Jinpu,
> >
> > Thanks for
On Wed, Apr 10, 2024 at 02:28:59AM +, Zhijian Li (Fujitsu) via wrote:
>
>
> on 4/10/2024 3:46 AM, Peter Xu wrote:
>
> >> Is there document/link about the unittest/CI for migration tests, Why
> >> are those tests missing?
> >> Is it hard or very sp
On Wed, Apr 10, 2024 at 09:49:15AM -0400, Peter Xu wrote:
> On Wed, Apr 10, 2024 at 02:28:59AM +, Zhijian Li (Fujitsu) via wrote:
> >
> >
> > on 4/10/2024 3:46 AM, Peter Xu wrote:
> >
> > >> Is there document/link about the unittest/CI for migration te
h even if ready. I think we need people
that understand these stuff well enough, have dedicated time and look after
it.
Thanks,
--
Peter Xu
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
_https://enterprise-support.nvidia.com/s/article/howto-configure-soft-roce__;!!GjvTz_vk!VEqNfg3Kdf58Oh1FkGL6ErDLfvUXZXPwMTaXizuIQeIgJiywPzuwbqx8wM0KUsyopw_EYQxWvGHE3ig$
> >
> > Thanks and best regards!
> >
> > On Thu, Apr 11, 2024 at 4:20 PM Peter Xu wrote:
> > &g
ities");
> -return false;
> -}
> -if (!migrate_cap_set(MIGRATION_CAPABILITY_BLOCK, true, errp)) {
> -return false;
> -}
> -s->must_remove_block_options = true;
> -}
> +s->must_remove_block
On Mon, Apr 29, 2024 at 02:18:57PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 10:14:05AM -0300, Fabiano Rosas wrote:
> >> @@ -2003,21 +1997,7 @@ static bool migrate_prepare(MigrationState *s, bool
reduce ambiguity, the ``fd:`` URI
> +usage of providing a file descriptor to a plain file has been
> +deprecated in favor of explicitly using the ``file:`` URI with the
> +file descriptor being passed as an ``fdset``. Refer to the ``add-fd``
> +command documen
On Mon, Apr 29, 2024 at 03:35:02PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Mon, Apr 29, 2024 at 02:18:57PM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Fri, Apr 26, 2024 at 10:14:05AM -0300, Fabiano Rosas wrote:
On Mon, Apr 29, 2024 at 03:47:39PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Fri, Apr 26, 2024 at 10:14:08AM -0300, Fabiano Rosas wrote:
> >> The fd: URI can currently trigger two different types of migration, a
> >> TCP migration using sockets and
Reviewed-by: Markus Armbruster
> Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
--
Peter Xu
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
mand
> option is deprecated.").
>
> Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
--
Peter Xu
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
; compression code has been deprecated in 8.2 and now is time to remove
> it.
>
> Deprecation commit 864128df46 ("migration: Deprecate old compression
> method").
>
> Signed-off-by: Fabiano Rosas
Reviewed-by: Peter Xu
--
Peter Xu
_
On Tue, Apr 30, 2024 at 09:00:49AM +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 30, 2024 at 09:15:03AM +0200, Markus Armbruster wrote:
> > Peter Xu writes:
> >
> > > On Mon, Apr 29, 2024 at 08:08:10AM -0500, Michael Galaxy wrote:
> > >> Hi All
b' option from migrate commands
> migration: Remove block migration
> migration: Remove non-multifd compression
> migration: Deprecate fd: for file migration
Reviewed-by: Peter Xu
--
Peter Xu
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org
On Wed, May 01, 2024 at 04:59:38PM +0100, Daniel P. Berrangé wrote:
> On Wed, May 01, 2024 at 11:31:13AM -0400, Peter Xu wrote:
> > What I worry more is whether this is really what we want to keep rdma in
> > qemu, and that's also why I was trying to request for some ser
; migration",
> > > + "\n\t\t\t -r to resume a paused migration",
> > > .cmd= hmp_migrate,
> > > },
> > >
> > >
> > > SRST
> > > -``migrate [-d] [-b]`` *uri*
> >
ou want I can try to see how we can
test together. And btw I don't think we need a cluster, IIUC we simply
need two hosts, 100G nic on both sides? IOW, it seems to me we only need
two cards just for experiments, systems that can drive the cards, and a
wire supporting 100G?
>
> >
>
and easy task.
It'll be good to know whether Dan's suggestion would work first, without
rewritting everything yet so far. Not sure whether some perf test could
help with the rsocket APIs even without QEMU's involvements (or looking for
test data supporting / invalidate s
7;s about help us make a decision
on whether to drop rdma, iow, even if rdma performs well, the community
still has the right to drop it if nobody can actively work and maintain it.
It's just that if nics can perform as good it's more a reason to drop,
unless companies can help to provide
dma code as Dan
mentioned?
Thanks,
>
> On Fri, May 3, 2024 at 4:33 PM Peter Xu wrote:
> >
> > On Fri, May 03, 2024 at 08:40:03AM +0200, Jinpu Wang wrote:
> > > I had a brief check in the rsocket changelog, there seems some
> > > improvement over time,
> >
On Tue, May 07, 2024 at 01:50:43AM +, Gonglei (Arei) wrote:
> Hello,
>
> > -Original Message-
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Monday, May 6, 2024 11:18 PM
> > To: Gonglei (Arei)
> > Cc: Daniel P. Berrangé ; Markus Armbru
ocs when a
rdma document page is ready.
Chuan, please check the whole thread discussion, it may help to understand
what we are looking for on rdma migrations [1]. Meanwhile please feel free
to sync with Jinpu's team and see how to move forward with such a project.
[1] https://lore.kernel.org/qe
NICs are powerful now, but again as I mentioned I don't
think it's a reason we need to deprecate rdma, especially if QEMU's rdma
migration has the chance to be refactored using rsocket.
Is there anyone who started looking into that direction? Would it make
sense we start some PoC now?
Thanks,
--
Peter Xu
On Tue, May 28, 2024 at 09:06:04AM +, Gonglei (Arei) wrote:
> Hi Peter,
>
> > -Original Message-
> > From: Peter Xu [mailto:pet...@redhat.com]
> > Sent: Wednesday, May 22, 2024 6:15 AM
> > To: Yu Zhang
> > Cc: Michael Galaxy ; Jinpu Wang
> >
RC we don't yet have a major blocker to do that, but I didn't
further check either. I've put that issue aside just to see whether this
may or may not make sense.
Thanks,
--
Peter Xu
ination and it can pull it.
> That might work nicely for postcopy.
I'm not sure whether it'll still be a problem if rdma recv side is based on
zero-copy. It would be a matter of whether atomicity can be guaranteed so
that we don't want the guest vcpus to see a partially copied page during
on-flight DMAs. UFFDIO_COPY (or friend) is currently the only solution for
that.
Thanks,
--
Peter Xu
On Wed, Jun 05, 2024 at 10:10:57AM -0400, Peter Xu wrote:
> > e) Someone made a good suggestion (sorry can't remember who) - that the
> > RDMA migration structure was the wrong way around - it should be the
> > destination which initiates an RDMA read,
> Yes, but even ignoring that (and the UFFDIO_CONTINUE idea you mention), if
> the destination can issue an RDMA read itself, it doesn't need to send
> messages
> to the source to ask for a page fetch; it just goes and grabs it itself,
> that's got to be good for latency.
Oh, that's pretty internal stuff of rdma to me and beyond my knowledge..
but from what I can tell it sounds very reasonable indeed!
Thanks!
--
Peter Xu
on switchover? Peter, can
> > you add the details, please?
>
> Thanks - @Peter, if you have additional info on that, would love to know
> what the non-VFIO downsides are here.
So far, VFIO is the only one who will register this "ACK needed" hook.
When nobody registers with it, the ACK will be sent upfront of a migration
when return path is established. That happens at the very beginning of a
migration, and that ACK will be completely meaningless in that case.
Said that, it may not be too bad either to have that meaningless ACK, if
that will simply Libvirt. That only happens once per migration, and after
sent once it should work exactly the same as when switchover-ack not enabled.
Thanks,
--
Peter Xu
gt; "size": 512
> },
>
> vs.
>
> {
> "field": "vendor_data",
> "version_id": 0,
> "field_exists": false,
> "num": 512,
> "size": 1
> },
>
> The unused field was introduced in 2016 so there's no chance of
> migrating a QEMU that old to/from 9.1.
What happens if an old qemu 9.0 sends rubbish here to a new QEMU, while the
new QEMU would consider it meaningful data?
--
Peter Xu
at "static const uint8_t buf[1024]" is there at least since
2017. So yes, probably always sending zeros.
Nothing I can think of otherwise indeed, if we want to trust that nothing
will migrate before 2016. It's just that we may want to know how that
"2016" is justified to be safe if we would like to allow that in the
future.
One thing _could_ be that "rule of thumb" is we plan to obsolete machines
with 6 years, so anything "UNUSED" older than 6 years can be over-written?
--
Peter Xu
stion would be: are we requesting an OpenStack cluster to
always upgrade QEMU with +1 versions, otherwise migration will fail?
--
Peter Xu
On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Wed, Jul 10, 2024 at 01:21:51PM -0300, Fabiano Rosas wrote:
> >> It's not about trust, we simply don't support migrations other than
> >> n->n+1 and (maybe)
On Wed, Jul 10, 2024 at 06:38:26PM -0300, Fabiano Rosas wrote:
> Peter Xu writes:
>
> > On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote:
> >> Peter Xu writes:
> >>
> >> > On Wed, Jul 10, 2024 at 01:21:51PM -0300, Fabiano Rosas wrote:
>
e can stick
with that (and only if people would like to reuse a field and ask; that's
after all not required..). If more than that I doubt whether we should
spend time working on covering all the fields.
--
Peter Xu
l simply be gone.. See configuration_post_load(),
where it'll throw an error upfront when machine type mismatched.
--
Peter Xu
On Fri, Jul 26, 2024 at 03:25:31AM -0400, Michael S. Tsirkin wrote:
> On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote:
> > On 26/07/2024 08.08, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 06:18:20PM -0400, Peter Xu wrote:
> > > > On Tue, Au
On Fri, Jul 26, 2024 at 09:48:02AM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote:
> > On 26/07/2024 08.08, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2024 at 06:18:20PM -0400, Peter Xu wrote:
> > > > On Tue, Au
On Fri, Jul 26, 2024 at 04:17:12PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 26, 2024 at 10:43:42AM -0400, Peter Xu wrote:
> > On Fri, Jul 26, 2024 at 09:48:02AM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote:
> >
On Fri, Jul 26, 2024 at 07:39:46PM +0200, Thomas Huth wrote:
> On 26/07/2024 09.25, Michael S. Tsirkin wrote:
> > On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote:
> > > On 26/07/2024 08.08, Michael S. Tsirkin wrote:
> > > > On Thu, Jul 25, 2024 at 06
On Mon, Jul 29, 2024 at 01:45:12PM +0900, Akihiko Odaki wrote:
> On 2024/07/29 12:50, Jason Wang wrote:
> > On Sun, Jul 28, 2024 at 11:19 PM Akihiko Odaki
> > wrote:
> > >
> > > On 2024/07/27 5:47, Peter Xu wrote:
> > > > On Fri, Jul 26, 2024
On Mon, Jul 29, 2024 at 04:58:03PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 26, 2024 at 04:47:40PM -0400, Peter Xu wrote:
> > On Fri, Jul 26, 2024 at 04:17:12PM +0100, Daniel P. Berrangé wrote:
> > >
> > > In terms of launching QEMU I'd imagine:
> >
On Tue, Jul 30, 2024 at 02:23:46AM +0900, Akihiko Odaki wrote:
> On 2024/07/30 2:00, Peter Xu wrote:
> > On Mon, Jul 29, 2024 at 04:58:03PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Jul 26, 2024 at 04:47:40PM -0400, Peter Xu wrote:
> > > > On Fri, Jul 26, 2024
On Mon, Jul 29, 2024 at 06:26:41PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 29, 2024 at 01:00:30PM -0400, Peter Xu wrote:
> > On Mon, Jul 29, 2024 at 04:58:03PM +0100, Daniel P. Berrangé wrote:
> > >
> > > We've got two mutually conflicting goals with th
On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 30, 2024 at 02:13:51PM -0400, Peter Xu wrote:
> > On Mon, Jul 29, 2024 at 06:26:41PM +0100, Daniel P. Berrangé wrote:
> > > On Mon, Jul 29, 2024 at 01:00:30PM -0400, Peter Xu wrote:
> > > &
that.
Thanks,
--
Peter Xu
On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
> > On Tue, Jul 30, 2024 at 03:22:50PM -0400, Michael S. Tsirkin wrote:
> > > This is not what we did historically. Why should we start now?
> &g
On Wed, Jul 31, 2024 at 03:41:00AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 31, 2024 at 08:04:24AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jul 30, 2024 at 05:32:48PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, Jul 30, 2024 at 04:03:53PM -0400, Peter Xu wrote:
>
On Thu, Aug 01, 2024 at 02:05:54PM +0900, Akihiko Odaki wrote:
> On 2024/07/31 4:11, Peter Xu wrote:
> > On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jul 30, 2024 at 02:13:51PM -0400, Peter Xu wrote:
> > > > On Mon, Jul 29, 2024
o
I'm not sure how fast that can ready, considering our very limited
bandwidth so far. Maybe that can be done separately, but I remember Dan
used to suggest we do handshake right in one shot, and I tend to agree
that'll be nicer.
Thanks,
--
Peter Xu
On Fri, Aug 02, 2024 at 01:30:51PM +0900, Akihiko Odaki wrote:
> On 2024/08/02 0:13, Peter Xu wrote:
> > On Thu, Aug 01, 2024 at 02:05:54PM +0900, Akihiko Odaki wrote:
> > > On 2024/07/31 4:11, Peter Xu wrote:
> > > > On Tue, Jul 30, 2024 at 07:46:12PM +0100, Daniel P
hinking (where I totally agree with you on this) that
whether we should settle a short term plan first to be on the safe side
that we start with migration always being compatible, then we figure the
other approach. That seems easier to me, and it's also a matter of whether
we want to do something for 9.1, or leaving that for 9.2 for USO*.
Thanks,
--
Peter Xu
On Fri, Aug 02, 2024 at 12:40:33PM -0400, Michael S. Tsirkin wrote:
> On Fri, Aug 02, 2024 at 12:26:22PM -0400, Peter Xu wrote:
> > And that's why I was thinking (where I totally agree with you on this) that
> > whether we should settle a short term plan first to be on the s
On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
> On 2024/08/03 1:26, Peter Xu wrote:
> > On Sat, Aug 03, 2024 at 12:54:51AM +0900, Akihiko Odaki wrote:
> > > > > > I'm not sure if I read it right. Perhaps you meant something more
> > > >
On Mon, Aug 05, 2024 at 04:27:43PM +0900, Akihiko Odaki wrote:
> On 2024/08/04 22:08, Peter Xu wrote:
> > On Sun, Aug 04, 2024 at 03:49:45PM +0900, Akihiko Odaki wrote:
> > > On 2024/08/03 1:26, Peter Xu wrote:
> > > > On Sat, Aug 03, 2024 at 12:54:5
On Thu, Aug 08, 2024 at 08:43:22PM +0900, Akihiko Odaki wrote:
> On 2024/08/07 5:41, Peter Xu wrote:
> > On Mon, Aug 05, 2024 at 04:27:43PM +0900, Akihiko Odaki wrote:
> > > On 2024/08/04 22:08, Peter Xu wrote:
> > > > On Sun, Aug 04, 2024 at 03:49:45PM +0900, Aki
ould fix a breakage first.
And that's why I think we should fix it even in the simple way first, then
we consider anything more benefitial from perf side without breaking
anything, which should be on top of that.
Thanks,
--
Peter Xu
ration everywhere
> 2) Migration on specific machines
> 3) Migration on some known platforms
> 4) No migration (migration on nowhere)
>
> Taking the discussion with Peter, I amend 4) as follows:
> 4*) Migration on one platform (checkpoint/restore)
Maybe we can avoid calling out "checkpoint/restore", but something like
"migration on identical hosts" or something.
AFAIU that's what we do with many arm64 systems on the vcpu models with KVM
(IIRC it's still about using "virt" machines), where we simply mostly
require it's the identical bare metal host or weird things can happen when
migration happens.
>
> cross-migrate=on is a complete solution for 1).
> 2) is dealt with another proposal of mine.[b]
> 3) can be solved with the -platform proposal by Daniel.[c]
> 4*) is what QEMU currently implements.
>
> [a]
> https://lore.kernel.org/all/39a8bb8b-4191-4f41-aaf7-06df24bf3...@daynix.com/
> [b]
> https://lore.kernel.org/all/2da4ebcd-2058-49c3-a4ec-8e60536e5...@daynix.com/
> [c] https://lore.kernel.org/all/zqo7cr-uigpx2...@redhat.com/
>
> Regards,
> Akihiko Odaki
>
Thanks,
--
Peter Xu
On Thu, Aug 08, 2024 at 10:47:28AM -0400, Michael S. Tsirkin wrote:
> On Thu, Aug 08, 2024 at 10:15:36AM -0400, Peter Xu wrote:
> > On Thu, Aug 08, 2024 at 07:12:14AM -0400, Michael S. Tsirkin wrote:
> > > This is too big of a hammer. People already use what you call "cross
On Wed, May 21, 2025 at 08:37:09AM +0200, Markus Armbruster wrote:
> Argument @detach has always been ignored. Start the clock to get rid
> of it.
>
> Cc: Peter Xu
> Cc: Fabiano Rosas
> Signed-off-by: Markus Armbruster
> ---
> docs/about/deprecated.rst | 5
On Wed, May 21, 2025 at 04:28:33PM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, May 21, 2025 at 08:37:09AM +0200, Markus Armbruster wrote:
> >> Argument @detach has always been ignored. Start the clock to get rid
> >> of it.
> >>
&g
66 matches
Mail list logo
