Vagrant CLI on Windows is very slow

[keilma]

Hello,

I was not able to find something useful to solve this issue so I will try it here.
I've a fresh installation of Vagrant (no plugins) on my host, but the response of the CLI is very very slow.
For example it takes 19 seconds to get the output of "vagrant version":

PS > Measure-Command { vagrant version }

Days : 0
Hours : 0
Minutes : 0
Seconds : 19
Milliseconds : 460
Ticks : 194606842
TotalDays : 0,000225239400462963
TotalHours : 0,00540574561111111
TotalMinutes : 0,324344736666667
TotalSeconds : 19,4606842
TotalMilliseconds : 19460,6842

Environment: Windows 10 2004 Build 19041.450 (32 GB RAM, Core i7), Vagrant 2.2.10, VirtualBox 6.1.12.

Thanks in advance.

Kind regards
Marcel

[yasny]

Same here; running vagrant version takes about 7 seconds.

Environment: Windows 10 1909 (18363.1139), 16GB RAM, Core i7, Vagrant 2.2.10, VirtualBox 6.1.8.

PS> measure-command { vagrant version }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 7
Milliseconds      : 423
Ticks             : 74233471
TotalDays         : 8.5918369212963E-05
TotalHours        : 0.00206204086111111
TotalMinutes      : 0.123722451666667
TotalSeconds      : 7.4233471
TotalMilliseconds : 7423.3471

Tried adding C:\HashiCorp to the virus scan exclusion list, but no difference.

[chrisroberts]

This may be due to powershell compiling assemblies on startup which is causing the delay. Precompiling them can resolve the issue if it is indeed the root cause: https://serverfault.com/questions/761301/calling-powershell-exe-is-extremely-slow/761473#761473

[yasny]

@chrisroberts Thanks for the tip, but Vagrant is also slow using normal cmd.exe.

C:\>cmd /v:on /c "echo !TIME! & vagrant version & echo !TIME!"
 7:38:16.06
Installed Version: 2.2.10
Latest Version: 2.2.10

You're running an up-to-date version of Vagrant!
 7:38:22.76

Not as accurate as measure-command, but it's taking about 7 seconds.

I'm thinking it's a problem running the embedded ruby environment on Windows that's slow...

[keilma]

Using cmd it takes 19 seconds on my notebook:

cmd /v:on /c "echo !TIME! & vagrant version & echo !TIME!"
10:42:59,13
Installed Version: 2.2.10
Latest Version: 2.2.10

You're running an up-to-date version of Vagrant!
10:43:18,49

[chrisroberts]

@yasny / @keilma It is not an issue with running Vagrant under powershell or cmd. Vagrant executes powershell commands on Windows to determine things like available providers and user permissions. If powershell itself is slow to start, then it will result in Vagrant being slow as well. This is where precompiling the assemblies can help.

[keilma]

Hi @chrisroberts,

normal powershell operations or other scripts are working normal on my system. In the thread on serverfault it takes ~7 seconds for a write-host, on my host it's done in miliseconds:

PS> measure-command { pwsh "Write-Host test" }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 330
Ticks             : 3302527
TotalDays         : 3,82236921296296E-06
TotalHours        : 9,17368611111111E-05
TotalMinutes      : 0,00550421166666667
TotalSeconds      : 0,3302527
TotalMilliseconds : 330,2527

[AMoghrabi]

@chrisroberts Thanks for your input. Do you have any other suggestions? It's really difficult to work with Vagrant on Windows :(

[keilma]

Difficult? Not usable here.

[lispercat]

I got 28 sec for "vagarant version".
When I run full script (provision docker-compose + run docker-compose.yml) docker it takes ~40minutes.
After that "vagrant ssh" takes a very long time to connect.
Wonder how you guys use it on Windows.

Edit: that information above is for my work machine. For my much less powerful home PC, it's approximately 3 times faster. Maybe there is some big-brother s/w in between

