waiting for winrm connection that never arrives

[heymishy]

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]

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 notifications@github.comwrote:

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]

@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]

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]

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]

Am 21.01.2013 um 09:40 schrieb Hamish King notifications@github.com:

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]

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]

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

[hh]

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

[jedi4ever]

@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]

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

[hh]

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 chris@hippiehacker.orgwrote:

Yes. 8)

On Tue, Jan 22, 2013 at 8:23 AM, Daniel Lauzon notifications@github.comwrote:

@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]

Yes. 8)

On Tue, Jan 22, 2013 at 8:23 AM, Daniel Lauzon notifications@github.comwrote:

@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]

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]

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