Minikube: hyperv: Default to disabling dynamic memory (pass --hyperv-disable-dynamic-memory to driver)

[AceHack]

I keep running into issues the first time I do minikube start with kubeadm and hyper-v. It seems to be releated to dynamic memory. I can stop things, disable dynamic memory, then restart but I think it's messed up by then. I'm tyring to work though it now.

[kwaazaar]

I can confirm that dynamic memory enabled causes problems. Everything starts fine, but after a while it just stops working. See my own issue here: https://github.com/kubernetes/minikube/issues/2298

[alexandervantrijffel]

It would be nice if minikube start supports an option to disable dynamic memory for hyper-v.

[shahiddev]

Hi, I've been bitten by this problem a few times so would like to implement this.
I'm having a few issues trying to build the source code (wsl on Windows machine), trying to follow the contrib guide.
I'm at Kubecon, if someone could give me a few pointers that would be awesome, I'm probably just being a noob :/

[dlorenc]

I'm here as well, come by the Minikube Intro session this afternoon and we can get your build sorted out :)

[shahiddev]

Fantastic, I am attending that session and was going to ask you :-)

[dlorenc]

Hey @shahiddev, could you try doing the build with:

MINIKUBE_BUILD_IN_DOCKER=y make

My guess is that we're not building in docker because WSL looks like linux, but it doesn't look enough like it to actually work. That flag should force the build to run in a container.

[shahiddev]

Hi @dlorenc that still fails

shahid@SI-SP4:~/projects/go/src/k8s.io/minikube$ MINIKUBE_BUILD_IN_DOCKER=y make
docker run --rm -e IN_DOCKER=1 --user 1000:1000 -w /go/src/k8s.io/minikube -v /home/shahid/projects/go:/go --entrypoint /bin/bash k8s.gcr.io/kube-cross:v1.9.1-1 -c '/usr/bin/make out/minikube-linux-amd64'
make: *** No rule to make target 'out/minikube-linux-amd64'.  Stop.
Makefile:120: recipe for target 'out/minikube-linux-amd64' failed
make: *** [out/minikube-linux-amd64] Error 2

[dlorenc]

Ah, that error usually has something to do with the volume mounts to the docker container not working correctly. I'm not terribly familiar with WSL or Docker for Windows, but my guess is that the part of the command:

-v /home/Shahid/projects/go:/go

isn't working correctly. Do you know how Docker for Windows mounts work with WSL? Essentially we need the minikube directory from your laptop mounted into the container at /go.

[shahiddev]

Thanks, that's a useful hint, I can dig a bit deeper to figure that out.
I'll update the docs once I get to the bottom of it.

[shahiddev]

Seems like I can get minikube building in the Windows Subsystem for Linux now without needing to use the docker approach.

I'm trying to build the Windows binaries using GOOS=windows make which isn't working, is this the correct way to build the windows binaries? Output I get is this:

$ GOOS=windows make
make: *** No rule to make target 'out/minikube-windows-amd64".exe"', needed by 'out/minikube".exe"'.  Stop.

[shahiddev]

I got a way to test what I've been doing that's fine for now.

I have a question about best approach for implementing.
At the moment I'm implementing this as an optional flag to disable the dynamic memory option, this way current behaviour is unchanged, I would prefer to enable it by default but feels like giving the option for disable first is better before making a potentially breaking change by setting the default to be disabled.

Does that sound like a sensible approach?

[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

[shahiddev]

/remove-lifecycle stale

[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

[AceHack]

Please keep active

[pbuhrmann]

This would be really useful, I'm going through this right now too

[chrislyonod]

/remove-lifecycle rotten

[tstromberg]

I'd never heard of dynamic memory before, but read up a little on it:

https://blogs.technet.microsoft.com/virtualization/2015/05/26/when-to-use-hyper-v-dynamic-memory-versus-runtime-memory-resize/

I don't know much about HyperV, but I would definitely be happy to help someone implement this if they want to tackle it. It seems like the --hyperv-disable-dynamic-memory option is supported already by the hyperv driver:

https://docs.docker.com/machine/drivers/hyper-v/#4-create-the-nodes-with-docker-machine-and-the-microsoft-hyper-v-driver

[tstromberg]

Dupe of #1766