Changing VM hardware (memory, cores) has no effect after provisioning

[blueelvis]

Pretty sure this would be the case with other drivers as well.
The exact command to reproduce the issue:

.\minikube-windows-amd64.exe start --vm-driver=hyperv --hyperv-virtual-switch="Default Switch" --memory=1700
.\minikube-windows-amd64.exe start --vm-driver=hyperv --hyperv-virtual-switch="Default Switch" --memory=1500 --cpus=1

The cluster initially gets provisioned with the memory and CPU but if I start it again with new parameters, the VM is just started with the original values as you can see from the below screenshot -

I think this should be configurable. The only thing which should not be configurable in size is the hard disk size.

The operating system version:
Windows 10 Enterprise.

Pretty sure this would be applicable across all drivers and all the operating systems.

[tstromberg]

I'm not sure if the machine drivers infrastructure allows on-the-fly hardware changing. I'm also not sure if there is a way we can detect whether the current VM has the correct hardware settings.

What we can do however is compare the current VM config with the previously saved one, and recreate the VM, preserving the new disk if at all possible. If preserving the disk isn't possible, we should prompt the user or require them to add a flag for deletion.

[afbjorklund]

Normally you would change this in the machine JSON file, and then restart the machine...

I think minikube could do the same thing with the config, after the Load but before the Save ?

[afbjorklund]

This probably depends a lot on the driver... Some create external config, some pass parameters.

If it does create an external object, then it does need the aforementioned synchronization step.

[sharifelgamal]

This is probably still worth looking at.

[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

[priyawadhwa]

Hey @blueelvis --

Hopefully it's OK if I close this - there wasn't enough information to make it actionable, and some time has already passed. If you are able to provide additional details, you may reopen it at any point by adding /reopen to your comment.

Here is additional information that may be helpful to us:

• Whether the issue occurs with the latest minikube release
• The exact minikube start command line used
• The full output of the minikube start command, preferably with --alsologtostderr -v=3 for extra logging.
• The full output of minikube logs

Thank you for sharing your experience!