Re: [PATCH v19 00/15] virtio-net: live-TAP local migration

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jul 15, 2026 at 11:21:23PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 15.07.26 19:00, Peter Xu wrote:
> > On Wed, Jul 15, 2026 at 04:52:48PM +0100, Daniel P. Berrangé wrote:
> > > 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.
> > 
> > Right, IIUC all similar single-host migrations like this series or CPR (or
> > anything else...) should always need to enable x-ignore-shared in the first
> > place.  That's almost always the starting point of optimizing local
> > migrations.. no matter how the memory will be shared (by the same pool of
> > page cache, or persisted over kexec, etc.).
> > 
> 
> Yes, sharing RAM between source and target + enabling x-ignore-shared is a first thing to do.
> 
> This series optimizes TAP recreating. Not only skip recreating but also allow to
> exclude cloud-networking component form live-update entirely, making the process
> simpler (less components involved), and as I already said, reducing corresponding
> downtime.
> 
> -- 
> Best regards,
> Vladimir

So can you explain, how is this better than
1. a persistent tap
2. a non persistent tap that some server gets a hold of

IOW why does qemu need to bother.
-- 
MST