waiting for winrm connection that never arrives #1

heymishy · 2013-01-07T08:55:41Z

I seem to be having issues connecitng with winrm using your veewee config.

Seems to be stalling when while it tries (in vain) to connect to the winrm guest:

Waiting for winrm login on 127.0.0.1 with user vagrant to windows on port => 5985 to work, timeout=10000 sec
.......................................................................................................................

The complicating element for my setup is this:

Im running a Ubuntu guest on a Windows 8 host, THEN running veewee/windows-fromscratch through the guest to create a 3rd guest.

Originally I thought it was my Windows8 winrm listener getting in the way, but I've turned off that on my machine and there should be no interference for the connection.

Do you have any ideas on how to resolve?

Also, do you have any idea how long the process should take? I'm assuming when the process is kicked off, Autounattend.xml is used to install Win2008 and configure the WinRM service once it's finished.. so im guessing its going to take quite a while to fire up and actually connect through WinRM?

Thanks,
Hamish.

marsmensch · 2013-01-07T11:16:26Z

FYI: just had the same effect with a windows 7 guest on a ubuntu 12.04 host

On Mon, Jan 7, 2013 at 9:55 AM, Hamish King [email protected]:

I seem to be having issues connecitng with winrm using your veewee config.

Seems to be stalling when while it tries (in vain) to connect to the winrm
guest:

Waiting for winrm login on 127.0.0.1 with user vagrant to windows on port
=> 5985 to work, timeout=10000 sec

.......................................................................................................................

The complicating element for my setup is this:

Im running a Ubuntu guest on a Windows 8 host, THEN running
veewee/windows-fromscratch through the guest to create a 3rd guest.

Originally I thought it was my Windows8 winrm listener getting in the way,
but I've turned off that on my machine and there should be no interference
for the connection.

Do you have any ideas on how to resolve?

Also, do you have any idea how long the process should take? I'm assuming
when the process is kicked off, Autounattend.xml is used to install Win2008
and configure the WinRM service once it's finished.. so im guessing its
going to take quite a while to fire up and actually connect through WinRM?

Thanks,
Hamish.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1.

jedi4ever · 2013-01-07T12:19:33Z

@heymishy can you check if the port 5985 is actually reachable from the vm? and maybe login into the windows/virtualbox console and see if what winrm reports inside the vm?

marsmensch · 2013-01-17T08:28:20Z

Hi,
just re-tested in a new lab environment with a Ubuntu 12.04 Host and vagrant 1.0.5. Windows 7 Host comes up, theres obviously a problem with winrm:

[ 8< SNIP 8<]
Creating vm windows-7-enterprise-amd64-winrm : 512M - 1 CPU - Windows7_64
Creating new harddrive of size 20280, format VDI, variant Standard 
Attaching disk: /home/flom/VirtualBox VMs/windows-7-enterprise-amd64-winrm/windows-7-enterprise-amd64-winrm.vdi
Mounting cdrom: /home/flom/vagrant-lab/windows-fromscratch/iso/7600.16385.090713-1255_x64fre_enterprise_en-us_EVAL_Eval_Enterprise-GRMCENXEVAL_EN_DVD.iso
Mounting guest additions: /home/flom/vagrant-lab/windows-fromscratch/iso/VBoxGuestAdditions_4.1.12.iso
Using winrm because winrm_user and winrm_password are both set
Received port hint - 5985
Found port 5985 available
Received port hint - 5985
Found port 5985 available
Waiting 0 seconds for the machine to boot
Done typing.
Skipping webserver as no kickstartfile was specified
Received port hint - 7000
Found port 7000 available
Waiting for winrm login on 127.0.0.1 with user vagrant to windows on port => 5985 to work, timeout=10000 sec
..................................#
Bad HTTP response returned from server (401).
["/var/lib/gems/1.9.1/gems/winrm-1.1.2/lib/winrm/http/transport.rb:48:in `send_request'", "/var/lib/gems/1.9.1/gems/winrm-1.1.2/lib/winrm/winrm_service.rb:368:in `send_message'", "/var/lib/gems/1.9.1/gems/winrm-1.1.2/lib/winrm/winrm_service.rb:113:in `open_shell'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/helper/winrm.rb:128:in `winrm_execute'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/helper/winrm.rb:54:in `block in when_winrm_login_works'", "/usr/lib/ruby/1.9.1/timeout.rb:68:in `timeout'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/helper/winrm.rb:44:in `when_winrm_login_works'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/exec.rb:21:in `exec'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/wincp.rb:18:in `wincp'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/copy.rb:9:in `copy_to_box'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:268:in `block in transfer_buildinfo'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:259:in `each'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:259:in `transfer_buildinfo'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/virtualbox/box/helper/buildinfo.rb:16:in `transfer_buildinfo'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:78:in `build'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/virtualbox/box/build.rb:14:in `build'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/command/vbox.rb:17:in `build'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/invocation.rb:109:in `invoke'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor.rb:213:in `block in subcommand'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/base.rb:425:in `start'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/bin/veewee:23:in `'", "/var/lib/gems/1.9.1/bin/veewee:19:in `load'", "/var/lib/gems/1.9.1/bin/veewee:19:in `'"]
............[ 8< SNIP 8<]......LOTSOFDOTSREMOVED...........[ 8< SNIP 8<].....................................#<#: execution expired>
execution expired
["/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/helper/winrm.rb:51:in `sleep'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/helper/winrm.rb:51:in `block in when_winrm_login_works'", "/usr/lib/ruby/1.9.1/timeout.rb:68:in `timeout'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/helper/winrm.rb:44:in `when_winrm_login_works'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/exec.rb:21:in `exec'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/wincp.rb:18:in `wincp'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/copy.rb:9:in `copy_to_box'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:268:in `block in transfer_buildinfo'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:259:in `each'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:259:in `transfer_buildinfo'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/virtualbox/box/helper/buildinfo.rb:16:in `transfer_buildinfo'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/core/box/build.rb:78:in `build'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/provider/virtualbox/box/build.rb:14:in `build'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/lib/veewee/command/vbox.rb:17:in `build'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/invocation.rb:109:in `invoke'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor.rb:213:in `block in subcommand'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'", "/var/lib/gems/1.9.1/gems/thor-0.16.0/lib/thor/base.rb:425:in `start'", "/home/flom/.bundler/ruby/1.9.1/veewee-8ce8f06c75b6/bin/veewee:23:in `'", "/var/lib/gems/1.9.1/bin/veewee:19:in `load'", "/var/lib/gems/1.9.1/bin/veewee:19:in `'"]
[ 8< SNIP 8<]

