Re: [libvirt] [PATCH] RFC: use a slirp helper process
Hi
On Tue, Apr 30, 2019 at 7:31 PM Daniel P. Berrangé <berrange(a)redhat.com> 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