-
Notifications
You must be signed in to change notification settings - Fork 239
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 libhvee as alternative Hyper-V driver on Windows #3824
Add libhvee as alternative Hyper-V driver on Windows #3824
Conversation
9c10def
to
2e72ce2
Compare
0a919ec
to
6013d5f
Compare
This comment was marked as outdated.
This comment was marked as outdated.
6013d5f
to
d1658c1
Compare
These are the results for this PR on windows https://crcqe-asia.s3.amazonaws.com/nightly/ocp/4.13.12/20231005/11-pro/qe-results/e2e-non-ux.xml |
Want to incorporate 9P, but the current codebase for this lives in the PR containers/gvisor-tap-vsock#280 |
The code from this gvisor-tap-vsock PR is short, and thus easy to add to the daemon when we need it. But there's also some guest code involved, which might be trickier mheon/libpod@334e213 |
@cfergeau it basically is the same/similar code as the 9p-ufs that I tested with earlier, so I am not so concerned. I am more curious if this will therefore be part of a library, or the changes for libpod remain seperate? |
ref: #3870 |
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.
I've rebased this and squashed the commits in https://github.com/cfergeau/crc/tree/libhvee
This looks like a fairly straightforward change, though I haven't tried running it on a Windows machine :)
@@ -166,19 +165,6 @@ func fixUserPartOfCrcUsersAndHypervAdminsGroup() error { | |||
return errReboot | |||
} | |||
|
|||
func checkIfHyperVVirtualSwitchExists() error { |
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.
Fwiw, it would be good to split the system mode networking removal on Windows in its own preparatory commit, this would make it easier to focus on/review the config/preflight changes.
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.
Honestly, I do not even know if this functionality still works. I'll consider, but these checks are also performed when not even necessary (like the existence of the virtual switch) and therefore actually wrong.
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.
I've done this in https://github.com/cfergeau/crc/tree/libhvee, this removes even more code
Rebase done. |
729ee25
to
3def960
Compare
17ce677
to
ee4795d
Compare
@lilyLuLiu @adrianriobo For this change, the proxy tests are failing. Do we have more information aroudn this? |
@gbraad those are mainly failing due to timeout on the full suite, let me check downstream running only that one I will ack if it is green (and will increase the timeout for the suite here) |
Downstream windows test passed for this PR. |
We are good to go, downstream proxy is green |
Should return an error when trying to set the "system networking" option. But I think this is already the case, or it's not possible to choose this option in release builds? Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
This replaces the interaction of Hyper-V from our machine-drivers based driver as used in Minikube/minishift to the libhvee library as used by podman machine.
Disk handling API was added to libhvee since the first iteration of the libhvee support, we can now make use of it. Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
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.
Full green on downstream windows env
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adrianriobo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Didn't we wait too long though? We held this PR a while back as we did not want to land it at the same time as the switch to 4.16. |
ee4795d
to
3003fc5
Compare
New changes are detected. LGTM label has been removed. |
@gbraad: 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-sigs/prow repository. I understand the commands that are listed here. |
Since it is pass the pipeline, I don't think we should hold it any longer. I am merging this now. |
We held it last time because QE had concerns about their capacity to deal with 2 large changes at once, would have been nice to wait for their input before merging this.. |
No worries, I am fine with it, as @praveenkumar this already passed (and actually has been passing for a while now). So I think we should be good. |
Thank you all |
Fixes #3811
Basic functionality for: