On 14.07.2026 18:42, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
Here is a migration for TAP net backend, including its properties and
open fds.
With this new feature, 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.
This is quite a big patch set, - is this really worth the effort to do
all this just for *local* migration? What's the possible use case for
this in real, - am I right this is just about upgrading the host qemu?
And with that in mind, isn't it sufficient to use what we already have
(namely, create new tap, start new qemu instance, and migrate the usual
way), and tolerate some very minor downtime while the networking code
learns the new network topology (isn't it happening almost instantly
anyway, and if not, the management can help by sending gratitious ARP)?
I wonder what's the use for this at yandex?
Thanks,
/mjt
