[test] Add Hyper-V socket functional tests #1979
Open
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
d68cb40
to
0d82a11
Compare
helsaawy
changed the title
Add tests for binding to and listening on hyper-v sockets from within a uVM (as well as a hyper-v isolated containerd). 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 <hamzaelsaawy@microsoft.com>
helsaawy
force-pushed
the
hcsock-func-tests
branch
from
0d82a11
to
d156cfd
Compare
helsaawy
commented
May 28, 2024
There was a problem hiding this comment.
Its best to review this after disabling showing whitespace (gear icon > "Hide whitespace" check box"), since most of the changes are indentation.
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/defaulttest 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.