"minikube start" hangs in a nested Virtualbox VM environment #9647
Labels
cause/nested-vm-config
When nested VM's appear to play a role
co/virtualbox
kind/support
Categorizes issue or PR as a support question.
lifecycle/frozen
Indicates that an issue or PR should not be auto-closed due to staleness.
lifecycle/rotten
Denotes an issue or PR that has aged beyond stale and will be auto-closed.
os/linux
Comments
afbjorklund
added
os/linux
cause/nested-vm-config
|
If you are already running in VirtualBox, I would recommend using a different driver... For instance the "docker" driver (for a desktop), or the "none" driver (for a dedicated VM) Is there a reason for using an Ubuntu VM, rather than using the provided Buildroot ISO ? Another approach is using a remote/second VM for minikube, as described here: #4730 |
|
It might be an issue when using more than 1 vCPU, as required by kubadm:
|
afbjorklund
added
kind/support
Hi, I was following the instructions from the Linux foundation in the course Kubernetes Fundamentals (LFS258), where they suggest using Virtualbox as the driver in the learning phase. I have previously used the docker driver where it worked just fine.
I tried this to no avail, unfortunately. I'm going to see whether this could be kernel version related or not with a more recent version. |
|
Alright, I have now tried with CentOS 8 instead: Run results: After updating to mainline: Same result happens when changing VM to 1 vCPU. |
Instead of running minikube inside a VirtualBox VM, you can let minikube use VirtualBox to create the VM for you. |
To be clear, I figured as much that it is meant to be run on bare metal, but given that Virtualbox does support nested virtualization, this should work. Quoting from The Linux Foundation's free course (LFS258): “Minikube is installed and runs directly on a local Linux, macOS, or Windows workstation. However, in order to fully take advantage of all the features Minikube has to offer, a Type-2 Hypervisor should be installed on the local workstation, to run in conjunction with Minikube. This does not mean that we need to create any VMs with guest operating systems with this Hypervisor. Minikube builds all its infrastructure as long as the Type-2 Hypervisor is installed on our workstation. Minikube invokes the Hypervisor to create a single VM which then hosts a single-node Kubernetes cluster. Thus we need to make sure that we have the necessary hardware and software required by Minikube to build its environment.” Minikube is also recognized to use the Virtualbox driver as the default VM runtime. If operating minikube inside a virtual machine isn't supported, this should be stated in the documentation. I believe installing testing environments on bare metal is a bad idea overall, and should be separated if possible wheter minikube already virtualizes and isolates it from a production environment or not. On a side note; I ran minikube with the docker driver and it works like a charm as when I tried it last year. |
chippey5
changed the title
|
The course sounds about right:
This is because minikube will use your hypervisor, to create a virtual machine (thus not touching the original environment). We do provide a driver, for people who want to provide their own VM rather than letting minikube do it. (It's called "none")
Of course you can just continue to use the new "docker" driver, it was not available at the time this course was written. Either you can run it on a Docker available directly on the host, or even run docker inside your own VM for extra isolation. But running one VirtualBox VM inside another VirtualBox VM seems like it has some issue, and is thus better off avoided. * this approach is for instance used when running the minikube "docker" driver with Docker Desktop, on Mac or Win |
This is true when following the course only using Virtualbox on "bare metal". I think that the confusion comes from how the options are layered in terms of isolation;
The setup I'm trying is most likely not used by many but I still believe that either the official documentation should mention to avoid nested virtualization where minikube is installed in a virtual machine and where the user then tries to use the virtualbox driver. Nonetheless, going forward I'm using the docker driver in a VM for the extra isolation. Looking back at this I learned that the minikube driver should not be confused with the kubernetes CRI (which I believe I did for a second). Actual kubernetes environments will look a lot different in the end in terms of infrastructure setup where virtualbox won't be involved as much, if at all. |
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
k8s-ci-robot
added
the
lifecycle/stale
|
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
k8s-ci-robot
added
lifecycle/rotten
spowelljr
added
the
lifecycle/frozen
|
@chippey5 I'm unsure from the discussion if there is any action on minikube's behalf that should be done to help resolve your issue. For now I'm going to close this issue, but if there's any recommendation that would help, feel free to comment, thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce the issue:
curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/)minikube startFull output of failed command:
Other errors showing up during minikube start:
This has been tested on two different machines, both running Ubuntu 20.04 under virtualbox. Kernel version
5.4.0-52-generic.Optional: Full output of
minikube logscommand:The text was updated successfully, but these errors were encountered: