Hyper-v: "hv_balloon: Memory hot add failed"

[jon-walton]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report

Minikube version (use minikube version): 0.18

Environment:

• OS (e.g. from /etc/os-release): Windows 10 Pro build 15063.138
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): hyperv
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): 0.18.0 (also tested on 1.0.7)
• Install tools:
• Others:

What happened: The hyperv virtual machine is created with memory ballooning enabled. As I add more pods to kubernetes, I expected the host OS to assign more memory to the VM. Instead, the message "hv_balloon: Memory hot add failed" is printed to the vm console. Eventually my pods / kubernetes services are killed by the OOM killer

What you expected to happen: As memory pressure increases inside the VM, I expect memory ballooning to give the VM more memory.

How to reproduce it (as minimally and precisely as possible):

• Enable HyperV on a Windows 10 Pro build
• Create a new external hyperv switch (call it minikube for this example)
• minikube start --vm-driver hyperv --hyperv-virtual-switch minikube
• deploy lots of kubernetes pods
• monitor the vm console for "hv_balloon: Memory hot add failed", monitor the hyperv console and see the memory demand increase, memory status change to "warning" but assigned memory not increasing

Anything else do we need to know:

[dlorenc]

It looks like hot add is not currently supported on Linux:
http://lxr.free-electrons.com/source/drivers/hv/hv_balloon.c#L347

Have you seen this work elsewhere?

[jon-walton]

It's worked on Ubuntu since 14.04 (https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-ubuntu-virtual-machines-on-hyper-v) and centos 7. I guess the functionality is provided by additional packages?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close