Expose the VM ID inside user distros #13212
Conversation
chelnak
requested review from
OneBlue,
benhillis,
craigloewen-msft and
justus-camp-microsoft
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Doh... i'll fix that localisation error shortly! |
This change ensures that we pass the vm id to an instances init. The id is then set as an environment variable and can be accessed at runtime.
|
Should be fixed now (double checked with the python script locally!) |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 13212 in repo microsoft/WSL |
|
I am good with this approach, but I think @OneBlue has some thoughts about not using an environment variable that people might end up taking a dependency on (and might not be present in all situations). |
There was a problem hiding this comment.
Overall change looks good !
Architecture wise I we should not expose WSL2_VM_ID to user processes and instead tell users to use wslinfo to fetch the VM ID.
Doing that cleanly would require a bit of a deeper change (since wslg currently depends on it being set inside the system distro), so let's merge this PR, and then we'll do a follow up change so that wslg moves to calling wslinfo, and then we can remove the environment variable from both the user and system distro.
Thank you for your contribution !
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Add a new argument --vm-id to wslinfo so that the caller can retrieve the VM id by calling the binary. Although it is an environment variable, it can be useful here too to save additional string parsing from the caller.
|
@benhillis @OneBlue Thanks both for the reviews. On the architecture point - I see what you mean and the plan sounds good! |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
3 participants
Summary of the Pull Request
Prior to this change it was not possible to find the ID of the VM responsible for providing WSL distro instances.
With this change, the VM ID is now exposed inside user distros via
wslinfoand as an environment variable.A benefit of this change is that a listener can be configured host side using the ID allowing connections from inside user distros.
For example, using Go, we can:
Where guid is the ID of the VM.
And from inside a distro, we can establish a vsock connection by using the appropriate port.
Looking forward to discussing this PR a bit more!
PR Checklist
Detailed Description of the Pull Request / Additional comments
Validation Steps Performed
The changes here have been validated by locally testing the change inside a user distro & also by adding and running unit tests.
The vm id can be accessed by:
wslinfo --vm-id