On Fri, 17 Jan 2025 13:13:36 +0100
Laurent Vivier <lvivier(a)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_Da…
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.