Hi all! Here is a new migration parameter backend-transfer, which allows to enable local migration of TAP virtio-net backend (and maybe other devices and backends in future), including its properties and open fds.
With this new option, management software doesn't need to initialize new TAP and do a switch to it. Nothing should be done around virtio-net in local migration: it just migrates and continues to use same TAP device. So we avoid extra logic in management software, extra allocations in kernel (for new TAP), and corresponding extra delay in migration downtime. v10: reworked interface: 1. backend-transfer migration parameter - simple boolean 2. backend-transfer option for virtio-net device - in combination with [1] it enables the feature for concrete virtio-net device 3. incoming-fds option for TAP - to skip any open() calls and setting up the fd, and instead wait for incoming FD. Why we need [1]? To be able to simply choose between local and remote migration, not touching device options. Why we need [2]? Because otherwise we have to significantly complicate migration paremeter (to be a list of QOM paths of devices to enable backend-transfer for), which doesn't look good architectural design (we don't want to end with migration parameters like feature1 = [list of QOM paths], feature2 = [list of QOM paths]k, ... Why we need [3]? To avoid complicated logic of postponing the whole initialization of TAP up to pre-incoming point (see "[PATCH v9 0/9] net/tap: postpone connect"), and to make the whole feature more reliable: with such a parameter user is sure, that backend code will not do any open()/connect(), etc, which may influence running source vm. Automatic logic of 3 stage postponing in v9 (first, we postpone initialization up to attaching to frontend, then, if it's a virtio-net, it take ownership and postpone initializing of backend up to pre-incoming point (where we know migration parameters), and finally if it's a backend-transfer, postpone it up to post-load) can't be so reliable. Misconfiguration on target may lead to breaking source vm. And with separate parameter, everything becomes a lot simpler and reliable. The series is based on "[PATCH v2 00/12] net: refactoring and fixes" Based-on: <[email protected]> Vladimir Sementsov-Ogievskiy (8): net/tap: move vhost-net open() calls to tap_parse_vhost_fds() net/tap: move vhost initialization to tap_setup_vhost() qapi: add backend-transfer migration parameter net: introduce vmstate_net_peer_backend virtio-net: support backend-transfer migration net/tap: support backend-transfer migration tests/functional: add skipWithoutSudo() decorator tests/functional: add test_tap_migration hw/core/machine.c | 4 +- hw/net/virtio-net.c | 137 +++++- include/hw/virtio/virtio-net.h | 2 + include/migration/misc.h | 2 + include/net/net.h | 6 + migration/options.c | 18 +- net/net.c | 47 ++ net/tap.c | 185 ++++++-- qapi/migration.json | 13 +- qapi/net.json | 6 +- tests/functional/qemu_test/decorators.py | 16 + tests/functional/x86_64/meson.build | 1 + tests/functional/x86_64/test_tap_migration.py | 401 ++++++++++++++++++ 13 files changed, 792 insertions(+), 46 deletions(-) create mode 100644 tests/functional/x86_64/test_tap_migration.py -- 2.52.0
