Hi Nikolay,
On Fri, 15 Sep 2023 18:21:52 +0400
Nikolay Edigaryev <edigaryev(a)gmail.com> wrote:
Problem: I have a Cloud Hypervisor virtual
machine that needs both
(1) an internet access without fiddling with iptables/Netfilter and
(2) VM <-> host access (to be able to provision this VM over SSH)
without dealing with passt port forwarding it doesn't seem to be
possible to map the whole IP address, yet the users expect an IP
instead of IP:port combination.
Requirement #1 is why I've choosen passt and it's pretty much
satisfied (thank you for this great piece of software!).
And thanks for the patches! I'm glad to hear it's useful for you (and
with Cloud Hypervisor :)).
Two comments:
Requirement #2 implies some kind of bridge
interface on the host
with one TAP interface for the VM and the other for the passt.
However, only pasta can accept TAP interface FD's in it's -F/--fd,
which is OK, but it also configures unneeded namespacing, which in
turn results in unneeded complexity and performance overhead due
to the need of involving veth pairs to break away from the pasta
namespace to the host for the requirement #2 to be satisfied.
I've also considered proxying the UNIX domain socket communication
to/from a TAP interface in my own Golang code, but it incurs
significant performance overhead.
On the other hand passt seems to already can do everything I need,
it just needs some guidance on which type of FD it's dealing with.
Solution: introduce --fd-is-tap command-line flag to tell passt
which type of FD it's being passed to and force it to use appropriate
system calls and offset calculation.
Did you consider adding another parameter altogether, such as --tap-fd?
I'm asking because we recently got a request to add another (similar)
interface on that "side", that is, a VSOCK file descriptor, for usage
with podman-machine. At that point, a further --fd-is-vsock would look
a bit awkward.
Further, David Gibson is working on a generalised flow table approach
which *should* also allow us to have multiple "taps"... and at that
point, somebody might want to pass multiple "--tap-fd" or -F options.
I didn't really evaluate if there are drawbacks to that, though --
maybe it's a lot more code.
I second that point. I think having a different option for passing an
fd is a much better interface design than having a secondary option
which affects the interpretation of another one.
This patch
also clarifies the -F/--fd description for pasta to note
that we're expecting a TAP device and not a UNIX domain socket.
You should add a Signed-off-by tag here (but in general I can fix up
tags myself on merge). Other than that, the patch looks good to me in a
general sense.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!