No way to specify install location other than ~/.crc

[ghost]

General information

• OS: Windows
• Hypervisor: Hyper-V
• Did you run crc setup before starting it (Yes/No)? Yes

CRC version

Latest, 4.2.2

Host Operating System

Windows 10 Pro, latest updates as of Nov 18 2019

Problem:

I want to specify another directory to install CRC, since the current behavior is to install it under the user's home directory (in Windows, it would be C:\Users\User1.crc

Since we usually have limited space on the C:\ partition, I would like a way to specify another install directory or location, for example, D:\OpenShift\ where I would have a lot more space.

[rh-fr]

Hello, I suffer with exactly same issue. One difference I am on Ubuntu. Why was this ticket closed?

Thanks, Richard

[ghost]

Well no one did anything to address it. I resized my home directory under fedora, but this is very annoying for all operating systems. I reopened the ticket.

On Ubuntu there are many bugs, I don't think u can get it working unless u do many modifications manually to the networking portion.

You are better off with fedora 31 and install crc on it. That went smooth. Resize home directory to 100gb

[gbraad]

The binary at the moment can not operate on a drive other than C:, see: #764 This is likely due to an issue with libmachine (Minikube has the same issue in their top10. @tstromberg)

[gbraad]

Marking this as an enhancement.

[ghost]

The issue applies to all linux (and probably macOS) flavors. the crc config should be able to support a different destination, whether a different drive or partition

[cfergeau]

Just to be clear, what you want to put in a different location are the big files crc creates/needs, if ~/.crc has a reasonable size (a few MB at most), it's ok to have it?

[rh-fr]

Would be great to move big files from cache and machines directory, this is how looks my .crc

