-
Notifications
You must be signed in to change notification settings - Fork 259
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
[test] Add Hyper-V socket functional tests #1979
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
helsaawy
force-pushed
the
hcsock-func-tests
branch
3 times, most recently
from
December 12, 2023 20:57
d68cb40
to
0d82a11
Compare
helsaawy
changed the title
Add Hyper-V socket functional tests
[test] Add Hyper-V socket functional tests
Feb 8, 2024
helsaawy
force-pushed
the
hcsock-func-tests
branch
from
May 28, 2024 19:54
0d82a11
to
d156cfd
Compare
Add tests for binding to and listening on hyper-v sockets from within a uVM (as well as a hyper-v isolated containers). Tests verify default SDDL and wildcard bind settings, as well updating the settings for a particular service ID. In order to test HVSocket communication, an agent is needed to run from within the uVM (or container within that). To accomplish that, the ability to re-exec the (functional) testing binary is added, so that it can be shared into the uVM (or container) and then run a separate code path that is defined within the same test case that is running on the host. For example, while running the test case `TestHVSock_Container_GuestBind/default`, the functional testing binary that is being run (i.e. `functional.test.exe`) is shared within the running container and then run with the flag `-run=^TestHVSock_Container_GuestBind$/^default$`. This causes the guest to bind to the agreed-upon Service GUID, and then (after the host connects to the same Service GUID), the guest verifies the expected VM and service GUIDs, and then ensures communication is possible. Signed-off-by: Hamza El-Saawy <[email protected]>
helsaawy
commented
May 28, 2024
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.
Its best to review this after disabling showing whitespace (gear icon > "Hide whitespace" check box"), since most of the changes are indentation.
ambarve
reviewed
Jun 11, 2024
ambarve
reviewed
Jun 12, 2024
helsaawy
force-pushed
the
hcsock-func-tests
branch
from
June 19, 2024 17:04
d156cfd
to
fe99b1f
Compare
ambarve
approved these changes
Jun 26, 2024
yyatmsft
approved these changes
Jul 5, 2024
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.
LGTM
yyatmsft
approved these changes
Jul 5, 2024
Signed-off-by: Hamza El-Saawy <[email protected]>
helsaawy
force-pushed
the
hcsock-func-tests
branch
from
July 8, 2024 18:10
fe99b1f
to
19d8435
Compare
princepereira
pushed a commit
to princepereira/hcsshim
that referenced
this pull request
Aug 29, 2024
* [test] Add hvsock connection tests Add tests for binding to and listening on hyper-v sockets from within a uVM (as well as a hyper-v isolated containers). Tests verify default SDDL and wildcard bind settings, as well updating the settings for a particular service ID. In order to test HVSocket communication, an agent is needed to run from within the uVM (or container within that). To accomplish that, the ability to re-exec the (functional) testing binary is added, so that it can be shared into the uVM (or container) and then run a separate code path that is defined within the same test case that is running on the host. For example, while running the test case `TestHVSock_Container_GuestBind/default`, the functional testing binary that is being run (i.e. `functional.test.exe`) is shared within the running container and then run with the flag `-run=^TestHVSock_Container_GuestBind$/^default$`. This causes the guest to bind to the agreed-upon Service GUID, and then (after the host connects to the same Service GUID), the guest verifies the expected VM and service GUIDs, and then ensures communication is possible. Signed-off-by: Hamza El-Saawy <[email protected]> * PR: remove hvsock feature Signed-off-by: Hamza El-Saawy <[email protected]> --------- Signed-off-by: Hamza El-Saawy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add tests for binding to and listening on hyper-v sockets from within a uVM (as well as a hyper-v isolated containers).
Tests verify default SDDL and wildcard bind settings, as well updating the settings for a particular service ID.
In order to test HVSocket communication, an agent is needed to run from within the uVM (or container within that).
To accomplish that, the ability to re-exec the (functional) testing binary is added, so that it can be shared into the uVM (or container) and then run a separate code path that is defined within the same test case that is running on the host.
For example, while running the test case
TestHVSock_Container_GuestBind/default
, the functional testing binarythat is being run (i.e.
functional.test.exe
) is shared within the running container and then run with the flag-run=^TestHVSock_Container_GuestBind$/^default$
.This causes the alternative code path defined in
TestHVSock_Container_GuestBind/default
test case to run in the guest, which binds to the agreed-upon service GUID, and then (after the host connects to the same service GUID) verifies the expected VM and service GUIDs, and then ensures communication is possible.