On Wed, Jul 15, 2026 at 11:48:40AM -0400, Michael S. Tsirkin wrote: > 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.
Don't we already have the ability to skip memory transfer by setting the "x-ignore-shared" capability, assuming the VM RAM has a shared memory backing. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
