On Tue, 3 Aug 2021 04:18:42 -0300
Leonardo Bras Soares Passos wrote:
> Hello Lukas,
>
> On Tue, Aug 3, 2021 at 3:42 AM Lukas Straub wrote:
> > Hi,
> > There is an easier explanation: I forgot the send side of multifd
> > altogether (I thought it was covered by migration_channel_connect()).
> >
Hello Lukas,
On Tue, Aug 3, 2021 at 3:42 AM Lukas Straub wrote:
> Hi,
> There is an easier explanation: I forgot the send side of multifd
> altogether (I thought it was covered by migration_channel_connect()).
> So yank won't actually shutdown() the multifd sockets on the send side.
If I could
Hello Dave,
> > diff --git a/migration/multifd.c b/migration/multifd.c
> > index 377da78f5b..744a180dfe 100644
> > --- a/migration/multifd.c
> > +++ b/migration/multifd.c
> > @@ -1040,6 +1040,17 @@ void multifd_recv_sync_main(void)
> >
On Fri, 30 Jul 2021 04:40:45 -0300
Leonardo Bras wrote:
> From source host viewpoint, losing a connection during migration will
> cause the sockets to get stuck in sendmsg() syscall, waiting for
> the receiving side to reply.
>
> In migration, yank works by shutting-down the migration
* Leonardo Bras (leob...@redhat.com) wrote:
> From source host viewpoint, losing a connection during migration will
> cause the sockets to get stuck in sendmsg() syscall, waiting for
> the receiving side to reply.
>
> In migration, yank works by shutting-down the migration QIOChannel fd.
> This
>From source host viewpoint, losing a connection during migration will
cause the sockets to get stuck in sendmsg() syscall, waiting for
the receiving side to reply.
In migration, yank works by shutting-down the migration QIOChannel fd.
This causes a failure in the next sendmsg() for that fd, and
