search

hh / windows-fromscratch

Windows Vagrant VM from scratch
97 stars 21 forks source link

waiting for winrm connection that never arrives #1

Open heymishy opened 11 years ago

heymishy commented 11 years ago

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 commented 11 years ago

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/hh/windows-fromscratch/issues/1.

jedi4ever commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

hh commented 11 years ago

So we don't need to use my vagrant branch anymore... https://github.com/jedi4ever/veewee/commit/f45954fb0402d2cdfb44fc0d3cec7c34f3e11591

jedi4ever commented 11 years ago

@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 commented 11 years ago

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

hh commented 11 years ago

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/hh/windows-fromscratch/issues/1#issuecomment-12552172.

hh commented 11 years ago

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/hh/windows-fromscratch/issues/1#issuecomment-12552172.

jedi4ever commented 11 years ago

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 commented 11 years ago

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 schisamo/em-winrm#8

marsmensch commented 11 years ago

Am 21.01.2013 um 11:20 schrieb Hamish King notifications@github.com:

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 commented 11 years ago

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 commented 11 years ago

Am 23.01.2013 um 21:38 schrieb Hippie Hacker notifications@github.com:

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 commented 11 years ago

just sent a pull request

hh commented 11 years ago

2 merged! Thanks @marsmench!