[Pyker]

I see people in this bug report performing measurements on vagrant version, but that won't be accurate at all because it performs an HTTP request to Vagrant to fetch the latest version, so you'll have a variable extra delay from that request. Personally, I test vagrant help instead.

I did find out that it's (for some reason) faster if Vagrant is running elevated (with administrator permissions):

There also doesn't seem to be any difference between running in Windows 10's pre-installed PowerShell or PowerShell 7, because it will ALWAYS call out to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

Testing the command inside of a Vagrant environment (in this case Laravel Homestead) seems to make it run even faster:

[berney]

I also find the slow vagrant cli quit annoying, especially vagrant help. I normally get about 2.3s with the measure-command. Every time I use vagrant, I lose focus as it takes so long to complete any command that I switch tasks and get distracted.

I used SysInternals Process Monitor to record the events, filtering on vagrant.exe, ruby.exe, and powershell.exe.

It shows that majority of the execution time is the ruby process. I think the root cause is that Ruby, at least on Windows, is very slow. The PowerShell processes take a lot less time than ruby. The vagrant.exe wrapper takes very small time.

[berney]

Please remove the needs-repo and waiting-reply labels as clear repo steps have been provided and powershell has been eliminated.

[skalinkin]

We experience same delay problems. We have stopped using any vagrant commands which have alternatives on windows. I.E. vagrant ssh we use ssh directly on windows to connect to VM. The biggest issue for us is rsync. We need to send files often from Windows Vagrant Host to VM. Running vagrant rsync almost every 5 minutes drives us crazy.

[berney]

We experience same delay problems. We have stopped using any vagrant commands which have alternatives on windows. I.E. vagrant ssh we use ssh directly on windows to connect to VM. The biggest issue for us is rsync. We need to send files often from Windows Vagrant Host to VM. Running vagrant rsync almost every 5 minutes drives us crazy.

@skalinkin Just use rsync directly. Its a binary packaged in vagrant. Or you can get cwRsync, msys2 rsync etc.

[vuzzlevuzz]

I've just experienced this and found a solution here: https://www.gitmemory.com/issue/hashicorp/vagrant/10521/492835941
Commenting out those functions and just returning false sped up my cli (e.g. vagrant --help) by 4x - i.e. went from 8-9 seconds down to 2

I'm not 100% certain what these functions are required for, but as two of them are for Hyper-V which I'm not using on this machine I'm assuming it should be fairly safe to disable them

C:\HashiCorp\Vagrant\embedded\gems\2.2.14\gems\vagrant-2.2.14\lib\vagrant\util\platform.rb
  def windows_admin?
    return false

  def windows_hyperv_admin?
    return false

  def windows_hyperv_enabled?
    return false

[berney]

I've just experienced this and found a solution here: https://www.gitmemory.com/issue/hashicorp/vagrant/10521/492835941
Commenting out those functions and just returning false sped up my cli (e.g. vagrant --help) by 4x - i.e. went from 8-9 seconds down to 2

2 seconds to display help is still 2s too long.

[SecDWizar]

cmd /v:on /c "echo !TIME! & vagrant help > nul & echo !TIME!"
17:30:46.36
17:33:42.58

That's ridiculous, unusable...

I can't disable powershell/hyperv etc. as I'm using them (hyper-v).

[jarlva]

I applied @vuzzlevuzz's patch but it still takes over 10 seconds to "vagrant ssh" to a ubuntu vm from CMD (not PowerShell).
Running version 2.2.14 on latest Windows 10 with latest VirtualBox.

[mbarkhau]

Not just on Windows

$ uname -a
Linux mb-spectre 5.8.0-45-generic #51~20.04.1-Ubuntu SMP Tue Feb 23 13:46:31 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ vagrant --version
Vagrant 2.2.15
$ time vagrant --help | head -n 4
Usage: vagrant [options] <command> [<args>]

    -h, --help                       Print this help.

