Runtime: virtcontainers: Make sandbox manage VM CPUs.

[jcvenegas]

Today the VCPUS resources are managed by the container.go in virtcontainers API but the VM resources should be managed by the sandbox. The container only is reponsible to update namespaces and cgroups.

[jodh-intel]

I think you just won the "issue with the longest title award" @jcvenegas - :trophy: :fireworks:

[jingxiaolu]

I agree with what @jcvenegas suggests. If we do it so, I think we've also got the solution of discussion_r224051455 @WeiZhang555

[WeiZhang555]

@jodh-intel Definitely! :laughing:

[jcvenegas]

@jodh-intel @Weichen81 lol thanks for the award, @jingxiaolu I reworked the sandbox resources in https://github.com/kata-containers/runtime/pull/793

[egernst]

duplicate of https://github.com/kata-containers/runtime/issues/743

I think the main takeaway from #743 is that the current logic results in too many vCPUs being allocated to the virtual machine.

[egernst]

@WeiZhang555 @jcvenegas I agree -- vCPU should be handled at Sandbox level, not at container level.

Having said this, I think it still makes sense to track CPUs requested in the context of containers, since we will still constrain in the VM here, and since we may have specific cpusets which we'll want to maintain at the container level (see https://github.com/kata-containers/runtime/issues/878).

Also, without tracking on a per container basis, I'm not sure if we'll know the delta in mCPUs from what was originally requested. As an example, let's say we get an UpdateContainer call from CRI-level, and for container foo it requests 500m for CPU.

We don't know what foo had originally, so how can we know what additional vCPU requirements we have now? It could be +400m (original was 100m), +100m (original was 400m) or -2000m (original was 2500m).

In summary, I think we need to keep track of the resources on a per container basis, but should pool this together when making and changes to QEMU.

[WeiZhang555]

In summary, I think we need to keep track of the resources on a per container basis, but should pool this together when making and changes to QEMU.

Yes, we need to track this. Currently kata saves container OCI config.json so I think this is possible. @egernst