kvm2
Overview
KVM (Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions. To work with KVM, minikube uses the libvirt virtualization API
Requirements
- libvirt v1.3.1 or higher
- qemu-kvm v2.0 or higher
Installing Prerequisites
Proper installation of KVM and libvirt is highly specific to each Linux distribution. Please consult:
Once configured, validate that libvirt reports no errors:
virt-host-validate
Usage
Start a cluster using the kvm2 driver:
minikube start --driver=kvm2
To make kvm2 the default driver:
minikube config set driver kvm2
Check virtualization support
To use VM drivers, verify that your system has virtualization support enabled:
grep -E -q 'vmx|svm' /proc/cpuinfo && echo yes || echo no
If the above command outputs “no”:
- If you are running within a VM, your hypervisor does not allow nested virtualization. You will need to use the None (bare-metal) driver
- If you are running on a physical machine, ensure that your BIOS has hardware virtualization enabled
Special features
The minikube start
command supports 5 additional KVM specific flags:
--kvm-gpu
: Enable experimental NVIDIA GPU support in minikube--hidden
: Hide the hypervisor signature from the guest in minikube--kvm-network
: The KVM default network name--network
: The dedicated KVM private network name--kvm-qemu-uri
: The KVM qemu uri, defaults to qemu:///system
Issues
minikube
will repeatedly ask for the root password if user is not in the correctlibvirt
group #3467Machine didn't return an IP after 120 seconds
when firewall prevents VM network access #3566unable to set user and group to '65534:992
whendynamic ownership = 1
inqemu.conf
#4467- KVM VM’s cannot be used simultaneously with VirtualBox #4913
- On some distributions, libvirt bridge networking may fail until the host reboots
Also see co/kvm2-driver open issues.
Nested Virtualization
If you are running KVM in a nested virtualization environment ensure your config the kernel modules correctly follow either this or this tutorial.
Troubleshooting
- Run
id
to confirm that user belongs to the libvirt[d] group (the output should contain entry similar to: ‘groups=…,108(libvirt),…’). - Run
virsh domcapabilities --virttype="kvm"
to confirm that the host supports KVM virtualisation. - Run
virt-host-validate
and check for the suggestions. - Run
ls -la `which virsh`
,virsh uri
,sudo virsh net-list --all
andip a s
to collect additional information for debugging. - Run
minikube start --alsologtostderr -v=9
to debug crashes. - Run
docker-machine-driver-kvm2 version
to verify the kvm2 driver executes properly. - Read How to debug Virtualization problems
Troubleshooting KVM/libvirt networks
For the most part, minikube will try to detect and resolve any issues with the KVM/libvirt networks for you. However, there are some situations where manual intervention is needed, mostly because root privileges are required.
- Run
sudo virsh net-list --all
to list all interfaces.
example output:
Name State Autostart Persistent
-----------------------------------------------------------
default active yes yes
mk-kvm0 active yes yes
mk-minikube active yes yes
my-custom-kvm-priv-net active yes yes
where:
- default is the default libvirt network,
- mk-kvm0 is a default libvirt network created for minikube kvm0 profile (eg, using
minikube start -p kvm0 --driver=kvm2
), - mk-minikube is a network created for default minikube profile (eg, using
minikube start --driver=kvm2
) and - my-custom-kvm-priv-net is a custom private network name provided for minikube profile (eg, using
minikube start -p kvm1 --driver=kvm2 --network="my-custom-kvm-priv-net"
).
-
Run
sudo virsh net-autostart <network>
to manually set network to autostart, if not already set. -
Run
sudo virsh net-start <network>
to manually start/activate network, if not already started/active.-
In case that the default libvirt network is missing or is unable to start/activate - consult your OS/distro-specific libvirt docs; the following steps might help you to fix the issue:
- Run
sudo virsh net-dumpxml default > default.xml
to backup the default libvirt network config. - Run
sudo virsh net-destroy default
to stop the default libvirt network. - Run
sudo virsh net-undefine default
to delete the default libvirt network. - Run
sudo virsh net-define /usr/share/libvirt/networks/default.xml
to recreate the default libvirt network.- Note: repeat above steps b. and c. and then Run
sudo virsh net-define default.xml
to restore the original default libvirt network config, in case of any issue.
- Note: repeat above steps b. and c. and then Run
- Run
sudo virsh net-start default
to start the default libvirt network. - Run
sudo virsh net-autostart default
to autostart the default libvirt network.
- Run
-
If non-default libvirt network is unable to start/activate, use the following steps:
- Run
sudo virsh net-dumpxml <network>
to dump XML network config - note thebridge name=<bridge>
andip address='<address>' netmask='<netmask>'
values. Example output:
<network connections='1'> <name>mk-minikube</name> <uuid>cfcb37fb-fd75-4599-825a-14bee5d863f5</uuid> <bridge name='virbr1' stp='on' delay='0'/> <mac address='52:54:00:80:97:5a'/> <dns enable='no'/> <ip address='192.168.39.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.39.2' end='192.168.39.254'/> </dhcp> </ip> </network>
b. Run
ip -4 -br -o a s
to show all interfaces with assigned IPs (in CIDR format), now compare the above IP address and netmask with those of the bridge. Example output:lo UNKNOWN 127.0.0.1/8 virbr0 UP 192.168.122.1/24 wlp113s0 UP 192.168.42.17/24 br-08ada8d5dfa4 DOWN 172.22.0.1/16 docker0 DOWN 172.17.0.1/16 virbr1 UP 192.168.39.1/24
- IF THEY MATCH, or THE IP ADDRESS ISN’T LISTED ANYWHERE: Run
sudo ip link delete <bridge>
followed bysudo virsh net-start <network>
andsudo virsh net-autostart <network>
to let libvirt recreate the bridge and [auto]start the network. - IF THE IP ADDRESS BELONGS TO ANOTHER INTERFACE: something else occupied the IP address creating the conflict, and you’ll have to determine what and then choose between the two…
- Run
-
-
Run
sudo systemctl restart libvirtd
orsudo systemctl restart libvirt
(depending on your OS/distro) to restart the libvirt daemon.
Hopefully, by now you have libvirt network operational, and you will be successfully running minikube again.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.