minikube: kvm2: minikube start fails after host reboot: "network 'minikube-net' is not active'

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

bug

Environment:

Minikube version (use minikube version):

0.25

  • OS (e.g. from /etc/os-release): Fedora 26
  • VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName):

kvm2

  • ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION):
  • Install tools:
  • Others: The above can be generated in one go with the following commands (can be copied and pasted directly into your terminal):
minikube version
echo "";
echo "OS:";
cat /etc/os-release
echo "";
echo "VM driver": 
grep DriverName ~/.minikube/machines/minikube/config.json
echo "";
echo "ISO version";
grep -i ISO ~/.minikube/machines/minikube/config.json

What happened:

minikube start --vm-driver=kvm2

Starting local Kubernetes v1.9.0 cluster… Starting VM… E0204 22:35:52.820568 30508 start.go:159] Error starting host: Error starting stopped host: Error creating VM: virError(Code=55, Domain=19, Message=‘Requested operation is not valid: network ‘minikube-net’ is not active’).

How to reproduce it (as minimally and precisely as possible): minikube start --vm-driver=kvm2

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 10
  • Comments: 23 (11 by maintainers)

Most upvoted comments

To resolve this:

Assuming you can access virsh do the following:

  1. Type virsh
  2. Type net-list --all - should see that minikube-net is inactive
  3. Type net-start minikube-net - should get an error message about “Network is already in use by interface virbr1” or similar
  4. Quit virsh
  5. Type sudo ifconfig virbr1 down
  6. Type sudo brctl delbr virbr1
  7. Type virsh
  8. Type net-start minikube-net - should now start-up
  9. Quit virsh
  10. Type minikube start

On Arch Linux I had to fix this with:

  1. sudo virsh
  2. net-start minikube-net
  3. quit
  4. minikube start --vm-driver=kvm2

The sudo was necessary for virsh to see the available networks via net-list --all, whereas other examples here seem to omit it.

I was able to resolve this on Fedora 27.

  1. run minikube start --vm-driver=kvm2
  2. let it fail
  3. switch to root
  4. start virsh
  5. under virsh, run net-edit default
  6. change network>bridge.name in the xml to virbr1 (or some other unoccupied address)
  7. save and quit
  8. under virsh, run net-start minikube-net
  9. exit root
  10. run minikube start --vm-driver=kvm2, this time it should succeed

The issue for me seems to stem from the minikube-net trying to also occupy virbr0, which is what default does naturally. Ideally, minikube-net should pick another default.

also virsh net-autostart minikube-net --> to have a persistent minikube-net over restarts

@mheese - Great news. Feel free to send the PR to myself.

In the mean time, I’m using this workaround the first time I run into it:

sudo virsh net-autostart minikube-net                                                                                                                                                                            
sudo virsh net-start minikube-net   

Surprisingly, I ran into this today with v0.30.0: worked around it by using minikube delete && minikube start. This appears to have been due to minikube expecting the previously configured VM to have a network.

My fix seems to work, will need to check in with my company to see how exactly I am allowed to create the PR (organization forked repo vs my private github forked repo for the PR).

if you have virt-manager package you can do: net-start minikube-net on the virsh shell or just use the virt-manager UI that comes with the package.

on the UI, go to menu Edit > Connection Details and on the resulting dialog box select the Virtual Network Tab. select minikube-net from the list and click the start button (the button with the play symbol at the bottom of the list) then click apply

I use archlinux so package name might be different. to start

I tried to duplicate this in v0.33.1, but I couldn’t across several reboots. I know there is a latent condition here somewhere, but I’m going to close this for now until we see it again and can root cause it appropriately.

Thank you @mheese!