Re: [PATCH 0/9] vhost-user: Migration support

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 17 Jan 2025 13:13:36 +0100
Laurent Vivier <lvivier@redhat.com> wrote:

> On 19/12/2024 12:13, Laurent Vivier wrote:
> > This series allows a QEMU guest to be migrated while it is connected
> > to Passt using vhost-user interface.
> > 
> > There are two parts:
> > 
> > - first part enables the migration of QEMU without transferring the
> >    internal state of Passt. All connections are lost.
> > 
> >    This is done by implementing VHOST_USER_SET_LOG_FD and
> >    VHOST_USER_SET_LOG_BASE commands (and enabling
> >    VHOST_USER_PROTOCOL_F_LOG_SHMFD feature)
> > 
> >    "vhost-user: add VHOST_USER_SET_LOG_FD command"
> >    "vhost-user: add VHOST_USER_SET_LOG_BASE command"
> >    "vhost-user: Report to front-end we support VHOST_USER_PROTOCOL_F_LOG_SHMFD"
> > 
> > - second part allows source Passt instance to send its internal
> >    state using QEMU migration channel to destination Passt instance.
> > 
> >    This is done implementing VHOST_USER_SET_DEVICE_STATE_FD and
> >    VHOST_USER_CHECK_DEVICE_STATE (and enabling
> >    VHOST_USER_PROTOCOL_F_DEVICE_STATE feature).
> > 
> >    "vhost-user: add VHOST_USER_CHECK_DEVICE_STATE command"
> >    "vhost-user: add VHOST_USER_SET_DEVICE_STATE_FD command"
> >    "vhost-user: Report to front-end we support VHOST_USER_PROTOCOL_F_DEVICE_STATE"
> > 
> >    For now, it only implements the function needed to transfer the
> >    state but no state is transferred.
> > 
> >    VHOST_USER_PROTOCOL_F_DEVICE_STATE is implemented in QEMU
> >    only for vhost-user-fs, to be able to use it with virtio-net
> >    I have proposed a patch upstream:
> > 
> >    https://patchew.org/QEMU/20241218143453.1573185-1-lvivier@redhat.com/
> > 
> > Laurent Vivier (9):
> >    virtio: Use const pointer for vu_dev
> >    vhost-user: update protocol features and commands list
> >    vhost-user: add VHOST_USER_SET_LOG_FD command
> >    vhost-user: Pass vu_dev to more virtio functions
> >    vhost-user: add VHOST_USER_SET_LOG_BASE command
> >    vhost-user: Report to front-end we support
> >      VHOST_USER_PROTOCOL_F_LOG_SHMFD
> >    vhost-user: add VHOST_USER_CHECK_DEVICE_STATE command
> >    vhost-user: add VHOST_USER_SET_DEVICE_STATE_FD command
> >    vhost-user: Report to front-end we support
> >      VHOST_USER_PROTOCOL_F_DEVICE_STATE
> > 
> >   epoll_type.h |   2 +
> >   passt.c      |   4 +
> >   util.h       |   3 +
> >   vhost_user.c | 251 ++++++++++++++++++++++++++++++++++++++++++++++++++-
> >   vhost_user.h |  50 +++++++++-
> >   virtio.c     | 116 +++++++++++++++++++++---
> >   virtio.h     |  32 +++++--
> >   vu_common.c  |  59 +++++++++++-
> >   vu_common.h  |   3 +-
> >   9 files changed, 484 insertions(+), 36 deletions(-)
> >   
> 
> Another point:
> 
> vhost-user can ask backend (passt) to send a notification at the end of the migration on 
> the destination side to the network to update the network topology. Do we need this?
> 
> This is VHOST_USER_SEND_RARP:
> "Ask vhost user back-end to broadcast a fake RARP to notify the migration is terminated 
> for guest that does not support GUEST_ANNOUNCE.
> 
> Only legal if feature bit VHOST_USER_F_PROTOCOL_FEATURES is present in 
> VHOST_USER_GET_FEATURES and protocol feature bit VHOST_USER_PROTOCOL_F_RARP is present in 
> VHOST_USER_GET_PROTOCOL_FEATURES. The first 6 bytes of the payload contain the mac address 
> of the guest to allow the vhost user back-end to construct and broadcast the fake RARP."

This isn't really clear :( ...what does "fake RARP" even mean? RARP is
a protocol, and an obsolete one, despite:

  https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol#Modern_Day_Uses

Anyway, it comes from 3e866365e1eb ("vhost user: add rarp sending after
live migration for legacy guest").

I have no idea what "legacy" means here, but I'm under the impression that
somebody just needed a way to notify the guest of the finished migration
(nothing related to networking) and, correct me if I'm wrong, the French
word for "fake" is rather similar to the one for "dummy".

So my understanding of it is that they would just send a dummy packet,
and a RARP broadcast would be a good candidate because it's otherwise
unused, but wouldn't raise any firewall alert.

Or maybe "legacy" has something to do with VMware vSphere, and there was
some guest previously running on VMware vSphere that needs a RARP packet
to "proceed" with something after the migration.

If that's the case, and if there's still something like that around, I
guess that ideally we want it for compatibility, but it's *very* unlikely
to ever bite us.

So all in all I would say that if the implementation is very small and
unproblematic we can hack up something in arp.c to build a RARP packet
(example here: https://wiki.wireshark.org/RARP but that's a request, not
a broadcast). Otherwise I wouldn't really care until somebody asks.

-- 
Stefano