-
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
kvm2: minikube start fails, due to timeout before disk image is fully created #7561
Comments
I'll send a PR out for a lower-tech solution, just to see if it works. This step typically takes 10 seconds, so normally 2 minutes is enough, and well, 4 minutes should be plenty of time. |
Do you mind checking if this binary fixes your issue: https://storage.googleapis.com/minikube-builds/7565/minikube-linux-amd64 |
Hmm, this is supposed to create a sparse image... It will grow over time (too much*), but not to 20G ? * see #3155 Which version of libvirt (QEMU and KVM) is this ? Disk bloat is my main reason for preferring VirtualBox |
You could try inspecting the image (compacting it could also help)
|
This setup is at my work computer and I lost access to it, so I get more details next week, when that is fixed. In my terminal history, the size of Libvirt, qemu and kvm should be versions from Debian testing/unstable, as I just had updated packages, thus libvirt should be v6.Any case, I'll get back to you on these. It could be that As a side note, I think we should find a way to limit the timeout only for the |
@raphendyr - Thank you for the update. Please let me know if the PR I sent out helps at all. |
@raphendyr have you a chance to try our latest version of minikube to verify this solved your problem? |
@raphendyr haven't heard from you. I will close this please feel free to re-open |
Sorry, I have not tragged github notifications for a while again... Any case, I forgot to comment that the creation delay is because ecryptfs must create the full file for parse images due to security reasons. I "fixed" it by creating a symlink from The newest minikube (v.1.10.1), still fails due to long image creation time. However, I think the symlink is a viable workaround, unless you want to support encrypting the raw image via ecryptfs mount. Timestamped log from the last test using minikube v1.10.1
I can personally accept this behaviour, so the issue can stay closed. |
Steps to reproduce the issue:
minikube-1.7.3 start -p minikube173 --auto-update-drivers=false -v=8 --alsologtostderr --vm-driver=kvm2
Full output of failed command:
Output for v1.9.2 (fails)
Output for v1.7.3 (fails)
Output for v1.7.2 (success after ~5min)
Image sizes
It seems that 1.7.3 and 1.9.2 images are not as big as they are supposed to be.
Other details
Timeout was introduced in PR #6625 and released in tag v1.7.3.
Ideas for solution
The text was updated successfully, but these errors were encountered: