Open wzrdtales opened 6 years ago
Hope that helps some of you guys stumbling over this and searching for help here.
I'm still getting the error when create new VM with following command:
[cryto@archserver ~]$ docker-machine create -d kvm --kvm-network "docker-machines" --kvm-boot2docker-url=https://github.com/boot2docker/boot2docker/releases/download/v17.03.1-ce/boot2docker.iso machine1 Running pre-create checks... Creating machine... (machine1) Boot2Docker URL was explicitly set to "https://github.com/boot2docker/boot2docker/releases/download/v17.03.1-ce/boot2docker.iso" at create time, so Docker Machine cannot upgrade this machine to the latest version. (machine1) Downloading /home/cryto/.docker/machine/cache/boot2docker.iso from https://github.com/boot2docker/boot2docker/releases/download/v17.03.1-ce/boot2docker.iso... (machine1) 0%....10%....20%....30%....40%....50%....60%....70%....80%....90%....100% (machine1) Creating SSH key... (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input (machine1) Failed to decode dnsmasq lease status: unexpected end of JSON input ...
@wzrdtales Do you have any idea? I just want to start minishift to learn openshift, but due to the same error while leasing an IP from dnsmasq for the VM so the VM can't start properly --> minishift also fails to start
@tunggad My issue wasn't about minishift. for minishift you can try the minikube kvm2 https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#kvm2-driver, no guarantees for that though.
@wzrdtales: I found this issue in Fedora Bugzilla reported back in June 2015: https://bugzilla.redhat.com/show_bug.cgi?id=1228631
It states that libvirt for some reasons from particular version does not use the dnsmasq managed lease database (the .leases files) anymore, that's why for the libvirt-managed networks there is also no .leases file -> no file under /var/lib/libvirt/dnsmasq/docker-machines.leases for docker-machines network -> kvm driver gets the above error
So i wonder, how could the kvm driver of @dhiltgen work for minishift since then?
For the network docker-machines, i also tried to add this following line to /var/lib/libvirt/dnsmasq/docker-machines.conf (the configuration file of the dnsmasq instance created by libvirt for the network)
dhcp-leasefile=/var/lib/libvirt/dnsmasq/docker-machines.leases
But it does not make any effect, still get the error when starting minishift
docker-machine create -d kvm user Running pre-create checks... Creating machine... (user) Copying /root/.docker/machine/cache/boot2docker.iso to /root/.docker/machine/machines/user/boot2docker.iso... (user) Creating SSH key... (user) Unable to determine VM's IP address, did it fail to boot? Waiting for machine to be running, this may take a few minutes... Detecting operating system of created instance... Waiting for SSH to be available...
no any response,au ,
hello!
I had this issue and fixed it by switching to the virtio network driver. It appears that the latest boot2docker images no longer support the rtl8139 driver, and a rtl8139 seems to be the default network device on my libvirt installation.
I worked around this by shutting down the machine in virt-manager
while it was waiting for SSH to appear, changing both network drivers to virtio, and then starting it up again. You have to do it somewhat quickly before it times out.
You may also be able to fix this by applying a diff like
diff --git a/kvm.go b/kvm.go
index 1e6c891..90566b4 100644
--- a/kvm.go
+++ b/kvm.go
@@ -59,9 +59,11 @@ const (
<listen type='address' address='127.0.0.1'/>
</graphics>
<interface type='network'>
+ <model type='virtio'/>
<source network='{{.Network}}'/>
</interface>
<interface type='network'>
+ <model type='virtio'/>
<source network='{{.PrivateNetwork}}'/>
</interface>
</devices>
and recompiling.
@wzrdtales: I submitted PR #74 to address this, but it looks similar/overlapping PRs have been submitted in the past. But I note that Issue #67 strongly implies that @dhiltgen no longer has time to support this project. I also note (from discussion on and related to that issue) that this work may eventually be merged into another project.
In the mean time, since I'm still using this, I made a release in my own fork. It supports specification of virtio as the NIC model and, thus supports recent versions of boot2docker. Feel free to use.
Man thanks so much for your work. Happy to finally be using docker-machine for testing (have been watching this for months!)
So this is a solution rather than an issue. However I ran into this issue, without that I have changed anything about my infrastructure. I use this in combination with gitlab-runner and it suddenly failed to start my vms and got stuck on getting an IP.
To the logs it would write something like:
Do not have all logs here anymore, however, the solution to this is: downgrade the boot2docker version, by specifiying an older one. I.e. the 17.03. For some reason new boot2docker version fail to boot correctly, probably the docker team changed there a lot of things how boot2docker works recently.
To set this you need to set the kvm-boot2docker-url variable to another iso. I set for example:
"kvm-boot2docker-url=https://github.com/boot2docker/boot2docker/releases/download/v17.03.1-ce/boot2docker.iso"
After that everything should work as expected again.