pillar/kvm: account vRAM for the container overhead limit

The commit d88091b ("New formula to estimate VMM memory overhead (x86)")
breaks the container case and does not account vRAM, which can be set to a big
value, which causes QEMU process to be killed by the OOM killer.

This patch removes the `IsOCIContainer()` check, which makes the default
estimation path to be taken and eventually this amount of overhead limit
should be set for all the cases (vms and containers):

    350Mb (undefined mappings) +
    20Mb (QEMU binaries mappings) +
    3Mb * nvCPUs (vCPU stacks) +
    0 (MMIO regions, which presumably 0 if no direct attach) +
    vRAM * 0.25

So for a minimal reasonable container configuration with 4 vCPUs and
500Mb of vRAM, without PCI devices direct attach the overhead limit
will be set to ~500Mb, which should be safe.

What is the other motivation to increase the value from 100Mb/300Mb
to 500Mb for the container case rather than vRAM accounting? We notice
increased number of customer issues on the latest EVE versions, when
QEMU process was killed by the OOM killer.

Signed-off-by: Roman Penyaev <[email protected]>

pkg/pillar/hypervisor/kvm.go

@@ -461,21 +461,7 @@ func (ctx kvmContext) Task(status *types.DomainStatus) types.Task {
 	return ctx
 }
 
-func isArchARM() bool {
-	return runtime.GOARCH == "arm64"
-}
-
 func estimatedVMMOverhead(domainName string, config types.DomainConfig, aa *types.AssignableAdapters) (int64, error) {
-	// Container limit is set to 100MiB for x86 and 300 for ARM.
-	// This is a temporary solution until we have a better way to predict
-	// the memory usage of the container.
-	if config.IsOCIContainer() {
-		if isArchARM() {
-			return 300 << 20, nil // Mb in bytes
-		}
-		return 100 << 20, nil // Mb in bytes
-	}
-
 	var overhead int64
 
 	mmioOverhead, err := mmioVMMOverhead(domainName, config, aa)