Winrm too quick for Windows sysprep

[John Smith]

Hi,

Using 1.8.4

I have created Vagrant file that launches a Windows VM using vCenter Server with the provider plugin from NSIDC. It's all working fine and dandy except that when Winrm tries to authenticate it happens before sysprep can finish.

Bringing machine 'default' up with 'vsphere' provider...

==> default: Calling vSphere CloneVM with the following settings:

==> default:  -- Template VM: xxxxxx/vm/w2k8_r2_base_remoting

==> default:  -- Target VM: xxxxxx/vm/vagrant01

==> default: New virtual machine successfully cloned

    default: WinRM address: xxx.xxx.xxx.xxx:5985

==> default: Waiting for machine to boot. This may take a few minutes...

    default: WinRM username: xxxxxx <------- This section executes immediately. Sysprep takes a while and also reboots a couple times...

    default: WinRM execution_time_limit: PT2H

    default: WinRM transport: negotiate

No route to host - connect(2) for "xxx.xxx.xxx.xxx" port 5985 (xxx.xxx.xxx.xxx:5985)

In vSphere client the machine created properly and is accessible with RDP etc...

If I run vagrant up again for the sake of it...

Bringing machine 'default' up with 'vsphere' provider...

==> default: The VM is already created

    default: WinRM address: xxx.xxx.xxx.xxx:5985

==> default: Waiting for machine to boot. This may take a few minutes...

    default: WinRM username: xxxxxx

    default: WinRM execution_time_limit: PT2H

    default: WinRM transport: negotiate

==> default: Machine booted and ready!

So is there a way to tell vagrant to wait before it tries to winrm?

[Alvaro Miranda Aguilera]

hello, not sure if there is something natively, but maybe vagrant trigger can help, maybe running a sleep/wait on host after up, before script.

alvaro

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/83cab438-b487-48d9-bc6c-266bdee2ae7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Smith]

Cool I will try the trigger plugin. The cosequence is because of sysprep. Basically you get that "Configuring windows for the first time" screen which takes for ever and also causes windows to reboot.

[John Smith]

Ok so I'm trying the trigger plugin

This one works, it prints firing trigger before get state a few times

        config.trigger.before :ALL do

                info "STATE!!!!"

        end

This one doesn't work, nothing gets called

        config.trigger.before :state do

                info "STATE!!!!"

        end

This one doesn't work, nothing gets called

        config.trigger.before :boot do

                info "BOOT!!!!"

        end

[John Smith]

Hi can someone confirm if I can do this with the vagrant trigger plugin?

I'm looking at the vagrant vSphere plugin and on action up 

def self.action_up
	Vagrant::Action::Builder.new.tap do |b|
	b.use HandleBox
	b.use ConfigValidate
	b.use ConnectVSphere
	b.use Call, IsCreated do |env, b2|
	if env[:result]
	b2.use MessageAlreadyCreated
	next
	end
	b2.use Clone
	end
	b.use Call, IsRunning do |env, b2|
	b2.use PowerOn unless env[:result]
	end
	b.use CloseVSphere
	b.use WaitForCommunicator
	b.use Provision
	b.use SyncedFolders
	b.use SetHostname
	end
	end

Is there a way to trigger on wait for communicator?

[John Smith]

Or is there a way to tell winrm communicator to retry more times or set longer timeout somehow?

Keeping in mind that sysprep takes a while and also reboots the machine a couple of times...

[John Smith]

Ok there an undocumented config from the original plugin...

config.winrm.max_tries

This seems to work...