HvSocket support for containers

[anmaxvl]

Applications connecting from the host into the container should use
container-specific VMID. This ID will need to be the same as the
container's VMID inside the guest, which is calculated by HCS/GCS
like it's done in this PR by HCSIDToGUID.

To allow the container ID to work with HvSocket on the host, we
need to set up an AddressInfo mapping to tell HvSocket to redirect
the call into the UVM, which is done in this PR by default for
all WCOW containers.

[helsaawy]

does the address info ioctl have to go through before the container is created?
if not, then we could probably remove the HCSIDToGUID code and instead add the call to CreateAddressInfo in hcsoci.Create after the system is created and we have its GUID from HCS (so we don't rely on their internal logic for generating the GUID):

func CreateContainer(/* ... */) (_ cow.Container, _ *resources.Resources, err error) {
	// ...
	if gcsDocument != nil {
		c, err := coi.HostingSystem.CreateContainer(ctx, coi.actualID, gcsDocument)
		if err != nil {
			return nil, r, err
		}

		if p, err := c.PropertiesV2(ctx); err != nil {
			return nil, r, fmt.Errorf("retrieve created container compute system properties: %w", err)
		}
		hvsockAI, err := hvsocket.CreateAddressInfo(p.RuntimeId, coi.HostingSystem.RuntimeID(), true)
		if err != nil {
			return nil, r, fmt.Errorf("exposing container Hyper-V socket: %w", err)
		}
		r.Add(hvsockAI)

		return c, r, nil
	}
}

[helsaawy]

on a side note, how are users expected to get the runtime ID of the container for creating hv sockets?
are they expected to query HCS? or replicate the logic in HCSIDToGUID?

[apurv15]

What is the use case here? Is user expected to connect to inside the UVM using the containerId?
Can this be not satisfied through shimdiag exec into the UVM using the PodId?

[anmaxvl]

does the address info ioctl have to go through before the container is created? if not, then we could probably remove the HCSIDToGUID code and instead add the call to CreateAddressInfo in hcsoci.Create after the system is created and we have its GUID from HCS (so we don't rely on their internal logic for generating the GUID):

func CreateContainer(/* ... */) (_ cow.Container, _ *resources.Resources, err error) {
	// ...
	if gcsDocument != nil {
		c, err := coi.HostingSystem.CreateContainer(ctx, coi.actualID, gcsDocument)
		if err != nil {
			return nil, r, err
		}

		if p, err := c.PropertiesV2(ctx); err != nil {
			return nil, r, fmt.Errorf("retrieve created container compute system properties: %w", err)
		}
		hvsockAI, err := hvsocket.CreateAddressInfo(p.RuntimeId, coi.HostingSystem.RuntimeID(), true)
		if err != nil {
			return nil, r, fmt.Errorf("exposing container Hyper-V socket: %w", err)
		}
		r.Add(hvsockAI)

		return c, r, nil
	}
}

turned out RuntimeID is empty... I had to update the schema and explicitly ask for systemID, which is what we need.

[anmaxvl]

What is the use case here? Is user expected to connect to inside the UVM using the containerId? Can this be not satisfied through shimdiag exec into the UVM using the PodId?

The use case is a client/server application running on containerd host and server/client (respectively) running in a Xenon container communicating via HvSocket. shimdiag wouldn't be able to provide this type of communication.