Machine didn't return an IP after 120 seconds, aborting - even with HyperV disabled #45
Comments
|
can you run this please from powershell ?! |
|
and give the output :-) |
|
I don't believe it's the path as docker-machine-vmwareworkstation/vmrun.go Line 156 in 9f849d6 Questions:
The problem seems to be "similar" as the mac line is not present |
|
Hi folks, Can you start VMs manually on VMWare? Do you see the VM running? (you can try to open VMWare Workstation and "Open" the VM by opening the .vmx file) I'm really racking my brain here - I must be missing some stupid detail - and thanks for your help guys. |
|
[Complementary info]
|
|
@fernandoabcampos I missed this from the logs (sorry, was on mobile) but this is probably it So it could be related to having VMware installed on a different path as you mentioned before. |
|
No problem at all @pecigonzalo |
|
@fernandoabcampos, Its odd that it can't find the keys in the registry, as they should exist always AFAIK. Maybe you can manually check for them or as a test create them, to verify that works. We should terminate execution when they are not found, ill do a PR from this issue to terminate and report the error instead silently failing. |
|
OK @pecigonzalo, thanks. |
|
@fernandoabcampos as a test, could you set the env |
|
Sure, the results: Unfortunately, the same. |
|
But it did find |
|
Hi guys, update: The new log: I know that you've dedicated some time helping me out to investigate, but now, as it seems to be more related to VMWare / my environment and it is not strictly required for what I'm doing, I'm about to adopt another strategy and generate the docker-machines with virtualbox. |
|
Did you let it run till the end? |
|
Sorry, I didn't mention it - yes I let it run until the end. |
|
@fernandoabcampos Maybe you can try to run the commands in the Administrator mode and then see what happens. |
|
Hi guys, I getting the same timeout after 2min msg as @fernandoabcampos HOWEVER i get this msg when running HENCE i was trying to "work around" that problem by trying Docker Machine Version: 0.8.2, build e18a919 Found binary path at C:\ProgramData\chocolatey\bin\docker-machine-driver-vmwareworkstation.exe Found binary path at C:\ProgramData\chocolatey\bin\docker-machine-driver-vmwareworkstation.exe (debug-me) Calling .GetMachineName Running pre-create checks... Creating machine... (debug-me) DBG | executing: C:\Program Files (x86)\VMware\VMware VIX\vmrun.exe start C:\Users\ColinDNZ.docker\machine\machines\debug-me\debug-me.vmx nogui (debug-me) Waiting for VM to come online... (debug-me) DBG | Not there yet 1/60, error: couldn't find MAC address in VMX fil ... (debug-me) DBG | Not there yet 57/60, error: couldn't find MAC address in VMX fi Error creating machine: Error in driver during machine creation: Machine didn't return an IP after 120 seconds, aborting I don't yet understand how docker works with certs or networks |
|
I do hv |
|
I should mention docker installed & run using chocolatey C:\Users\ColinDNZ>docker version I don't know enough to know what this tells me... |
|
reinstall Docker & DockerMachine time="2017-10-17T15:27:21+13:00" level=warning msg="Unable to use system certificate pool: this time re-install has reset cert links |
|
Don't know if that helps here, but I got the same problem that docker-machine couldn't find an IP address after 120 seconds. I turned out that our new company notebooks don't have the virtualization (vTX vTD) settings activated in BIOS. I also couldn't start any VMware VM manually. But at least this is one thing to check. |
|
Unfortunately, I have been quite busy to answer all questions here, but lets separate the issues please. If you cant run the VM from your command line and/or manually then it is not a problem with this repository, its a problem with your setup. @colindnz Please dont put 3 messages one after the other and use Markdown formatting to make it more readable, otherwise its hard to understand your issue. The if the docker-machine driver failed, then you are not going to get anything from docker, as its not started. As a general statement, there could be 2 things happening here. First please verify the machine starts:
|
|
In my case VIX was missing |
|
Same problem and fixed after enable debug log, I found a vmrun command, then I run vmrun.exe directly: found this post, and open vixwrapper-config.txt no version setting for version I using (14.0.0), so I back to vmware website download to download VIX match for my player. and it works now. |
|
Posting the same info here that I posted over @ the Docker-Machine and Powershell/OpenSSH teams to collaborate on the final solution but I also provide a tested workaround. This issue has plagued us and gone all the way back over three years to when Docker was first released and I have uncovered the root cause. So for those of you like the OP having the dreaded (120 seconds....) or any one of the other failures (it's amazing how Kitematic INSTANTLY worked for the very FIRST time ever on my Win7 systems after implementing this workaround) - read and watch my screencast reproduction showing the root cause, and give the workaround a try if nothing else is working and I bet it also resolves your issue. NOTE: I did not even think to add all the related issues here and on all the other child BackgroundThere have been Github issues opened and subsequently closed dating all the way back to ISSUE #66 - very soon after the initial release yet closed. Many of these appear to be reproducible under this issue's cause or in some way related to this issue:
And the Docker forums:
And let's not forget all of StackOverflow sites (I'm only posting a couple but there are MANY):
Also, this issue's root cause is also responsible for all these Kitematic issues including:
And if that is not enough, just run these two Google searches below, and you can bet that most if not all those hits with these "mystery" 255/timeouts/nondescriptive are also this issue:
Issue(s)
CauseIncompatible SSH client implementation. Tests were run from the current beta release of Something in the call to "ip addr show" and possibly other operations from Docker-Machine are being interpreted incorrectly resulting in a terminating error. This prevents any successful Docker operations using either native shell in Windows. This is becoming a bigger and bigger issue now since the incompatible client is automatically installed with Powershell and Chocolatey and added to the system path. The presence and priority in the system path can be changed and in such is the reason this issue does not appear to plague everyone on Windows and has been so difficult to troubleshoot. Because the Mingwin bash shell relies on the separately installed Git SSH client, the QuickStart Terminal (usually) works which also had added to the difficulty in troubleshooting. However, once you move to native shells to manage the containers created with the QuickStart terminal, the system path will quickly prioritize the problematic SSH client and cause failures. Based on testing I would recommend until full resolution that this could possibly be utilized as an accurate statement that sums up in one paragraph the current status of this issue: Note that the real solution is (and I am also immediately opening a Github issue there as well) for the Powershell team now maintaining the OpenSSH for Windows project to work with the Docker team to capture the low-level debug output from OpenSSH back to Docker-Machine's call to "ip addr show" (and other commands) to determine what on earth is being interpreted as a bad return, despite as I demonstrated the command clearly returning successfully the exact same output as the versions using OpenSSL instead of LibreSSL, and the connection via TLS being successful in all versions. Issue ReproductionWorkaroundUntil the root cause of the incompatibility with the OpenSSH-Win32 client can be addressed, there is only one workaround that has been successfully tested. Both the SYSTEM and USER environment variable for PATH must be edited and any references to OpenSSH-Win32 (Default path of After making this change, a reboot is recommended. The original issue #'s to hopefully track progress on a real fix are over here: |
|
I also had the problem described above. And the solution is silly :D My scenario: The problem is: I also got the error when running the above line in my Powershell console. The solution: Proposal for improvement: Thank you very much for your help and for these vmwareworkstation drivers in general. :) |
|
the same issue. |
|
Hi The machine runs fine as do all other VMware VMs and they take IPaddresses fine. The result of The Mac address machine asks for is the one set in the vm settings: but not the same as inside the VM -but I suppose that is fine? How can I troubleshoot this? |
|
I comared the If I then try to regenerate I get: which just hangs even though I can easily logint with ssh to the machine using the docker account. What is really the problem? |
|
I opened this issue quite some time ago and still has never adequately been addressed. You might want to take the time to read this and I clearly demonstrate how this occurs, but I simply still don't have the time to debug all the docker code to find the exact cause. However, I also demonstrate the workaround/solution/cause which, if you take the time to read - is ultimately a pitifully-simple fix: Https://github.com/docker/machine/issues/4483 In my testing across legacy (non-WIN10) with docker/toolbox, this turned out to be the root cause of the majority of failures related to timeouts, "waiting for IP", and many more which I also cited with link examples. Note this affects BOTH Virtualbox as well as VMware workstation because ultimately if you read and watch the side-by-side video showing the cause, it isn't the virtualization application causing it. EDIT: Also note that even though I did NOT test Linux, theoretically if you read that cause, my guess is that it could potentially also impact Linux. |
|
@CollinChaffin Ill start working on this again next month. It has been quite hard as many issues seem to be lumped together here (as you can see from the user with the wrong mem value). Please avoid comments like the following
I appreciate the screencast and the explanation, altho I believe you are also lumping a bunch of issues together, as many "things" could cause the virtualization layer to fail to start and hence give the
Ill initially try at least to improve the logging from the CLI, VMWare and other interactions to help unbundle all these issues and make them easier to troubleshoot. Fortunately and unfortunately, the new docker with WSL2, should not need this anymore and will provide IMO a better, more "native" integration. To everyone else having issues, sorry for my long absence here, I have been unable to put the time on this I required and it was even made more complex since Im not daily running Windows at the moment for work reasons. |
Hi, guys,
I've tried all the approaches discussed previously and I'm still getting a "Machine didn't return an IP after 120 seconds, aborting". [The same was mentioned in #29 but any information there fixed my problem]
About what I've done:
VMware Workstation version: 12.5.7 build-5813279
After that as admin and as ordinary user I tried (the following command was executed with and without disk size):
As shown, the log Error finding VMware root: The system cannot find the file specified presents some info that could be useful. [Silly question] Could it related to the fact that VMWare is installed in a non-usual path?
Apart from that,
Hyper-V is disabled, so I don't think this could be causing much trouble as aforementioned in #29 .
The dev.vmx:
P.S.: I reinstalled the whole environment in order to try to overcome this, but so far I'm not being capable to solve.
Any clue on this issue would be more than appreciated.
Thanks in advance,
Regards.
Fernando Barbeiro
The text was updated successfully, but these errors were encountered: