crc setup before starting it YEScrc version: 1.3.0+918756b
OpenShift version: 4.2.10 (embedded in binary)
CRC VM: Stopped
OpenShift: Stopped
Disk Usage: 0B of 0B (Inside the CRC VM)
Cache Usage: 24.92GB
Cache Directory: C:\Users\Ozzy\.crc\cache
- cpus : 6
- memory : 32768
OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.18362 N/A Build 18362
OS Manufacturer: Microsoft Corporation
When CRC isn't running, it shouldn't be screwing up the platforms dns resolution.
CRC's adding of a DNS Server to the default virtual switch means every DNS lookup tries to go to the CRC ip (192.168.75.246 in my case) .. which is only available when CRC is running. This lookup adds noticeable seconds to DNS resolutions, and seems to cause issues with Maven/Docker builds that expect DNS lookups to occur in a timely manner.
Removing the DNS entry via the network connections panel with start/run/ncpa.cpl and right clicking vEthernet (Default Switch), double click Internet Protocol Version TCP/IP v4, and removing the ip address from the 'Use the following DNS server addresses' box, restored normal DNS behavior to my system.
We are aware of this. Still looking into a solution that might not need the local DNS resolution configured on the interface.
Any chance of an update in the docs somewhere to help mitigate the impact of this until it's resolved? It took me quite a while to figure out what CRC had done, so I could undo it.
The impact is quite nasty, as it affects the developers machine even if they remove CRC.
A possible solution might be to run dnsmasq in it's own tiny vm, independent of crc, allowing that vm to remain operational even while crc is stopped ?
running an additional VM would use resources we prefer not to waste. We considered this for Minishift and decided not to after tests. The alternative would have been to run CoreDNS, but this has proven to be unstable.
A reboot should have resolved the issue, right?
Does Restart-NetAdapter [0] reset these values?
[0] := https://docs.microsoft.com/en-us/powershell/module/netadapter/restart-netadapter
I think it鈥榮 not the right way to change the configuration of the default switch (which is the default switch for new Hyper-V machines). Out of the box the CodeReady VM is also very resource hungry and I think one will only have it running when needed.
What about adding a special vSwitch only for the usage of CRC?
@gbraad Didn't try a reboot.. once I'd figured out what CRC did to the default switch, I just undid it by hand via the UI. I'll just need to remember to reverse that whenever I actually need to run CRC (or automate it via some wrapper scripts.. but it's enough of a disincentive to use CRC that maybe I'll just go back to kube in docker for now).
@aguther I think the CRC installer already supports using it's own switch, but you have to create one called 'crc' before you do the install, at least I saw the code doing something like that, even if there doesn't appear to be docs saying why you'd want to do it, or how.
Using a crc named switch is part of a test for windows 10 enterprise. He haven't finalized the setup code and docs. But yes, this works as an alternative. For Pro/Home you either need to bridge a network segment that offers a dhcp server or manually add one to an internal switch.
Facing the issue and after crc is stopped, minishift/cdk is unable to start.
@jeffmaury @jeffsaremi Can you try Set-DNSClientServerAddress "vEthernet (Default Switch)" -ResetServerAddresses after stopping the VM ?
@gbraad
Yes the mentioned command fixed my problem. I just had to run it in an admin shell
Fixed with #1155
Hello, I'm still experiencing this issue with the latest CRC version.
Edit: Sorry I didn't realize this was specifically for after CRC is Stopped, I meant that I'm experiencing slow DNS resolution while CRC is running. I'll look for a different issue.
crc version
CodeReady Containers version: 1.12.0+6710aff
OpenShift version: 4.4.8 (embedded in binary)
crc status
CRC VM: Running
OpenShift: Running (v4.4.8)
Disk Usage: 12.89GB of 32.72GB (Inside the CRC VM)
Cache Usage: 14.81GB
Cache Directory: XXX
crc config
- cpus : 4
- memory : 16384
- pull-secret-file : XXX
os
OS Name: Microsoft Windows 10 Enterprise
OS Version: 10.0.19041 N/A Build 19041
hey @gbraad i'm trying to sort through this issue - i ran Set-DNSClientServerAddress "vEthernet (Default Switch)" -ResetServerAddresses but after I did this, now I cannot use crc anymore. It fails to find the dns entries.
Is there a "turn dns back on for openshift" powershell command I can run?
That way I can turn on the dns changes when i want to use crc, and turn them off again when I no longer want them? thanks.
I tried to crc cleanup && crc setup && crc start but now the installer hangs here:
鈮> crc setup
INFO Checking if oc binary is cached
INFO Checking if podman remote binary is cached
INFO Checking if goodhosts binary is cached
INFO Checking if CRC bundle is cached in '$HOME/.crc'
INFO Checking minimum RAM requirements
INFO Checking if running as normal user
INFO Checking Windows 10 release
INFO Checking Windows edition
INFO Checking if Hyper-V is installed and operational
INFO Checking if user is a member of the Hyper-V Administrators group
INFO Checking if Hyper-V service is enabled
INFO Checking if the Hyper-V virtual switch exist
INFO Found Virtual Switch to use: Default Switch
Setup is complete, you can now run 'crc start' to start the OpenShift cluster
鈮> crc start
WARN A new version (1.19.0) has been published on https://cloud.redhat.com/openshift/install/crc/installer-provisioned
INFO Checking if oc binary is cached
INFO Checking if podman remote binary is cached
INFO Checking if goodhosts binary is cached
INFO Checking minimum RAM requirements
INFO Checking if running as normal user
INFO Checking Windows 10 release
INFO Checking Windows edition
INFO Checking if Hyper-V is installed and operational
INFO Checking if user is a member of the Hyper-V Administrators group
INFO Checking if Hyper-V service is enabled
INFO Checking if the Hyper-V virtual switch exist
INFO Found Virtual Switch to use: Default Switch
? Image pull secret [? for help] ******************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
INFO Loading bundle: crc_hyperv_4.6.1.crcbundle ...
INFO Checking size of the disk image C:\Users\nicho\.crc\cache\crc_hyperv_4.6.1\crc.vhdx ...
INFO Creating CodeReady Containers VM for OpenShift 4.6.1...
INFO CodeReady Containers VM is running
INFO Generating new SSH Key pair ...
INFO Updating authorized keys ...
INFO Copying kubeconfig file to instance dir ...
INFO Starting network time synchronization in CodeReady Containers VM
INFO Will run as admin: add dns server address to interface vEthernet (Default Switch)
INFO Check internal and public DNS query ...
Hangs at INFO Check internal and public DNS query ... indefinitely.
So I go back and try again crc start and now it says it's started, but the dns resolution of api.crc.testing fails still.
@nddipiazza Latest crc introduces a new network mode that should fix your issue. Can you try https://github.com/code-ready/crc/wiki/VPN-support--with-an--userland-network-stack ? Thanks.
Sure! Trying it now. @guillaumerose
OK ran the instructions. I have openshift up and running and dns appears to be resolving quickly.
No issues as of this time.
Most helpful comment
@gbraad
Yes the mentioned command fixed my problem. I just had to run it in an admin shell