Add support for volume sharing via gvproxy for HyperV #280
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: mheon The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
There are no tests included here, because right now, the 9p code only runs on Windows + hyperv, and GHA does not seem to be able to reasonably test that configuration. I briefly looked into adding Mac support so it could be tested on a platform where we actually have access to non-nested virt, but the code was going to be so different (and not used outside of testing) that I didn't think it was worth it. Companion Podman branch, not yet PRed: https://github.com/mheon/libpod/tree/9p |
mheon
force-pushed
the
add_9p
branch
4 times, most recently
from
d2e5bdc to
0891cc3
Compare
|
@mheon do you have an idea of how much this increased binary size? |
|
~500kb from an initial check, exclusive to Windows (only place we need the 9p library) |
There was a problem hiding this comment.
Added a couple of comments.
However, having this 9p support in gvproxy feels awkward. This PR has no dependency on other gvisor-tap-vsock/pkg code, is Windows/Hyper-V only.
gvisor-tap-vsock provides a user-mode networking implementation, this 9p file sharing code is unrelated to this.
Apparently similar functionality could be achieved with a patched https://github.com/hugelgupf/p9/tree/main/cmd/p9ufs (for hvsock support) and one process per share? This could go in libhvee where it would fit better?
If podman wants to keep all the code which runs for the lifetime of the VM in a single process, have you considered having this combined gvproxy + 9p code in podman or a related module?
pkg/fileserver/server_windows.go
Outdated
|
|
||
| go func() { | ||
| if err := server.WaitForError(); err != nil { | ||
| logrus.Errorf("Error from 9p server for %s: %v", path, err) |
| "github.com/containers/gvisor-tap-vsock/pkg/fileserver/plan9" | ||
| "github.com/linuxkit/virtsock/pkg/hvsock" | ||
| "github.com/sirupsen/logrus" | ||
| "github.com/pkg/errors" |
There was a problem hiding this comment.
fwiw, this is obsolete https://github.com/pkg/errors " This repository has been archived by the owner on Dec 1, 2021. It is now read-only. "
There was a problem hiding this comment.
It's used throughout gvproxy right now, and I don't think mixing legacy pkg/errors and the new Golang fmt errors is a good idea. I can convert the entire project over to it, if you'd like? Shouldn't be that difficult.
There was a problem hiding this comment.
Ah I did not check the existing code for usage of pkg/errors. I only noticed it's deprecated when looking for the doc/source code for errors.Wrapf, I'm fine if you keep the pkg/errors usage in this file.
There was a problem hiding this comment.
what about a follow-up/refactor to address this?
|
We could certainly move the code into Podman, but thus far Podman has avoided having a long-running VM management process on Windows. The hope was we could continue to avoid this by placing the 9p code into the existing service which is guaranteed to live as long as the VM (gvproxy). If this is disagreeable, we can look into integrating the code back into Podman. |
Specifically, gvproxy will act as a 9p server, serving shares requested by the caller on HyperV vsocks, to allow the guest VM to access content on the host. The vsocks are intended to be managed by the caller in this model. As such, gvproxy receives the path to be shared and a vsock port number to share it on via CLI. An arbitrary number of these are accepted, as each share needs a separate server and vsock (they will be mounted by the Linux kernel 9p code within the guest VM, which does not support multiplexing multiple shares over a single vsock). Also, make a slight change to .gitignore - the ./bin/ ignore pattern was not ignoring the bin/ directory for me (removing the leading . fixes things). Signed-off-by: Matthew Heon <[email protected]>
|
forking of a process from podman machine (or libhvee) seems better fitting, with this code being part of a separate library. it is not something for gvproxy. |
|
Ack, I'll shift this over, then. |
|
Thanks @mheon, that would also make it easier to use it in: |
Specifically, gvproxy will act as a 9p server, serving shares requested by the caller on HyperV vsocks, to allow the guest VM to access content on the host.
The vsocks are intended to be managed by the caller in this model. As such, gvproxy receives the path to be shared and a vsock port number to share it on via CLI. An arbitrary number of these are accepted, as each share needs a separate server and vsock (they will be mounted by the Linux kernel 9p code within the guest VM, which does not support multiplexing multiple shares over a single vsock).
Also, make a slight change to .gitignore - the ./bin/ ignore pattern was not ignoring the bin/ directory for me (removing the leading . fixes things).