Support adding mount to running containers

[kiashok]

This PR adds hcsshim support to mount host volumes/directories to running windows containers.

HCS supports mounting host volumes/directories to running windows containers by modifying the hcs compute system with ResourcePath of Containers/MappedDirectories. These changes leverage this by extending the hcsTask.Update() function to process and add mounts for running process isolated and hyperV windows containers.

[helsaawy]

Can we not rely on (*UtilityVM) Share and add an analogous function to internal/hcs.System?
Id rather not bring HCS specifics into cmd

[kiashok]

Can we not rely on (*UtilityVM) Share and add an analogous function to internal/hcs.System? Id rather not bring HCS specifics into cmd

what HCS specifics are you referring to? task_hcs.go is already sending ht.c.Modify() modify requests for updating CPU and memory resources.

[kiashok]

cc @kharpMSFT

[helsaawy]

what HCS specifics are you referring to? task_hcs.go is already sending ht.c.Modify() modify requests for updating CPU and memory resources.

the logic in updateWCOWContainerMount; we already have it implemented in uVM code, and (aside for portions of the update and properties/stats code for hcsTask), most of the HCS schema creation logic is pushed to hcsoci or elsewhere instead of in cmd\containerd-shim-runhcs-v1

[kiashok]

what HCS specifics are you referring to? task_hcs.go is already sending ht.c.Modify() modify requests for updating CPU and memory resources.

the logic in updateWCOWContainerMount; we already have it implemented in uVM code, and (aside for portions of the update and properties/stats code for hcsTask), most of the HCS schema creation logic is pushed to hcsoci or elsewhere instead of in cmd\containerd-shim-runhcs-v1

The uvm.Share() function seems to be slightly different. It is sending a request with a different resource path type and is also a common code path and is not adding the share to release resource that is being mounted (not sure why this is ) . I think it would be better to have the mounting logic for running containers exclusive to this add-mount logic file as a non-exportable function if possible.

[kiashok]

what HCS specifics are you referring to? task_hcs.go is already sending ht.c.Modify() modify requests for updating CPU and memory resources.

the logic in updateWCOWContainerMount; we already have it implemented in uVM code, and (aside for portions of the update and properties/stats code for hcsTask), most of the HCS schema creation logic is pushed to hcsoci or elsewhere instead of in cmd\containerd-shim-runhcs-v1

The uvm.Share() function seems to be slightly different. It is sending a request with a different resource path type and is also a common code path and is not adding the share to release resource that is being mounted (not sure why this is ) . I think it would be better to have the mounting logic for running containers exclusive to this add-mount logic file as a non-exportable function if possible.

@helsaawy Refactored the code a little to reuse some part of it from uvm.Share() in the second commit of this PR. But no sure this can entirely move out to internal/* though. Let me know what you think