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