heymishy · 2013-01-21T08:40:07Z

Sorry about the delay.. basically I had some group policy setting that was re-enabling winrm on the host and clashing with the connection to the guest.. so if your trying to run windows host + windows guest, ensure winrm is disabled locally (or at the least change ports)

marsmensch: the 401 response is a bad authentication response. looks to me it's timing out and not handling the timeout correctly, but regardless it's not being authenticated properly.

have you enabled basic auth correctly on the guest?

check out https://github.com/zenchild/WinRM/issues?page=1&state=closed for winrm specific auth issues

marsmensch · 2013-01-21T10:12:01Z

Am 21.01.2013 um 09:40 schrieb Hamish King [email protected]:

marsmensch: the 401 response is a bad authentication response. looks to me
it's timing out and not handling the timeout correctly, but regardless it's
not being authenticated properly.

have you enabled basic auth correctly on the guest?

Hi Hamish,

this is a fresh install using an Win7 evaluation iso. Did i miss any
mandatory configuration settings?

Cheers

heymishy · 2013-01-21T10:20:40Z

I had a similar problem and thought I;d configured winrm correctly on the guest but ran the following to correct:

winrm quickconfig -q
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="512"}
winrm set winrm/config @{MaxTimeoutms="1800000"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}

I also ensured I could acutally perform the winrm to the guest without the winrm gem..

i.e. winrs -r:hostname -u:username -p:password dir C:\

The above is run from windows but I'm sure there's a linux equiv or just run from within a GUI sesssion of the VM you just created. Just put the following in yuor Vagrantfile for GUI

config.vm.boot_mode = :gui

hh · 2013-01-21T22:27:36Z

Ok, I'm taking a look at this today, if anyone is around I'll be on irc.freenode.net in #vagrant

hh · 2013-01-21T22:31:10Z

So we don't need to use my vagrant branch anymore... jedi4ever/veewee@f45954f

jedi4ever · 2013-01-22T11:11:43Z

@hh do you mean it's now merged into mean winrm gem? Would you do the honours of doing a pull request for veewee and check it's working correctly? Thanks!

daneroo · 2013-01-22T16:23:11Z

@hh does that mean that the windows-fromscratch Gemfile can stop pointing to your github forks of veewee and em-winrm ?

hh · 2013-01-22T18:57:26Z

We'll maybe not the em-winrm, I still need to get that pull request in to
update the version of the winrm gem it points to.

On Tue, Jan 22, 2013 at 10:33 AM, Chris McClimans [email protected]:

Yes. 8)

On Tue, Jan 22, 2013 at 8:23 AM, Daniel Lauzon [email protected]:

@hh https://github.com/hh does that mean that the windows-fromscratch
Gemfile can stop pointing to your github forks of veewee and em-winrm ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-12552172.

hh · 2013-01-22T19:04:23Z

Yes. 8)

