Introduce a client-server model #23
Conversation
|
Any reason for using a TCP port vs a Unix socket? Would vsock not work well for that? |
Right now libkrun only supports outgoing (VM -> host) connections with vsock. Implementing it the other way around is doable, but would be quite expensive to make it reliable, specially compared with simply using a TCP socket. |
slp
force-pushed
the
server-model
branch
2 times, most recently
from
911bc06
to
f6eebcb
Compare
slp
force-pushed
the
server-model
branch
4 times, most recently
from
d3edb7e
to
26d9205
Compare
|
I'll need more time to review the rest of the code, if that's alright. |
With the introduction of 47fdd45 (Default guest memory to 80% of total RAM on host), we're targeting a use case in which we expect to be running a single, large VM. To accommodate this use case, we're switching here to a client/server model. The first time krun is launched, in addition to running the command, it starts a small server in the VM listening on a TCP port. On the host side, it also creates a lock file, writes the listening port number to it, and calls flock() on it to prevent other instances from running in parallel. When it's executed again, krun detects there's another instance running, and contacts the server in the VM to request the launch of the command. The stdout and stderr of the command are redirected to $XDG_RUNTIME_DIR/krun-$COMMAND-$TIMESTAMP.[stdout|stderr] Co-authored-by: Teoh Han Hui <teohhanhui@gmail.com> Signed-off-by: Sergio Lopez <slp@sinrega.org>
Yeah, sorry about that. This turned to be a huge PR basically because we're changing a significant part of the original behavior and UX. I hope we don't need to deal with such a large change anymore. Everything else I have line up (including a juicy one that drastically decreases start-up time ;-) is much smaller. I've just applied your last suggestions and will be merging this one. Thanks a lot for the review! |
With the introduction of 47fdd45 (Default guest memory to 80% of total RAM on host), we're targeting a use case in which we expect to be running a single, large VM.
To accommodate this use case, we're switching here to a client/server model. The first time krun is launched, in addition to running the command, it starts a small server in the VM listening on a TCP port. On the host side, it also creates a lock file, writes the listening port number to it, and calls flock() on it to prevent other instances from running in parallel.
When it's executed again, krun detects there's another instance running, and contacts the server in the VM to request the launch of the command. The stdout and stderr of the command are redirected to $XDG_RUNTIME_DIR/krun-$COMMAND-$TIMESTAMP.[stdout|stderr]