search

microsoft / go-winio

Win32 IO-related utilities for Go
MIT License
946 stars 180 forks source link

HVsock Registry Application Registration #238

Closed helsaawy closed 2 years ago

helsaawy commented 2 years ago

Using Hyper-V sockets requires registering the application in the Windows Registry.

This PR adds (de)registration functionality for an application name/GUID.

This PR is split from #235

Signed-off-by: Hamza El-Saawy hamzaelsaawy@microsoft.com

kevpar commented 2 years ago

Do we know what precisely this registration affects or is needed for? I'm pretty sure we don't do this for any of the hvsocket stuff we use in the GCS today.

helsaawy commented 2 years ago

Do we know what precisely this registration affects or is needed for? I'm pretty sure we don't do this for any of the hvsocket stuff we use in the GCS today.

I dont know if the general case requires it, or if doing it allows for some side benefit, besides the docs saying its needed. For hcsshim, WCOW uses the HCS service id (1, 2). At least for me, thats already registered in my registry.

And for LCOW, we use the well known Vsock service ID

kevpar commented 2 years ago

Do we know what precisely this registration affects or is needed for? I'm pretty sure we don't do this for any of the hvsocket stuff we use in the GCS today.

I dont know if the general case requires it, or if doing it allows for some side benefit, besides the docs saying its needed. For hcsshim, WCOW uses the HCS service id (1, 2). At least for me, thats already registered in my registry.

And for LCOW, we use the well known Vsock service ID

Reading the doc from the PR description, I think we likely don't actually need this support. WMI based management is the older model used by VMMS. I suspect this registry entry basically allows the service to be used with a VMMS VM. However with HCS we instead directly configure what services are allowed using ServiceTable in the HCS schema, which also gives us much more fine-grained control.

helsaawy commented 2 years ago

Reading the doc from the PR description, I think we likely don't actually need this support. WMI based management is the older model used by VMMS. I suspect this registry entry basically allows the service to be used with a VMMS VM. However with HCS we instead directly configure what services are allowed using ServiceTable in the HCS schema, which also gives us much more fine-grained control.

Testing locally, service registration doesn't seem to have effect if using the well-known VM IDs (ie Loopback/Host/...). I added this mostly for external users that may want it, but if you think thats unnecessary, I'll close this.

dcantah commented 2 years ago

My $0.02 at least, I like the helpers. I know we'd been chuggin along due to the pre-registered gcs service ID so we don't need it on our end (at least for our container work), but it seems like a harmless time save for users of the package.

I suspect this registry entry basically allows the service to be used with a VMMS VM.

vmms is the only place I really see the key being checked and not just set, so you're probably right.

kevpar commented 2 years ago

My preference would be we don't try to support anything VMMS related. It's WMI based (gross) and probably not a rabbit hole we want to go down. HCS all the way :)

helsaawy commented 2 years ago

Noted; I'll close this.