Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dynamic UNIX socket forwarding #47

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

asahilina
Copy link
Member

Unconditionally forward a range of ports to sockets named $XDG_RUNTIME_DIR/krun/socket/port-$PORT. This allows applications to dynamically bind to sockets at those paths and have them forwarded to the guest as vsock ports, after the krun VM is already running.

The port range is currently hardcoded as 50000..50200.

Unconditionally forward a range of ports to sockets named
`$XDG_RUNTIME_DIR/krun/socket/port-$PORT`. This allows applications to
dynamically bind to sockets at those paths and have them forwarded to
the guest as vsock ports, after the krun VM is already running.

The port range is currently hardcoded as 50000..50200.

Signed-off-by: Asahi Lina <lina@asahilina.net>
@teohhanhui
Copy link
Collaborator

Would it make more sense for the port range to be configurable? The app will have to do directory traversal to figure out which ports are forwarded anyway, right? Otherwise what should happen when a port is already in use?

@asahilina
Copy link
Member Author

I think we need some way to tell apps what port range is available, I was thinking maybe a flag file in the directory? Apps would have to then pick the first nonexistent socket/port to bind to.

@slp
Copy link
Collaborator

slp commented Aug 22, 2024

Looks good. We should probably make the port range configurable via args with good defaults. As for how to coordinate port numbers across guest and host, giving that we expect most application launches to be initiated from the host, a reasonable approach could be delegating this responsibility to the application itself, like this:

  • The user launches the app.
  • The app looks for an non-existing socket file in the well-known directory.
  • The app launches the host-side executable which creates the unix socket in the selected path.
  • The app launches the guest-side executable using krun and passing an environment variable indicating the vsock port to connect to.

If this approach works for us, the only change in this PR would be making the port range configuration (and even than isn't a strong requirement from me).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants