Open frizop opened 10 years ago
@mitchellh any chance this issue and WinRM support can please be prioritized? Unless I've missed something in my test runs this is blocking a hands off provisioner run on a windows vanilla AMI base. This is somewhat a bit contrary to what's stated on the 1.6 feature preview blog: https://www.vagrantup.com/blog/feature-preview-vagrant-1-6-windows.html Vagrant 1.6 adds support for Vagrant to run Windows within the Vagrant environments (in VirtualBox, Hyper-V, EC2, etc.).
It'd be great to get this worked out so that dev iteration on EC2 Windows can run native within Vagrant-aws. For now looks like I'm having to resort to AWS SDK.
I too am having the same issue with my AWS vagrant config. My command window just blocks.
Here is my vagrant file.
Vagrant.configure("2") do |config| config.vm.box = "dummy" config.vm.communicator = "winrm" config.vm.guest = :windows
config.vm.provider :aws do |aws, override|
aws.access_key_id = "xxx"
aws.secret_access_key = "xxxx"
aws.keypair_name = "xxx"
aws.ami = "ami-fa05b392"
aws.tags = {
'Name' => "dotServer-1",
'environment' => "test",
}
aws.instance_type = "t2.micro"
aws.region = "us-east-1"
aws.security_groups = ["xxx"]
end
end
Are you sure it's actually trying to connect to SSH? I discovered that on my setup the info message is a lie, it's actually trying to connect to WinRM and in my case I know the AMI doesn't have that on it.
==> default: Waiting for SSH to become available...
INFO winrm: Checking whether WinRM is ready...
DEBUG provider: Searching for cap: winrm_info
DEBUG provider: Checking in: aws
INFO machine: Calling action: read_ssh_info on provider AWS ()
INFO runner: Preparing hooks for middleware sequence...
INFO runner: 2 hooks defined.
INFO runner: Running action: #<Vagrant::Action::Builder:0x5b7ba28>
INFO warden: Calling IN action: #<Vagrant::Action::Builtin::ConfigValidate:0x5baa9c0>
INFO warden: Calling IN action: #<VagrantPlugins::AWS::Action::ConnectAWS:0x5baaac8>
INFO connect_aws: Connecting to AWS...
INFO warden: Calling IN action: #<VagrantPlugins::AWS::Action::ReadSSHInfo:0x5c259c0>
INFO warden: Calling OUT action: #<VagrantPlugins::AWS::Action::ReadSSHInfo:0x5c259c0>
INFO warden: Calling OUT action: #<VagrantPlugins::AWS::Action::ConnectAWS:0x5baaac8>
INFO warden: Calling OUT action: #<Vagrant::Action::Builtin::ConfigValidate:0x5baa9c0>
DEBUG winrmshell: initializing WinRMShell
DEBUG winrmshell: powershell executing:
hostname
if ($?) { exit 0 } else { if($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 1 } }
INFO winrmshell: Attempting to connect to WinRM...
INFO winrmshell: - Host: xxx
INFO winrmshell: - Port: 5985
INFO winrmshell: - Username: vagrant
INFO retryable: Retryable exception raised: #<Errno::ECONNREFUSED: No connection could be made because the target machine actively refused it. - connect(2) (http://xxxx:5985)>
DEBUG winrmshell: powershell executing:
@MartinSGill you are right - I was also sitting there "Waiting for SSH to become available" but your comment did the trick - once I opened up the default port for WinRM (5985) on the VPC firewall, I was able to get passed that failure. Now I just need to figure out how to deal with the rsync failure that occurred right afterward.
@MartinSGill @jakefeasel
Did you guys ever get winrm set up to provision your windows ec2 instances?
I'm getting this output in debug mode; however, none of my provision scripts ever work:
function which {
$command = [Array](Get-Command $args[0] -errorAction SilentlyContinue)
if($null -eq $command)
{
exit 1
}
write-host $command[0].Definition
exit 0
}
function test ([Switch] $d, [String] $path) {
if(Test-Path $path)
{
exit 0
}
exit 1
}
function chmod {
exit 0
}
function chown {
exit 0
}
function mkdir ([Switch] $p, [String] $path)
{
if(Test-Path $path)
{
exit 0
} else {
New-Item $path -Type Directory -Force | Out-Null
}
}
# function to check whether machine is currently shutting down
function ShuttingDown {
[string]$sourceCode = @"
using System;
using System.Runtime.InteropServices;
namespace VagrantWindows {
public static class RemoteManager {
private const int SM_SHUTTINGDOWN = 0x2000;
[DllImport("User32.dll", CharSet = CharSet.Unicode)]
private static extern int GetSystemMetrics(int Index);
public static bool Shutdown() {
return (0 != GetSystemMetrics(SM_SHUTTINGDOWN));
}
}
}
"@
$type = Add-Type -TypeDefinition $sourceCode -PassThru
return $type::Shutdown()
}
if (ShuttingDown) {
exit 1
}
else {
# see if a reboot is scheduled in the future by trying to schedule a reboot
. shutdown.exe -f -r -t 60
if ($LASTEXITCODE -eq 1190) {
# reboot is already pending
exit 2
}
# Remove the pending reboot we just created above
if ($LASTEXITCODE -eq 0) {
. shutdown.exe -a
}
}
# no reboot in progress or scheduled
exit 0
exit $LASTEXITCODE
DEBUG winrmshell: Exit status: 4294901760
My provision script is the following:
config.vm.provision "shell", inline: "mkdir c:\hello"
@dav92lee I don't think I ever did. You can see my attempts for vagrant with ec2 and windows here: https://github.com/jakefeasel/sqlfiddle2/blob/master/Vagrantfile#L68
As you can see from the comments, I gave up trying to run the powershell provisioner in that environment, and instead just have the provisioning done prior to creating the AMI.
Is there no way to test WinRm via knife or whatever other tools you might be using? I imagine that this might break how we're spitting out shares/mounts to get chef-solo to run on the VM but I'd be happy if we could test for the open port then issue a
knife bootstrap windows winrm $host
style command or similar. I'm not sure if this fits into the whole mantra but I sort of feel like there hasn't been much support for this sort of issue. Let me know what you think.