-
Notifications
You must be signed in to change notification settings - Fork 2.7k
HyperV machine should reuse hvsock registry entries when possible #26277
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
base: main
Are you sure you want to change the base?
Conversation
this commit moves the HasAdminRights func from the wsl package to a generic windows package as this could also be used by the HyperV provider. Signed-off-by: lstocchi <lstocchi@redhat.com>
Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. 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. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: lstocchi 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 |
[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore. |
how are migrations handled? |
it is transparent to the user. The existing machines works the same as before. The new ones will not add any new entry in the Registry and will reuse the existing hvsock. |
Previously, each new HyperV Podman machine required creating new hvsock registry entries, necessitating administrator privileges. This change modifies the HyperV provider to reuse existing hvsock entries if found. This is possible due to Podman's current limitation of running only one HyperV machine at a time. As a result, administrator privileges are only needed for the first initial machine setup (when the registry is empty). Subsequent machines can be created by users in the "Hyper-V Administrators" group without being Admin. Hvsock entries are no longer deleted on machine removal; cleanup is handled by a system reset. Signed-off-by: lstocchi <lstocchi@redhat.com>
The uncompressed test previously failed on Windows because it uses \r\n line endings, while the test data and expected output implicitly assumed \n. This commit resolves the issue by replacing the \r\n with \n so that the comparison works on both Windows and Unix-like systems Signed-off-by: lstocchi <lstocchi@redhat.com>
Signed-off-by: lstocchi <lstocchi@redhat.com>
My only doubt is about the cleaning of the Registry. This implementation leverages the |
PR needs rebase. 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. |
This is a proposal based on ideas shared on #25723 and #25038 to, eventually, run podman on hyperv without being admin.
Instead of creating new Registry entries at each
podman machine init
execution, podman should try to reuse existing entries.This can be done because a user can only start a machine at a time.
A summary of what it does...
init
, it checks if there is a hvsock entry/port we could reuse (based on the purpose), otherwise if the user is admin it will create a new one (as it happens now)Does this PR introduce a user-facing change?
After the first machine init when the Registry gets populated, users could run podman on hyperv without being admin (if they are member of the hyperv admin group)