real	0m8.321s
user	0m3.132s
sys	0m1.211s

[Raxta]

With
config.vm.boot_timeout = 7200
'vagrant up' has been failed by timeout.
Is there any way to speed up vagrant?

[NgrNxk]

After nearly one year there is still no remedy in sight?

PS> Measure-Command { vg -h }

Days : 0
Hours : 0
Minutes : 0
Seconds : 5
Milliseconds : 270
Ticks : 52704992
TotalDays : 6.10011481481481E-05
TotalHours : 0.00146402755555556
TotalMinutes : 0.0878416533333333
TotalSeconds : 5.2704992
TotalMilliseconds : 5270.4992

PS> vg -v
Vagrant 2.2.16

[gavenkoa]

While it is convenient (and portable way) to use PowerShell to source Windows host info it is a poor choice.

Most of that info could be extracted by reading registry / invoking other utilities.

I was surprised when my report was closed #10521

Basically Vagrant is not usable on Windows. Small number of voices means the product is no longer popular on Windows.

[berney]

@chrisroberts Could you please remove the needs-repo and waiting-reply labels, repo steps are measure-command { vagrant help } in powershell.

Powershell was eliminated in #11853 (comment)

[rbuquet]

Any news on that matter?
I've just updated to Windows 20H2 (19042.630) and experience the same slowness.

vagrant -v
Vagrant 2.2.16

Measure-Command { vagrant help }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 11
Milliseconds      : 920
Ticks             : 119209993
TotalDays         : 0,000137974528935185
TotalHours        : 0,00331138869444444
TotalMinutes      : 0,198683321666667
TotalSeconds      : 11,9209993
TotalMilliseconds : 11920,9993

and it's the same in WSL2 (Ubuntu 20.04 LTS) :

$ vagrant -v
Vagrant 2.2.16

$ time vagrant help
(...)
real    0m14.309s
user    0m0.578s
sys     0m1.359s

[gavenkoa]

and it's the same in WSL2 (Ubuntu 20.04 LTS) :

Probably you configured passing control from WSL2 to Windows? WSL's vagrant delegates all commands to native Windows vagrant utility. If it is slow in Windows it is slow in WSL )) If it is not the case they just know about WSL env and try to reuse Windows powershell from Linux...

