Minikube: Allow users to specify a VM disk location for HyperV

[odytrice]

Feature Request

There should be an extra flag something like --hyperv-vm-disklocation such that you can specify where you want the VMdisk to be located. This is because the C:\ might not always have enough space. Or at the very least have an option to let hyperv create the vmdisk similar to what docker for windows does, this way one could configure the VMDisk location from Hyper-V

Please provide the following details:

Environment:
Minikube version:

• v0.28.2
• hyperv

[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

[tstromberg]

This sounds like a reasonable idea, and I would be happy to review or assist if anyone wants to attempt implementing it.

[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

[FranklinYu]

/remove-lifecycle stale

[blueelvis]

@tstromberg - I would like to pick this up. Could you please tell me where I should start for this? I would be happy to work my way from there :)

[tstromberg]

I'm not sure honestly. We control where the ISO is downloaded to in util.GetISOCacheFilepath, but that does not control the location of the VM state. I'm not actually sure how to go about configuring the latter in hyperv.

[FranklinYu]

@blueelvis I know nothing about Go, but I guess it’s here:

https://github.com/kubernetes/minikube/blob/2d85a7ffbcd0545e2777a802894fcc924d197c3c/pkg/minikube/drivers/hyperv/driver.go#L41

The “mini path” seems to be it. Also the virtual disk format is VHD.

[blueelvis]

@FranklinYu - Thanks for the information. I will work on this next.

/assign

[k8s-ci-robot]

@blueelvis: GitHub didn't allow me to assign the following users: blueelvis.

Note that only kubernetes members and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

@FranklinYu - Thanks for the information. I will work on this next.

/assign

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[gbraad]

libmachine does not alow the diskmachine to be used in any place other than
WINDIR. if the VM disk is not on this disk, the startup will fail. In other
words, a possible modification in libmachine might be needed, but to be
honest I do not remember the details of this anymore. Note: In a few days
perhaps I might look into this for use with the minishift successor 'CRC'

On Tue, May 28, 2019 at 10:14 PM Kubernetes Prow Robot <
[email protected]> wrote:

@blueelvis https://github.com/blueelvis: GitHub didn't allow me to
assign the following users: blueelvis.

Note that only kubernetes members
https://github.com/orgs/kubernetes/people and repo collaborators can be
assigned and that issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide
https://git.k8s.io/community/contributors/guide/#issue-assignment-in-github

In response to this
https://github.com/kubernetes/minikube/issues/3084#issuecomment-496535249
:

@FranklinYu https://github.com/FranklinYu - Thanks for the information.
I will work on this next.

/assign

Instructions for interacting with me using PR comments are available here
https://git.k8s.io/community/contributors/guide/pull-requests.md. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:
repository.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/minikube/issues/3084?email_source=notifications&email_token=AAAAOZV6TUQCKEIPXDHBBA3PXU45VA5CNFSM4FQJ2L72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWMINYI#issuecomment-496535265,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAAOZRVOX3DFJCLRNZXPVLPXU45VANCNFSM4FQJ2L7Q
.

--

Gerard Braad | http://gbraad.nl
[ Doing Open Source Matters ]

[blueelvis]

From what I saw in the code, it seems that if a value is passed instead of constants.GetMiniPath(), it should pick it up. But, let me try it as well.

[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

[FranklinYu]

/remove-lifecycle stale

[tstromberg]

AFAIK, this is still a thing in minikube v1.4.

[medyagh]

I believe we stil have this issue v1.6.1

[JoshuaCWebDeveloper]

I came across this issue while trying to figure out how I could move the Minikube HyperVM disk off of my C:\ drive in order to save space.

This is what ended up working for me, and may be a suitable workaround for others who are waiting for this feature:

1. Stop minikube if it is running
2. Open up the Hyper-V Manager app
3. Select the minikube virtual machine
4. In the right hand actions menu, select "Move..."
5. Follow the wizard, when I did it, I only had the option to move the data for the VM.
6. Start up minikube again, it should use the existing VM and relocated hard disk image

[FranklinYu]

@JoshuaCWebDeveloper This works if you’re careful. I vaguely recall that some commands will re-create the virtual machine (maybe modifying memory size or similar).

[odytrice]

@JoshuaCWebDeveloper like @FranklinYu pointed out, the problem (If I'm not mistaken) is that stopping and starting minikube will recreate the the VM in the old location

[JoshuaCWebDeveloper]

@odytrice Well merely stopping and starting minikube certainly didn't re-create the vm for me. When I do minikube stop and then minikube start it correctly re-uses the existing VM and doesn't attempt to create a new one. But I'm sure that, as @FranklinYu says, there are commands that could result in the virtual drive being moved back to the original location (certainly if someone deleted and re-created the cluster, I'm sure that would happen).

[tstromberg]

Rather than introducing a per-hypervisor flag, I believe the best solution here is for users to set the MINIKUBE_HOME environment variable:

https://minikube.sigs.k8s.io/docs/reference/environment_variables/

I do recommend running minikube delete --all before changing your environment variable around, as minikube will no longer be able to see the old VM's.

[JoshuaCWebDeveloper]

The MINIKUBE_HOME variable would allow a user to move all their minikube clusters to an external drive (or other custom location). However, what this issue seems to ask for is the ability to just move a single minikube cluster. Indeed, whether I am working with HyperV, VirtualBox, Vagrant, or in this case Minikube, I will often prefer to have machines in multiple locations based on my requirements (e.g. small vms on C:\, large ones on an external disk).

The point about "introducing a per-hypervisor flag" is a good one and make sense. However, I don't necessarily see why it would have to be a per-hypervisor flag. Yes, this issue calls for something like --hyperv-vm-disklocation, but I would imagine this use case would also exist for users of VMWare, VirtualBox, or even vm-driver=none. A flag called something like --vm-location (or even --vm-disk-location, though that wouldn't apply in all cases) would allow users of HyperV or other virtualization platforms to specify a custom location for a specific cluster. It would also eliminate the problem of a hypervisor-specific flag.

I would urge the maintainers to reconsider the closing of this issue.

[dfad1ripe]

This issue exists with VirtualBox too.

Though I have default VM location at D:\VM, minikube creates new VM under %HOMEDIR%\.minikube\machines.

Instead, minikube should at least read %HOMEDIR%\.VirtualBox\VirtualBox.xml and use the value of .VirtualBox.Global.SystemProperties['defaultMachineFolder'].

Adding a startup parameter to override this path would be great too.

Meanwhile, a workaround with MINIKUBE_HOME env variable works with VirtualBox.