On Tue, Jan 22, 2013 at 8:23 AM, Daniel Lauzon [email protected]:

@hh https://github.com/hh does that mean that the windows-fromscratch
Gemfile can stop pointing to your github forks of veewee and em-winrm ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-12552172.

jedi4ever · 2013-01-23T10:24:04Z

Euh @hh - is this a yes for removing it to point to the github? Was a bit confusing with first a maybe then a yes :)

hh · 2013-01-23T17:16:15Z

I revamped the code structure a bit and no longer point to my branches of anything. However I think schisamo should bump the winrm gem in chef-boneyard/em-winrm#8

marsmensch · 2013-01-23T19:01:07Z

Am 21.01.2013 um 11:20 schrieb Hamish King [email protected]:

I had a similar problem and thought I;d configured winrm correctly on the guest but ran the following to correct:

winrm quickconfig -q
winrm set winrm/config/winrs @{MaxMemoryPerShellMB="512"}
winrm set winrm/config @{MaxTimeoutms="1800000"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}
To complete the information in this issue:
The veewee "Autounattended.xml" template for the Windows7 Enterprise 64-bit is currently lacking the following line:

winrm set winrm/config/client/auth @{Basic="true"}

Adding it solved my problem and winrm happily connected to my fresh Windows installation.

Thanks for the pointer Hamish!

Florian

PS.: I will check the current veewee templates tomorrow and open a pull request if the issue exists there, too.

hh · 2013-01-23T20:38:11Z

Basic="true" is set on both -winrm templates in jedi4ever/veewee@master

https://github.com/jedi4ever/veewee/blob/master/templates/windows-2008R2-serverstandard-amd64-winrm/Autounattend.xml#L158

https://github.com/jedi4ever/veewee/blob/master/templates/windows-7-enterprise-amd64-winrm/Autounattend.xml#L144

marsmensch · 2013-01-23T20:55:57Z

Am 23.01.2013 um 21:38 schrieb Hippie Hacker [email protected]:

Basic="true" is set on both -winrm templates in jedi4ever/veewee@master

https://github.com/jedi4ever/veewee/blob/master/templates/windows-2008R2-serverstandard-amd64-winrm/Autounattend.xml#L158

https://github.com/jedi4ever/veewee/blob/master/templates/windows-7-enterprise-amd64-winrm/Autounattend.xml#L144

For the server, but not for the "winrm/config/client" setting ;-)

marsmensch · 2013-01-24T12:21:17Z

just sent a pull request

hh · 2013-01-24T16:40:24Z

#2 merged! Thanks @marsmench!

heymishy mentioned this issue Jan 7, 2013

veewee build error, controlvm keyboardputscancode 01 returns fails. jedi4ever/veewee#415

Closed

This was referenced Jan 24, 2013

fix winrm installation loop by activating client basic auth jedi4ever/veewee#502

Merged

documentation fix to properly enable basic auth chef/knife-windows#28

Closed

kalinadriver added this to @kalinadriver's untitled project May 12, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

waiting for winrm connection that never arrives #1

waiting for winrm connection that never arrives #1

heymishy commented Jan 7, 2013

marsmensch commented Jan 7, 2013

jedi4ever commented Jan 7, 2013

marsmensch commented Jan 17, 2013

heymishy commented Jan 21, 2013

marsmensch commented Jan 21, 2013

heymishy commented Jan 21, 2013

hh commented Jan 21, 2013

hh commented Jan 21, 2013

jedi4ever commented Jan 22, 2013

daneroo commented Jan 22, 2013

hh commented Jan 22, 2013

hh commented Jan 22, 2013

jedi4ever commented Jan 23, 2013

hh commented Jan 23, 2013

marsmensch commented Jan 23, 2013

hh commented Jan 23, 2013

marsmensch commented Jan 23, 2013

marsmensch commented Jan 24, 2013

hh commented Jan 24, 2013

waiting for winrm connection that never arrives #1

waiting for winrm connection that never arrives #1

Comments

heymishy commented Jan 7, 2013

marsmensch commented Jan 7, 2013

jedi4ever commented Jan 7, 2013

marsmensch commented Jan 17, 2013

heymishy commented Jan 21, 2013

marsmensch commented Jan 21, 2013

heymishy commented Jan 21, 2013

hh commented Jan 21, 2013

hh commented Jan 21, 2013

jedi4ever commented Jan 22, 2013

daneroo commented Jan 22, 2013

hh commented Jan 22, 2013

hh commented Jan 22, 2013

jedi4ever commented Jan 23, 2013

hh commented Jan 23, 2013

marsmensch commented Jan 23, 2013

hh commented Jan 23, 2013

marsmensch commented Jan 23, 2013

marsmensch commented Jan 24, 2013

hh commented Jan 24, 2013