Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Minikube version (use minikube version
): v0.12.2
Environment:
cat ~/.minikube/machines/minikube/config.json | grep DriverName
): kvmdocker -v
): 1.12.3What happened:
# minikube start \
--vm-driver=kvm \
--container-runtime=rkt
[... failed ...]
# sudo apt install libvirt-clients
[...]
# minikube start \
--vm-driver=kvm \
--container-runtime=rkt
[... failed ...]
# sudo apt install libvirt-daemon libvirt-daemon-system
[...]
[libvirtd could not access KVM, due to permission issues, thus:]
# reboot
[...]
# minikube start \
--vm-driver=kvm \
--network-plugin=cni \
--container-runtime=rkt \
--iso-url=http://storage.googleapis.com/minikube/iso/buildroot/minikube-v0.0.6.iso
Starting local Kubernetes cluster...
Downloading Minikube ISO
68.79 MB / 68.79 MB [==============================================] 100.00% 0s
E1118 13:37:13.086967 7590 start.go:92] Error starting host: Error creating host: Error creating machine: Error in driver during machine creation: [Code-55] [Domain-19] Requested operation is not valid: network 'default' is not active. Retrying.
E1118 13:37:13.087235 7590 start.go:98] Error starting host: Error creating host: Error creating machine: Error in driver during machine creation: [Code-55] [Domain-19] Requested operation is not valid: network 'default' is not active
================================================================================
An error has occurred. Would you like to opt in to sending anonymized crash
information to minikube to help prevent future errors?
To opt out of these messages, run the command:
minikube config set WantReportErrorPrompt false
================================================================================
Please enter your response [Y/n]:
Please note that I never get a chance to actually respond to the "report error" question. The console prompt was already flashing on the next line, which leads me to believe that the report was sent without my consent.
What you expected to happen:
Minikube should have started Kubernetes using KVM and created any missing networks.
How to reproduce it (as minimally and precisely as possible):
Hopefully the information given above is enough to reproduce it on a Debian 9.0 "Stretch" installation.
Anything else do we need to know:
There appear to be no networks configured in libvirt right now:
# virsh net-list
Name State Autostart Persistent
----------------------------------------------------------
Using virt-manager
, I started the default
network (virt-manager > edit > connection details > virtual networks > default) and enabled it start on boot.
That seemed to solve the issue somewhat: After repeatedly trying minikube start ...
, followed by minikube delete
and deleting ~/.minikube
several times, I finally have a working minikube installation.
Thanks for sharing your solution here. We should add this to our documentation for Debian with KVM. Are you interested in sending a PR?
I'm not sure whether this is a solution or a workaround. Is it possible for minikube to enable the default
network before trying to use it, in case it is currently disabled? That way the experience would be more "automatic" / "works out of the box".
Ah that makes more sense. Thanks for the explanation. Yeah, we should try to fix this. The relevant code is here: https://github.com/dhiltgen/docker-machine-kvm/blob/master/kvm.go#L284
It looks like it sets the network to auto start, but maybe "active" is different than started? @r2d4 have you looked into this at all?
Also note that I have two networks visible in virt-manager
now: default
and docker-machines
. docker-machines
was set to auto start and was active when I looked at it. default
was neither active nor set to auto start.
Is it possible that one network is properly activated, but this is missing for the other? Maybe the calls to SetAutoStart(true)
and Create()
(after LookupNetworkByName(...)
) should also be present in validateNetwork(...)
, just like they are in validatePrivateNetwork()
?
This is a known issue upstream in the kvm-driver https://github.com/dhiltgen/docker-machine-kvm/issues/24#issuecomment-249050583
The docker-machine private network _is_ managed by the driver
https://github.com/dhiltgen/docker-machine-kvm/blob/master/kvm.go#L261-L263
I don't see any reason why we can't create our own network instead of using the default and manage that.
The docker-machine private network is managed by the driver
Apologies if that was not clear from my last post. "One network [that] is properly activated" refers to the "docker-machines" network, while "the other" refers to the "default" network.
I don't see any reason why we can't create our own network instead of using the default and manage that.
This seems possible: https://github.com/dhiltgen/docker-machine-kvm/blob/master/kvm.go#L115
I would assume, though, that it is simpler to fix dhiltgen/docker-machine-kvm#12, if it can be fixed in the way I described in my last comment. Thanks for finding me the upstream bug, I'll suggest the fix there.
First time users need currently do:
virsh net-autostart default
virsh net-start default
@cruftex's suggestion works for me (I was previously doing a much more roundabout fix). Can it be included in the driver documentation?
FYI I also see issues with virsh net-start default
and have to bring down virbr0
.
$ sudo virsh net-start default
error: Failed to start network default
error: error creating bridge interface virbr0: File exists
$ sudo ifconfig virbr0 down
$ sudo brctl delbr virbr0
$ sudo virsh net-start default
Network default started
To restore the default network when something went b0rked, please do:
virsh net-undefine default
virsh net-destroy default
virsh net-list
virsh net-define /usr/share/libvirt/networks/default.xml
virsh net-start default
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.
Prevent issues from auto-closing with an /lifecycle frozen
comment.
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
/remove-lifecycle stale
I saw this issue with minikube v0.25.0 and --vm-driver=kvm2 on a Debian Buster-like-system.
virsh net-autostart default
failed with:
error: failed to get network 'default'
error: Network not found: no network with matching name 'default'
But with virt-manager
I was able to start and enable-autostart for default
, and then minikube start --vm-driver=kvm2
worked correctly.
EDIT: sudo virsh net-autostart default
seems to work. id | grep virt
shows I'm in libvirt and libvirt-qemu so group membership isn't the issue.
Lots of great tips in here, but my system (new Manjaro install) was even more raw, not even including the default.xml file from the libvirt source.
Cribbing off of previous suggestions, the following worked for me:
virsh net-define <(curl -s https://raw.githubusercontent.com/libvirt/libvirt/v4.0.0/src/network/default.xml)
virsh net-autostart default
sudo virsh net-start default
still experiencing this issue with v0.28.0
minikube delete; minikube start --vm-driver=kvm2 --cpus=2 --memory=4096
Deleting local Kubernetes cluster...
Machine deleted.
Error deleting machine profile config
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
E0620 08:43:55.867918 8843 start.go:168] Error starting host: Error creating host: Error creating machine: Error in driver during machine creation: creating network: checking network default: virError(Code=43, Domain=19, Message='Network not found: no network with matching name 'default'').
Retrying.
E0620 08:43:55.868926 8843 start.go:174] Error starting host: Error creating host: Error creating machine: Error in driver during machine creation: creating network: checking network default: virError(Code=43, Domain=19, Message='Network not found: no network with matching name 'default'')
If you have Virtual Machine Manager.. Just start the KVM default network
Go to Edit>Connection Details> Virtual Networks
select "default" network & go to the bottom and click the play icon.
Or second option, if you want to run through CLI :
You have to use the **virsh pool-create** command and add an xml file for the default network. The XML file will be similar to the default.xml file on the network connection details configured by KVM.
My suggestion, for best practices. Use the first option unless you want to manage the file paths of all your default virtual connections. Let the KVM application map and manage all the configuration files.
Most helpful comment
First time users need currently do:
virsh net-autostart default virsh net-start default