du -sh ~/.crc/*
92M	./.crc/bin
11G	./.crc/cache
4,0K	./.crc/crc.json
24K	./.crc/crc.log
8,3G	./.crc/machines

[lakgani]

On windows I am able to override the homedrive(~) by issuing $env:HOMEDRIVE="D:" (in powershell) before running crc setup in the same session.

[gbraad]

@lakgani what behaviour do you see now?

[nekator]

I also suffer from this issue. I have an Windows 10 Laptop and my user account has its homedrive configured as network drive with limited storate and a slow connection (compared to local drive).

[lakgani]

@gbraad Which version do you want me to give it a try?

[gbraad]

Override homedrive before running crc. Please report if that helped.

[lakgani]

@gbraad Yes it worked, that is the reason I posted my initial comment to help anyone that might need this behaviour

[Daemoen]

On Linux, pre-installation, create the directory where you want it installed. Assign your user as the owner. Once assigned, symlink ~/.crc to the chosen directory.

On windows, you may be able to use mklink (windows version of symlink). I haven't tested the windows mklink solution yet, but the Linux method of symlink pre-installation does work just fine.

Edit: Macos should be able to use the same solution as Linux above, since it is still 'nix' based.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[faysou]

I managed to use a different drive in Windows for the installation.

Using @Daemoen idea I created a symbolic link like this: mklink /J C:\Users\UserName\.crc E:.crc (make sure C:\Users\UserName\.crc doesn't exist before creating the link but E:.crc in this example must exist before creating the link)

Also make sure the crc.exe is executed somewhere on the C: drive.

[cameronkerrnz]

Can this workaround please be added to the Known Issues, rather than just saying its a known issue?

First ensure that .crc is not left-over in your home directory.

Then run this from an elevated powershell session (required for creating symbolic link)

Write-Host "Creating local application dir ${env:LOCALAPPDATA}"
New-Item -ItemType Directory -Path "${env:LOCALAPPDATA}\CodeReadyContainers"
New-Item -ItemType Directory -Path "${env:LOCALAPPDATA}\CodeReadyContainers\cache"
New-Item -ItemType Directory -Path "${env:LOCALAPPDATA}\CodeReadyContainers\machines"
New-Item -ItemType Directory -Path ${env:USERPROFILE}\.crc
New-Item -ItemType SymbolicLink -Path ${env:USERPROFILE}\.crc\cache -Target ${env:LOCALAPPDATA}\CodeReadyContainers\cache
New-Item -ItemType SymbolicLink -Path ${env:USERPROFILE}\.crc\machines -Target ${env:LOCALAPPDATA}\CodeReadyContainers\machines

I would suggest creating ${env:LOCALAPPDATA}\CodeReadyContainers\bin and putting crc.exe in there too, just to help ensure that its on the same volume as SystemDrive.

New-Item -ItemType Directory -Path ${env:LOCALAPPDATA}\CodeReadyContainers\bin
Move-Item ~\Downloads\crc-windows-1.24.0-amd64\crc.exe ${env:LOCALAPPDATA}\CodeReadyContainers\bin\

Type Windows "Edit Windows environment variables for your account", and add the following as one of the locations within your PATH environment variable for your account

%LOCALAPPDATA%\CodeReadyContainers\bin

When you save that, you should be able to start a new powershell session and run the following command:

Get-Command crc

(this is similar to the shell command 'which' in Bash)

Remember to run crc as non-admin user.

[cameronkerrnz]

Also; I don't know if this is some GPO-related weirdness with my local environment, but I notice on my new Windows 10 laptop that when I'm online at work, my HOME (literally $HOME in powershell) directory appears to be H:\ ... but when I'm offline its the same as what env:USERPROFILE is.

This is apparently normal according to https://superuser.com/questions/607105/is-the-home-environment-variable-normally-set-in-windows

No, it is not. The closest equivalents in Windows NT are %UserProfile% and %HomeDrive%%HomePath% (note that they may point to different locations – the profile is always local, while the home can point to a network share).

So I would suggest that the most appropriate location for .crc on Windows would be under %UserProfile%, if its not already (because I see I had both H:.crc and C:\Users\ME.crc ... which is confusing, but possibly normal?

[gbraad]

Also make sure the crc.exe is executed somewhere on the C: drive.

Due to limitations in the driver and jow Hyper-V treats the virtual machine files, we can not rely on these environment variables and are forced to use the drive that contains the OS.

We might looking into this again, but we consider a baseline as this impacts our testing. (Is this in that case would become a semi-supported option).

[cameronkerrnz]

My experience with CRC (1.24, and earlier in January with OKD) thus far would suggest that if its not already a tested environment then a managed (domain-joined) Windows 10 Pro/Enterprise that has a) roaming profiles, b) GPO-managed firewall (with local firewall rules ignored for better documentation outcomes) in an online ($HOME is $HOMEDRIVE$HOMEPATH) and disconnected state ($HOME == %UserProfile%) should be a regularly tested environment. Granted, that would need some infrastructure to help set up.

I'm not entirely sure why, but the laptops I have tried this with are unworkable without vsock mode (plus I'll need to be able to use the VPN when working from home, although on one of my laptops I hadn't installed the VPN at that stage). So I'm looking forward to seeing further development with this.

This would be representative of an developer / deployer / engineer working in an enterprise / commercial environment (assuming they don't have a different environment for their regular development, which would by likely because CRC resource requirements are unlikely to be met on most developer laptops I've seen).

Just looking at the 2020 Stack Overflow Developer Survey (https://insights.stackoverflow.com/survey/2020#development-environments-and-tools) about half of developers are using Windows.... it would be interested to see what proportion of that have managed devices. I wonder if you can infer that from CRC telemetry data (https://developers.redhat.com/article/tool-data-collection doesn't say explicitly)

Cheers, Cameron

[gbraad]

its not already a tested environment then a managed

At the moment we do not have a domain-joined test environment and some known issues for this are recorded.

are unworkable without vsock mode

this is likely because of the DNS setup. vsock will force the resolving over the the host itself. And yes, if you are using a VPN, you have to use vsock if a route-all is forced. The original setup with the virtual switch might become the alternative method soon-ish. We are in the process of moving vsock to become GA.

about half of developers are using Windows

We are aware of the disitribution, but so far our metrics for both download and usage show a slightly different usage ;-). We however do not record how systems are setup as we are cautious about collecting info that might be regarded as identifying.

[outcoldman]

Edit: Macos should be able to use the same solution as Linux above, since it is still 'nix' based.

It does not work that way if the volume is external /Volumes/DATA crc fails to start.

At the same time I am using minikube and it has ability to specify MINIKUBE_HOME that allows me to point to MINIKUBE_HOME=/Volumes/DATA/minikube