Parallels / vagrant-parallels

Vagrant Parallels Provider

Home Page:https://parallels.github.io/vagrant-parallels

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Vagrant tries to use IPv6 address and fails to connect via WinRM

yoonjs2 opened this issue · comments

Latest vagrant version(2.3.7 ARM64) keep throwing error when provisioning box with environment below:

vagrant version: 2.3.7 ARM64 (mac)
host os: macos ventura 13.4.1
guest os: windows 11
provider: vagrant-parallels
plugin version: 2.4.0 (global)

I've search the github and found similiar error occurred in other providers and its resolved:

hashicorp/vagrant#8759
hashicorp/vagrant#8831

Any helps?

Bringing machine 'default' up with 'parallels' provider...
==> default: Registering VM image from the base box 'hbsmith/win11-arm'...
==> default: Creating new virtual machine as a linked clone of the box image...
==> default: Unregistering the box VM image...
==> default: Setting the default configuration for VM...
==> default: Checking if box 'hbsmith/win11-arm' version '1.0.3-1681257111' is up to date...
==> default: A newer version of the box 'hbsmith/win11-arm' for provider 'parallels' is
==> default: available! You currently have version '1.0.3-1681257111'. The latest is version
==> default: '1.0.3-1689118652'. Run `vagrant box update` to update.
==> default: Setting the name of the VM: hbsmith-win11
==> default: Preparing network interfaces based on configuration...
    default: Adapter 0: shared
    default: Adapter 1: hostonly
==> default: Clearing any previously set network interfaces...
==> default: Forwarding ports...
    default: 3389 => 3389
    default: 5985 => 55985
    default: 5986 => 55986
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: WinRM address: fe80::9cad:d266:f71e:8eba:5985
    default: WinRM username: vagrant
    default: WinRM execution_time_limit: PT2H
    default: WinRM transport: negotiate
==> default: Forcing shutdown of VM...
==> default: Clearing any previously set forwarded ports...
==> default: Destroying VM and associated drives...
==> default: Destroying unused networking interface...
Traceback (most recent call last):
	27: from /opt/vagrant/embedded/gems/2.3.4/gems/logging-2.3.1/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'
	26: from /opt/vagrant/embedded/gems/2.3.4/gems/vagrant-2.3.4/lib/vagrant/action/builtin/wait_for_communicator.rb:16:in `block in call'
	25: from /opt/vagrant/embedded/gems/2.3.4/gems/vagrant-2.3.4/plugins/communicators/winrm/communicator.rb:31:in `wait_for_ready'
	24: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:110:in `timeout'
	23: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:33:in `catch'
	22: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:33:in `catch'
	21: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:33:in `block in catch'
	20: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:95:in `block in timeout'
	19: from /opt/vagrant/embedded/gems/2.3.4/gems/vagrant-2.3.4/plugins/communicators/winrm/communicator.rb:57:in `block in wait_for_ready'
	18: from /opt/vagrant/embedded/gems/2.3.4/gems/vagrant-2.3.4/plugins/communicators/winrm/communicator.rb:106:in `ready?'
	17: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:110:in `timeout'
	16: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:33:in `catch'
	15: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:33:in `catch'
	14: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:33:in `block in catch'
	13: from /opt/vagrant/embedded/lib/ruby/2.7.0/timeout.rb:95:in `block in timeout'
	12: from /opt/vagrant/embedded/gems/2.3.4/gems/vagrant-2.3.4/plugins/communicators/winrm/communicator.rb:107:in `block in ready?'
	11: from /opt/vagrant/embedded/gems/2.3.4/gems/vagrant-2.3.4/plugins/communicators/winrm/shell.rb:70:in `cmd'
	10: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/connection.rb:39:in `shell'
	 9: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/connection.rb:74:in `shell_factory'
	 8: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/connection.rb:80:in `transport'
	 7: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/http/transport_factory.rb:27:in `create_transport'
	 6: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/http/transport_factory.rb:33:in `init_negotiate_transport'
	 5: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/http/transport_factory.rb:33:in `new'
	 4: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/http/transport.rb:149:in `initialize'
	 3: from /opt/vagrant/embedded/gems/2.3.4/gems/winrm-2.3.6/lib/winrm/http/transport.rb:27:in `initialize'
	 2: from /opt/vagrant/embedded/lib/ruby/2.7.0/uri/common.rb:234:in `parse'
	 1: from /opt/vagrant/embedded/lib/ruby/2.7.0/uri/rfc3986_parser.rb:73:in `parse'
/opt/vagrant/embedded/lib/ruby/2.7.0/uri/rfc3986_parser.rb:67:in `split': bad URI(is not URI?): "http://fdb2:2c26:f4e4:0:8cbf:21c:ae62:6d7e:5985/wsman" (URI::InvalidURIError)

@yoonjs2 Do you need to use WinRM? We have a set of packer examples in one of our repos and we decided to use the WinSSH as it is faster. Please have a look at the Packer Examples Repo example. Let me know if you can use that or not

@cjlapao I found this problem caused by dual network adapter (WiFi + USB-C LAN) and everything works fine after switch adapter priority like below (make WiFi as first) or turn off USB-C LAN adapter. and also found another problem: winRM is broken on vagrant 2.3.7 (hashicorp/vagrant#13211) so I switched to winSSH and works fine. Thank you for the assistance.
Screenshot 2023-07-24 at 10 40 59 AM