Qemu driver: profile list shows "Stopped" instead of "Starting..."

[medyagh]

What Happened?

$ minikube profile list
|----------|-----------|---------|----------------|------|---------|---------|-------|----------------|--------------------|
| Profile  | VM Driver | Runtime |       IP       | Port | Version | Status  | Nodes | Active Profile | Active Kubecontext |
|----------|-----------|---------|----------------|------|---------|---------|-------|----------------|--------------------|
| minikube | qemu2     | docker  | 192.168.105.23 | 8443 | v1.30.0 | Stopped |     1 | *              |                    |
|----------|-----------|---------|----------------|------|---------|---------|-------|----------------|--------------------|

while in the next terminal I am seeing it as step of Preparing Kubernetes ... (which means VM is already created)

$ minikube start --driver=qemu2
😄  minikube v1.33.0 on Darwin 14.4.1 (arm64)
✨  Using the qemu2 driver based on user configuration
🌐  Automatically selected the socket_vmnet network
💿  Downloading VM boot image ...
    > minikube-v1.33.0-arm64.iso....:  65 B / 65 B [---------] 100.00% ? p/s 0s
    > minikube-v1.33.0-arm64.iso:  362.01 MiB / 362.01 MiB  100.00% 10.51 MiB p
👍  Starting "minikube" primary control-plane node in "minikube" cluster
💾  Downloading Kubernetes v1.30.0 preload ...
    > preloaded-images-k8s-v18-v1...:  319.81 MiB / 319.81 MiB  100.00% 10.76 M
🔥  Creating qemu2 VM (CPUs=2, Memory=4000MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.30.0 on Docker 26.0.1 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...

when it Finishes Preparing Kubernets I see it running

$ minikube profile list
|----------|-----------|---------|----------------|------|---------|---------|-------|----------------|--------------------|
| Profile  | VM Driver | Runtime |       IP       | Port | Version | Status  | Nodes | Active Profile | Active Kubecontext |
|----------|-----------|---------|----------------|------|---------|---------|-------|----------------|--------------------|
| minikube | qemu2     | docker  | 192.168.105.23 | 8443 | v1.30.0 | Running |     1 | *              | *                  |
|----------|-----------|---------|----------------|------|---------|---------|-------|----------------|--------------------|

[ComradeProgrammer]

/assign

[ComradeProgrammer]

Well I think currently we have some problems related with this status.

Here are some points I found after investigation

1. Actually, minikube profile does not return "Starting" even when we are starting a cluster using docker driver. So it is actually not related with qemu.
2. There are 3 places where the status of a cluster is fetched, and each of them have their own different logic of deciding the status:

• minikube profile list implemented its own logic to decide the status. It is soly based on the status of different components, but it take ha-cluster into consideration, so the status can never be "Starting" for qemu/kic.
• minikube status has its own logic to decide the status, which is designed to show different status of different nodes It is soly based on the status of different components,so the status can never be "Starting" for qemu/kic.
• minikube status -o json --layout=cluster also has its own logic to decide the status. It is based on the status of different status of components AND the event logs so it can return "Starting". But it does not take ha-cluster into consideration

(Actually this problem has been mentioned before in minikube-gui link . During that time I found that starting or stoping can never be returned by minikube at all. However in that pr eventually we used the log of minikube start to bypass this problem)

Based on these facts, can I suggest that we should make a small refactor for the status of cluster. We should unify these logic together and create a method returning the status of a cluster based on the status of components, event logs, whether it is a ha-cluster and how many node is running. Both minikube profile list and minikube status should use the new method instead.

@medyagh @spowelljr