On Wed, Jul 15, 2026 at 06:01:39PM +0300, Michael Tokarev wrote: > 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
Well just theoretically, imagine a big VM, reserving twice the amount of memory just to migrate is not nice at all.
