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

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 17 Jan 2025 13:44:45 +0100
Stefano Brivio <sbrivio@redhat.com> wrote:

> 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.

This:

  https://lore.kernel.org/qemu-devel/1433943783-20125-1-git-send-email-thibaut.collet@6wind.com/

and the discussions here:

  https://lore.kernel.org/qemu-devel/1433943783-20125-3-git-send-email-thibaut.collet@6wind.com/#r

  https://mails.dpdk.org/archives/dev/2016-February/033520.html

have some hints, but if it's for OVN:

  https://opendev.org/openstack/neutron/commit/e16ab24cd8c418deb7af9ed4dff24f36be39231a

...it's not used anymore?

Still, I wouldn't care at the moment.

-- 
Stefano