For that reason I gave up using Vagrant in WSL 1 (and patched Windows Vagrant commending some stupidly slow Hyper-virt checks, I'm with VBox xD).

[bastianb]

Still too slow in 2.3.1 - even with gavenkoa "patch" - wish doesnt seems to change anything in version 2.3.x anyway

PS C:\Users\maris\OneDrive\Pulpit\bastian\projects\provision_vm> Measure-Command {vagrant version}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 5
Milliseconds      : 702
Ticks             : 57023265
TotalDays         : 6,59991493055556E-05
TotalHours        : 0,00158397958333333
TotalMinutes      : 0,095038775
TotalSeconds      : 5,7023265
TotalMilliseconds : 5702,3265

[oleggtro]

Hashicorp probably doesn't care about Vagrant anymore... I've really wanted to try and use it, but those huge execution times ruin it

[qeba]

For those who suffer I work with patched Vagrant for 3 years, file platform.rb.diff:

c:/opt/Vagrant/embedded/gems/2.2.3/gems/vagrant-2.2.3/lib/vagrant/util/platform.rb


--- platform.rb.orig	2020-09-29 14:01:55.477153300 +0300
+++ platform.rb	2019-05-16 00:42:37.032299600 +0300
@@ -75,6 +75,8 @@
         #
         # @return [Boolean]
         def windows_admin?
+          # EDITED gavenkoa
+          return false
           return @_windows_admin if defined?(@_windows_admin)
 
           @_windows_admin = -> {
@@ -99,6 +101,8 @@
         #
         # @return [Boolean]
         def windows_hyperv_admin?
+          # EDITED gavenkoa
+          return false
           return @_windows_hyperv_admin if defined?(@_windows_hyperv_admin)
 
           if ENV["VAGRANT_IS_HYPERV_ADMIN"]
@@ -136,6 +140,8 @@
         #
         # @return [Boolean]
         def windows_hyperv_enabled?
+          # EDITED gavenkoa
+          return false
           return @_windows_hyperv_enabled if defined?(@_windows_hyperv_enabled)
 
           @_windows_hyperv_enabled = -> {

Note that my provider is VirtualBox so I disabled calls to PowerShell that should return false about Hyper-V.

This reduces slowness from 15 sec to 2-4 sec. My corporate antivirus adds additional slowness so in your case it might run faster.

Tried this with VMWare as provider but still slow, any idea what should be modify for WMare provider?

[libinglong]

Measure-Command {vagrant help}

Days : 0
Hours : 0
Minutes : 0
Seconds : 21
Milliseconds : 357
Ticks : 213575355
TotalDays : 0.000247193697916667
TotalHours : 0.00593264875
TotalMinutes : 0.355958925
TotalSeconds : 21.3575355
TotalMilliseconds : 21357.5355

It's crasy, windows 10. 4c 32g

[simplytech]

In case it's helpful, here are my timings:

MacBook Pro 2015:

$ time vagrant help > /dev/null
real 0m1.656s
user 0m1.278s
sys  0m0.214s

$ time ruby -e ''
real 0m0.150s
user 0m0.071s
sys  0m0.044s

Mac Mini 2018:

$ time vagrant help > /dev/null
real 0m1.378s
user 0m1.264s
sys  0m0.107s

$ time ruby -e ''
real 0m0.107s
user 0m0.064s
sys  0m0.032s

Dell Latitude 5410

C:\>cmd /v:on /c "echo !TIME! & vagrant help >NUL: & echo !TIME!"
18:44:08.58
18:44:15.76

C:\>cmd /v:on /c "echo !TIME! & c:\HashiCorp\Vagrant\embedded\mingw32\bin\ruby.exe -e 'puts :hello' & echo !TIME!"
18:44:30.68
hello
18:44:30.84

So, I conclude that:

• starting the Ruby interpreter is fast both on macOS and Windows.
• when Vagrant runs the Ruby interpreted language (I can't imagine that there are any OS system calls for vagrant help), macOS takes ~1.4-1.7s and Windows takes ~7s. So, I think running any Ruby program on Windows is much slower than macOS.
  Also, maybe this explains some of our frustrations: https://stackoverflow.com/questions/920201/why-is-ruby-so-much-slower-on-windows

[gavenkoa]

@simplytech You can install ts utility from moreutils (I use Cygwin) and have more fun with:

VAGRANT_LOG=debug vagrant help |& ts -s %.S
VAGRANT_LOG=debug vagrant help |& ts -i %.S

[ferchuni]

It is unacceptable. Vagrant 2.3.2 and Win 11.
I got 15 seconds for vagrant help and vagrant ssh.

It is very disappointing. It works great under Linux.

[AlexC-Sophos]

Any update on this?

[tuxerrante]

I've just experienced this and found a solution here: https://www.gitmemory.com/issue/hashicorp/vagrant/10521/492835941 Commenting out those functions and just returning false sped up my cli (e.g. vagrant --help) by 4x - i.e. went from 8-9 seconds down to 2

I'm not 100% certain what these functions are required for, but as two of them are for Hyper-V which I'm not using on this machine I'm assuming it should be fairly safe to disable them

C:\HashiCorp\Vagrant\embedded\gems\2.2.14\gems\vagrant-2.2.14\lib\vagrant\util\platform.rb
  def windows_admin?
    return false

  def windows_hyperv_admin?
    return false

  def windows_hyperv_enabled?
    return false

Did you had to restart something than? Is not working for me.
I have HyperV enabled since I use it on other VirtualBox VMs, but I don't think it is doing something here.

Windows 11
vagrant version 2.3.4

Vagrant.configure("2") do |config|
  config.vm.box = "generic/ubuntu2204"
  memory = 6144
  cpus = 4

  config.vm.provider :virtualbox do |v|
    v.memory = memory
    v.cpus = cpus
  end

  config.vm.provider :libvirt do |v|
    v.memory = memory
    v.cpus = cpus
  end

[gavenkoa]

Did you had to restart something than? Is not working for me.

I used VirtualBox provider, not HyperV. So the code should be updated for windows_hyperv_enabled?.

The workaround is about replacing costly powershell invocations with constants like True/False, unfortunately it is internals of Vagrant... so the success could vary and nothing is guarantied.

[mic345]

Hi there,

We're using Vagrant 2.3.4 on Windows 11 and it's still extremely slow, see the attached screenshot. Unfortunately gavenkoa's patch did not work for us.

Any suggestions?

[pcgeek86]

Just set up a new Windows 11 system, Ryzen 9 5900X, 64GB DDR4, Samsung 970 PRO NVMe SSD, RTX 2080. Installed Vagrant with scoop package manager.

Vagrant currently takes 4 seconds to run with zero parameters / arguments.

[Luxvao]

Will there ever be a fix?

[anzz1]

Vagrant is by a wide margin the best option for running VMs on Windows, including Docker containers via boot2docker , which I find much better than the native Docker implementation.

However this is a pretty major annoyance that the vagrant ruby script is painfully slow. It seems that independent of the command, there is a 2 second "thinking" period before actually executing the command, which itself is fast. For example, a vagrant --help takes 2031 ms to complete and vagrant global-status takes 2033ms on Windows 7 x64.

It looks like it sleeps for 2030ms and then does the work, and the actual work takes just milliseconds. The other commenters having even larger delays can be chalked up to the fact that Windows peaked on 7 and has been a dumpster fire of hot garbage rolling downhill ever since. Unlike the later iterations, 7 doesn't f*ck with your access times, so the 2 second delay is definitely something on Vagrant's end.

e: to help in narrowing it down, the proposed solution of overriding these functions:
C:\HashiCorp\Vagrant\embedded\gems\2.3.4\gems\vagrant-2.3.4\lib\vagrant\util\platform.rb

def windows_admin?
  return true
end
def windows_hyperv_admin?
  return false
end
def windows_hyperv_enabled?
  return false
end

made zero difference, i.e. the delta execution speed was ~100 microseconds, having an insignificant impact.

[gavenkoa]

It looks like it sleeps for 2030ms and then does the work, and the actual work takes just milliseconds

I could confirm it: Ruby VM startup time is about 3-4s on my PC (due to Sophos antivirus intercepting read of files).

@anzz1 You could reveal finer details with VAGRANT_LOG=debug of what is happening after initial Ruby VM startup delay :

VAGRANT_LOG=debug vagrant help
VAGRANT_LOG=debug vagrant help |& ts -s %.S
VAGRANT_LOG=debug vagrant help |& ts -i %.S

It shows lots of activity

[anzz1]

@anzz1 You could reveal finer details with VAGRANT_LOG=debug of what is happening after initial Ruby VM startup delay

Thanks for this, very useful. Indeed , if I replace C:\HashiCorp\Vagrant\embedded\gems\2.3.4\gems\vagrant-2.3.4\lib\vagrant.rb with just a exit 1 , it still takes 300ms to start up and do nothing at all.

Im leaning towards Ruby simply being slow / unoptimized as a language, that it's not necessarily caused by any bug.

However, there is definitely some room for optimization in Vagrant's side. Looking at the log, I am loading every single host platform/guest platform/provisioner/provider/protocol plugin under the sun when running any command. Shouldn't those be loaded as-needed instead? I don't necessarily need to load a plugin for Trisquel guest, heroku protocol or CFEngine provisioner everytime I run a command to launch my linux vm locally. And for host platforms, why is anything else than Windows host loaded at all when I'm on Windows?

[luk-sam]

varant on windows 10 is a nightmare.

measure-Command { vagrant.exe -h }
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 15
Milliseconds      : 298
Ticks             : 152989054
TotalDays         : 0,000177070664351852
TotalHours        : 0,00424969594444444
TotalMinutes      : 0,254981756666667
TotalSeconds      : 15,2989054
TotalMilliseconds : 15298,9054

@hashicorp-cloud
Does anyone work on this issue? it seems that MS doesn't have support from hashicorp, otherwise how do you explain a problem that has been going on for 3 years

[anzz1]

vagrant on windows 10 is a nightmare.

FTFY. When something that takes 2 seconds to run in Windows 7 (which is still too much), takes 15 seconds on Windows 10, there is not much the developers of Ruby, of Vagrant, of Mars Curiosity Rover, or anyone can do. And Windows 11 is even worse.

You could try asking Microsoft to scrap the fail that is current-day Windows, and keep supporting W7 indefinitely to have a fast and stable OS. Good luck with that, though.

[mic345]

Nonsense, it takes 157 millis to create two random files, 1MB each, and then run a diff between the two on Windows 11…

There shouldn't be any reason whatsoever for basic vagrant commands to take full seconds.

$ time ( ( tr -dc "A-Za-z0-9" </dev/urandom | head -c $(( 1024*1024 )) > /tmp/a ) && ( tr -dc "A-Za-z0-9" </dev/urandom | head -c $(( 1024*1024 )) > /tmp/b ) && diff /tmp/a /tmp/b > /dev/null )

real    0m0.157s
user    0m0.015s
sys     0m0.030s

$ uname -a
CYGWIN_NT-10.0 LAPTOP-44CNT3RE 3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin

[anzz1]

Nonsense, it takes 157 millis to create two random files, 1MB each, and then run a diff between the two on Windows 11…

There shouldn't be any reason whatsoever for basic vagrant commands to take full seconds.

$ time ( ( tr -dc "A-Za-z0-9" </dev/urandom | head -c $(( 1024*1024 )) > /tmp/a ) && ( tr -dc "A-Za-z0-9" </dev/urandom | head -c $(( 1024*1024 )) > /tmp/b ) && diff /tmp/a /tmp/b > /dev/null )

real    0m0.157s
user    0m0.015s
sys     0m0.030s

$ uname -a
CYGWIN_NT-10.0 LAPTOP-44CNT3RE 3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin

There is so much wrong in your methodology of testing I/O perf under Windows that I do not even know where to start.
To even begin to understand why everything about that is wrong, I suggest starting from the basics, firing up a debugger and running your command under it and see how much it takes to actually reach a kernel syscall which actually does file I/O (hint: NtReadFile/ZwReadFile & NtWriteFile/ZwWriteFile)

[mic345]

The entire point is that even with I/O the operation takes 1/50 of the time it takes to run a simple Vagrant command on the same system...

You can run the same without I/O, see if it takes longer 😉

[anzz1]

The entire point is that even with I/O the operation takes 1/50 of the time it takes to run a simple Vagrant command on the same system...

You can run the same without I/O, see if it takes longer 😉

And my point is that when you run the same command on Windows 7, it takes 2 seconds instead of 15. I don't understand what is the argument you are trying to make. It seems that you do not either. Yes, sure, there are some words, but they make very little sense. What part is exactly "nonsense" according to you, the expert?

[npc203]

For me any cli command takes around a minute, running with --debug, shows that it's stuck at

DEBUG meta: validating LANG value for virtualbox cli commands
 INFO subprocess: Starting process: ["C:\\HashiCorp\\Vagrant\\embedded\\usr\\bin/locale.EXE", "-a"]
DEBUG subprocess: Selecting on IO

Sure enough, if I run the locale.exe -a separately as well, it takes a long while, any ideas to fix it?

[wiretail]

I recollect (but can’t test right now) you can just rename/remove locale.exe and it will skip and still work.

[npc203]

@rgreer4 Yup, that just worked like a charm, deleting locale.exe reduced the time taken from 1minute-ish to 4-7 seconds!

I'd say, still sluggish for a cli, but very much usable for me, thanks!

[CrackerJackMack]

deleting locale.exe sped up my commands. no -- I didn't measure, but I can run commands without getting bored.

[JasonD94]

I've noticed this same issue on Windows 11 Pro (23H2) but interestingly when I switched to dual booting with Fedora 40 (KDE Plasma version on Linux 6.8.9-300.fc40.x86_64) I noticed significantly faster vagrant CLI speeds. Here's an example with vagrant status:

# Windows 11 Pro
$ time vagrant status
real    0m4.980s
user    0m0.000s
sys     0m0.000s

# Fedora 40 KDE Plasma
jdowning@fedora:tcbase$ time vagrant status
real    0m1.701s
user    0m0.838s
sys     0m0.574s

Under Linux things are about 3x faster for "basic" CLI commands (status, box list, version, help, etc - things that probably only do a handful of checks).

This gets more interesting when I look at bringing up a Rocky Linux VM guest with Vagrant. I have a number of ports forwarded, 3 shared folders mounted, etc so I expect this to take some time but the difference between Windows 11 and Fedora 40 is crazy:

# Windows 11 Pro
$ time vagrant up
real    12m0.201s   # yes, this is 12 MINUTES to boot up a VM...
user    0m0.000s
sys     0m0.015s

# Fedora 40
jdowning@fedora:tcbase$ time vagrant up
real    0m37.070s
user    0m3.896s
sys     0m3.963s

We're talking 24x slower on Windows vs Linux. To add additional notes, I'm using Virtualbox as the guest provider - Version 7.0.14 r161095 (Qt5.15.2) on both Windows 11 and Fedora 40. I am also using GitBash on Windows 11 and bash on Fedora 40. It seems to me, looking at DEBUG output from the Windows 11 logs I collected, that on Windows Powershell may be used at times, even when running under GitBash.

I also noticed that mounting three shared folders took about 6 mins in Windows 11 vs about 9 seconds on Fedora. Another slow part seems to be the machine booting process. On Windows, this takes about 5 mins between boot/checking for guest additions. On Linux this is the longest step, but it still only takes 24 seconds.

I've tried a few of the things in this thread to see if I can speed up Windows 11. I used the platform.rb changes from this comment: #11853 (comment)

I also tried deleting locale.EXE as suggested recently. Nothing seems to have improved things. It seems like the theory that Powershell or Ruby is slowing things down on Windows might be something worth looking into. I've collected some debug logs with --debug-timestamps that I'm analyzing now, but I wanted to share that this is still a problem even in 2024.

[JasonD94]

I might have found a potential solution to my problem. It appears that on Windows 11 Pro some Hyper-V settings were enabled by default. I found that this was causing Virtualbox to enter "Snail execution mode":

00:00:00.852350 NEM: NEMR3Init: Snail execution mode is active!
00:00:00.852350 NEM: Note! VirtualBox is not able to run at its full potential in this execution mode.
00:00:00.852350 NEM:       To see VirtualBox run at max speed you need to disable all Windows features
00:00:00.852350 NEM:       making use of Hyper-V.  That is a moving target, so google how and carefully
00:00:00.852350 NEM:       consider the consequences of disabling these features.

(these are logs from Virtualbox which you can find by going to the Virtualbox GUI and clicking on Machine -> Show Log or hitting CTRL + L)

It seems like this was the problem. After following steps listed in this Virtualbox forum post: https://forums.virtualbox.org/viewtopic.php?f=25&t=99390

I find that vagrant up now takes about 2 mins under Windows 11:

$ time vagrant up
Bringing machine 'dev' up with 'virtualbox' provider...
==> dev: Clearing any previously set forwarded ports...
==> dev: Fixed port collision for 8080 => 8080. Now on port 2200.
==> dev: Fixed port collision for 9000 => 9000. Now on port 2201.
==> dev: Clearing any previously set network interfaces...
==> dev: Preparing network interfaces based on configuration...
    dev: Adapter 1: nat
    dev: Adapter 2: intnet
==> dev: Forwarding ports...
    dev: 22 (guest) => 2222 (host) (adapter 1)
    dev: 25 (guest) => 2525 (host) (adapter 1)
    dev: 8080 (guest) => 2200 (host) (adapter 1)
    dev: 6006 (guest) => 6006 (host) (adapter 1)
    dev: 80 (guest) => 8081 (host) (adapter 1)
    dev: 443 (guest) => 8443 (host) (adapter 1)
    dev: 18082 (guest) => 18082 (host) (adapter 1)
    dev: 8983 (guest) => 8983 (host) (adapter 1)
    dev: 9876 (guest) => 9876 (host) (adapter 1)
    dev: 9000 (guest) => 2201 (host) (adapter 1)
    dev: 15672 (guest) => 15672 (host) (adapter 1)
==> dev: Booting VM...
==> dev: Waiting for machine to boot. This may take a few minutes...
    dev: SSH address: 127.0.0.1:2222
    dev: SSH username: vagrant
    dev: SSH auth method: private key
==> dev: Machine booted and ready!
[dev] GuestAdditions 7.0.14 running --- OK.
==> dev: Checking for guest additions in VM...
==> dev: Setting hostname...
==> dev: Configuring and enabling network interfaces...
==> dev: Mounting shared folders...
    dev: # censored this part, but I have 3 shared folders that I bring up for software dev purposes
==> dev: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> dev: flag to force provisioning. Provisioners marked to run always will still run.

real    2m2.227s
user    0m0.000s
sys     0m0.000s

This is still several times slow than Linux, but it's at least faster than before by several times.

Highly recommend folks on Windows using Vagrant with Virtualbox take a look at their Hyper-V settings and disable them if possible. Seems like Snail execution mode can cause a lot of slow down with Virtualbox VMs that vagrant seems to handle, but will perform slower than necessary if the Hyper-V programs / features in Windows 11 are disabled.

[colemar]

Vagrant 2.4.1 fresh installation on Windows 10 x64.
Both vagrant help and vagrant version spend about 20 seconds on the last line of this debug log:

DEBUG bundler: resolving solution from available specification set
DEBUG bundler: solution set for configured plugins has been resolved
DEBUG bundler: activating solution set
DEBUG bundler: Activating solution set: []
DEBUG solution_file: plugin file does not exist, not storing solution
DEBUG bundler: solution set stored to - <Vagrant::Bundler::SolutionFile:C:/Users/colem/.vagrant.d/plugins.json:C:/Users/colem/.vagrant.d/bundler/global.sol:invalid>
 INFO manager: Loading plugins...
 INFO loader: Loading configuration in order: [:home, :root]
DEBUG loader: Configuration loaded successfully, finalizing and returning
DEBUG push: finalizing
 INFO subprocess: Starting process: ["c:\\windows\\system32\\windowspowershell\\v1.0\\/powershell.EXE", "-NoLogo", "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass", "-Command", "Write-Output $PSVersionTable.PSVersion.Major"]
 INFO subprocess: Command not in installer, restoring original environment...
DEBUG subprocess: Selecting on IO

In this case Powershell is the culprit, and I already knew Powershell (any version) is very slow to start.
Precompiling the assemblies with ngen.exe did not help.

[behniafb]

Solution:
Uninstall Vagrant on Windows & use Vagrant on WSL (namely Linux).