Hi On Tue, Apr 30, 2019 at 7:31 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > At this point, the slirp-helper doesn't handle migration. But is it > > really worth it? From a guest POV, it would look like packet lost or > > disconnection. Adding migration handling is possible, to avoid a > > disconnection event. How should it be done? via a libvirt provided > > socket for storage? via its own file transferred by libvirt? via qemu > > somehow (qemu wouldn't really know about the external process but > > would copy around the migration bits?). > > How does migration actually work today with built-in slirp ? I It is registered with save_state/load_state callbacks (old-style vmstate), and save/load from the given stream. It uses the "vmstate format" so far, although it could be a blob for what qemu is concerned (there is no json-desc, although there could be, but that would make libslirp even more relying on vmstate format). But the interesting thing is that very few state is saved. Beside some DHCP (bootp) state, only guestfwd sockets are saved. I suppose the reason is that it's not "possible" to migrate a system socket. On destination, UDP sockets will be handled by guest OS fine, new slirp UDP socket will be created, and guest will mostly see some packet lost. For TCP, in general, there isn't anything slirp can really do. Even if slirp did attempt to save/restore TCP sockets, this will result in stream corruption (or just disconnection) in the guest. That's why it probably doesn't make much sense to save much of slirp socket state beside guestfwd, and let the guest handle socket disconnect/reconnect. > Assume that all open network connections are lost right now ? So guestfwd (& udp) sockets shouldn't be "lost" from guest POV. But TCP sockets will be. > > What actual state does QEMU transfer for built-in slirp what > does that achieve in practice ? > > Ideally we would "live migrate" all existing QEMU processes using > built-in slirp to use the slirp helper. Even if this doesn't > actually do much useful stuff due to all connections being lost, > it allows us to automatically enable external slirp for everything > out of the box. Requiring an opt-in config for external slirp makes > it less compelling & will massively reduce uptake. It's not reasonable to expect built-in slirp VM to migrate to external slirp imho. Qemu doesn't know much about the external helper, it talks ethernet frame with it only. When external slirp process learns migration support, either libvirt manages the "state" (read it, transfer it etc), or we could somehow teach qemu to do it, ex "-savevm-external chardev", which would talk a simple protocol to read/save the state. Other ideas? thanks -- Marc-André Lureau -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
