-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minikube tries to delete the default libvirt network #18919
Comments
Thanks @nirs for the PR and that sounds resonable, I am curious what are some practical usages of using the "default" network vs letting minikube create its own custom network ? I am saying this because many years ago when we were sharing the network and not using dedicated network we were facing a lot of issues such as ip conflicts or stuck networks or clean ups... I just like to learn your specific needs if you dont mind sharing |
We create a DR setup with 3 clsuters (hub, dr1, dr2). The DR clusters run rook-ceph storage, and use the host network. This makes it easier to setup storage replication between the dr1 and dr2. With the storage replicated, when we create a workload on one cluster and enable DR protection, the ceph volume is replicated to the other cluster. Then we can simulate a disaster by suspending or destroying one of the clusters, and start the workload on the other cluster. On a real setup, we allow connect the remote clusters using submariner. For the testing setup we simplify, we have enough trouble without submariner. You can check this FOSDEM talk showing all this with virtual machine as workload: |
thank you for sharing, thats interesting, so in this case the other servers in the cluster already use the "Default" network and I assume you pass a flag to minikube to force it to use the default network as well, right? I think as long as we make sure we have a good clean up story (for when we delete minikube) that should be good PR for minikube, and thanks for taking the time to contribute it |
What Happened?
When running minikube with
--driver kvm2 --network default
it will use the libvirt default network, but it does not create it. If fact, it will fail if the default network does not exist.When deleting a minikube profile, it tries the delete the default network it did not create.
Looking at verbose logs we see that minikube tries to delete the default network if the network is not used by any vms:
This is very wrong - minikube does not own the libvirt default network, so it must not try to remove it.
This is 100% reproducible when no other vm on the system is using the default network, and randomly fails when deleting multiple profiles in parallel, since the check for used network is racy (time of check, time of use).
Looking at the relevant code, the intent is very clear that we do not want to delete the default network (d.Network), but only the minikube private network (d.PrivateNetwork). So it seems that the root cause is that the d.PrivateNetwork is set to "default" by mistake at some point.
Checking the domain, we have 2 interfaces created on the default network, instead of one interface on the default network, and one on the "minikube-net" private network:
We can also see that minikube is using only the default network in the config:
Maybe this is the intended behavior - if you use
--network defualt
both interfaces are created on the specified network.Based on this, I think we should skip deletion if the private network is "default".
Attach the log file
Logs in the description.
Operating System
Redhat/Fedora
Driver
KVM2
The text was updated successfully, but these errors were encountered: