Closed sjug closed 5 years ago
Also annoyingly after it fails to create it is unable to delete...
[user@host path]$ sudo minikube delete
π₯ Deleting "minikube" from kvm2 ...
π£ Failed to delete cluster: destroying running domain: virError(Code=55, Domain=20, Message='Requested operation is not valid: domain is not running')
πΏ Sorry that minikube crashed. If this was unexpected, we would love to hear from you:
π https://github.com/kubernetes/minikube/issues/new
Why sudo ? The user is normally supposed to be part of a libvirt
(or libvirtd) root-equivalent group.
Same error occurs without sudo
, no difference except the path.
UID 65534 is nobody
, so there is something wrong with the libvirt configuration.
Check /etc/libvirt/qemu.conf
# Whether libvirt should dynamically change file ownership
# to match the configured user/group above. Defaults to 1.
# Set to 0 to disable file ownership changes.
#dynamic_ownership = 1
Similar to https://bugs.archlinux.org/task/58894
FWIW, the latest kvm2 driver should handle network cleanup better. I also concur: do not use root to run minikube, it causes more problems than it's worth.
Do you mind running: virt-host-validate
and groups
?
Please confirm if setting dynamic_ownership = 0
fixes the issue, as @afbjorklund suggested.
I can confirm that setting dynamic_ownership = 0
fixes this issue for me.
@sjug could you please confirm if the solution also works for you?
Closing as a workaround appears to have been found.
After some messing around I just noticed that (sans workaround) virt-manager REQUIRES the file be located in /var/lib/libvirt/images before they will not throw errors similar to OP. As a filthy casual I like to keep my VM images in userspace.
The exact command to reproduce the issue:
The full output of the command that failed:
The output of the
minikube logs
command:The operating system version:
Linux ryzen 5.1.7-arch1-1-custom #1 SMP PREEMPT Thu Jun 6 07:40:25 EDT 2019 x86_64 GNU/Linux