-
Notifications
You must be signed in to change notification settings - Fork 52
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
Update gvisor-tap service by using nmcli and binary from container image #673
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
Trying this patch right now with microshift bundle and so far so good tried 3 time /hold |
This patch do following - Create a tap device using nmcli with a hard coded mac address, this mac address is mapped in the crc daemon lease which provide `192.168.127.2` IP address to the VM. - copy the `vm` binary from container image and put it to /usr/local/bin - modify gvisor-tap-vsock service to use the `vm` binary instead running the container using podman
87b7be3
to
45c5117
Compare
With the current change now it takes around 40-50 sec extra. I have to dig more. ( still hold) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had these comments around, never posted them apparently :(
podman create --name=gvisor-tap-vsock quay.io/crcont/gvisor-tap-vsock:latest | ||
podman cp gvisor-tap-vsock:/vm /usr/local/bin/ | ||
podman rm gvisor-tap-vsock | ||
tee /etc/systemd/system/gvisor-tap-vsock.service <<ETE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does ETE
have any special meaning/is this typical to use this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first time I see this
[Unit] | ||
Description=gvisor-tap-vsock traffic forwarder | ||
Wants=network-online.target | ||
After=network-online.target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the network-online
target is reached, it means the system has some kind of external network connectivity. In our bundles, with usermode networking, gvisor-tap-vsock
is required before we have external network connectivity.
This unit file tells systemd to first wait for network-online.target
, and then to start gvisor-tap-vsock.service
, I don't think this is correct, the order should be the opposite.
containers/gvisor-tap-vsock#202 is exploring something similar. |
I've done some work on this in https://github.com/cfergeau/snc/tree/gvisor_service |
@praveenkumar: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
This patch do following
192.168.127.2
IP address to the VM.vm
binary from container image and put it to /usr/local/binvm
binary instead running the container using podman