Vagrant Support

[JoelProminic]

@JustinProminic requested that we add support for Vagrant in Moonshine. This will let the user quickly spin up a VM for a test environment or other purpose. Some possible features:

• run commands like vagrant up or vagrant halt to manage an existing configuration
• Edit the configuration in Vagrantfile
• Initialize an existing project with Vagrant? I think we would want to keep Vagrant as an "addin " available for all projects rather than having a dedicated template.
• Monitor the status of the vagrant instance?

Here are some installation instructions. Vagrant also requires at least one configured hypervisor to work (I have generally used VirtualBox).

We need to discuss this more before we start on implementation.

[JoelProminic]

More notes from @JustinProminic

After the next release, which is focused on just getting the Mac App Store version working again plus a few other mostly done already features like the new homepage (I think?), the very next thing we need to do is add to the SDK Installer and awareness in the Getting Started page:

Vagrant
VirtualBox

These is going to be a prerequisite for a lot of things Bing is working on, such as Structure4Notes.

Note that we do not need to INSTALL Vagrant and VirtualBox, we simply need to detect whether they are present on the Getting Started and add them to the SDK Menu and then auto-download them. We should then just auto-launch the installer for each one, or provide a button for the user to launch the installer.

The real point here is to add awareness of Vagrant and VirtualBox, make it as easy as possible for the user to install and launch them without having to separately go visit the websites of the vendors.

I have been working on a Vagrant build of Domino 12 that will allow us to plug Moonshine Domino related software builds directly into a live, locally running and locally built, Domino 12 server that can be quickly destroyed and recreated automatically as the user wants to experiment.

Bing is going to need Vagrant to have the NSF to Domino Visual Editor XML converter local to the user.

Bing is going to need Vagrant to have Structure4Notes Designer, Importer, and Broker local.

We need to get all of these things tied together. They will make some wonderful videos of combining all this technology.

Vagrant depends upon VirtualBox for the way I am building the Vagrant configs, which require shared folder sync only available in VirtualBox for bi-directional host to guest VM file synchronization for certain folders.

This will allow Moonshine to build something, it will automatically get injected into the Domino or Structure4Notes Vagrant VM, and the user can instantly see what they just coded.

[JoelProminic]

I added an example Vagrant project for Royale here: https://github.com/Moonshine-IDE/VagrantRoyaleExample

This will run the Royale project on a server created with Vagrant. This is not a very practical example, but it is relatively fast and simple compared to the Vagrant files that we will use in general.

[rat-moonshine]

For quick reference on installation and uninstallation process, here's some earlier discussions with @JoelProminic .

Installation

If you aren't familiar with Vagrant, here are some brief instructions on how to get started with Vagrant. We'll need to automate the Vagrant and VirtualBox installations as part of the Moonshine integration.

Download and install Vagrant from here: https://www.vagrantup.com/downloads.html

Download and install VirtualBox from here: https://www.virtualbox.org/wiki/Downloads
If you get an error installing VirtualBox on High Sierra or higher, see this page: docksal/docksal#417

Once this is done, you should be able to initialize a project like this:

cd path/to/your/project
vagrant init

And download the desired box like this:

vagrant box add centos/7

You can find more boxes here: https://app.vagrantup.com/boxes/search
The Vagrantfile documentation is here: https://www.vagrantup.com/docs/vagrantfile

Uninstallation

I see that the uninstall process is more complicated than usual, but it doesn't look too bad. I haven't needed to try this myself, but I'll probably need to do this for testing:

https://www.vagrantup.com/docs/installation/uninstallation
https://osxdaily.com/2019/01/25/uninstall-virtualbox-mac-completely/

[rat-moonshine]

Possible areas to cover:
(UPDATE)

Updating the development breakups based on the suggestion proposed by @JoelProminic :

• Add new Settings tab for Vagrant. This should only require a setting for the Vagrant Path
• Add Vagrant to About page
• Add context menu items
• Implement "vagrant up" action, writing to a log file (holding to Vagrant Support #770 (comment))
• Add a new tab on the bottom to view Vagrant output
• Add entry in Getting Started
• Implement "vagrant reload"
• Implement "vagrant halt"
• Implement "vagrant ssh" action, which opens a Terminal/Command Line
• MSDKI installation, detection for Vagrant - this requires two large installers, and I'm not sure how well we can automate this (Phase 2)

[rat-moonshine]

Following are the list of items suggested by @JustinProminic for Vagrant and MacPorts (#921 ) implementation:

1. Add to Getting Started detection: Vagrant - /usr/local/bin/vagrant
2. Add to Getting Started detection: MacPorts - /opt/local/bin/port
3. On the About screen, show the Vagrant version
4. On the About screen, show the MacPorts version
5. Add Vagrant to SDK Installer
6. Add MacPorts to the SDK Installer (for ref: https://stackoverflow.com/questions/17308629/specify-vagrantfile-path-explicity-if-not-plugin)
7. Context-menu items in sidebar - Up, Halt, Reload (to sync files), SSH. Populate against named file Vagrantfile
8. Vagrant up needs to effectively do what this wrapper script does:

#!/bin/bash
## Simple wrapper for vagrant up to write to a log as well as the console
LOG_FILE=vagrant_up.log
vagrant up  2>&1 | tee $LOG_FILE
echo "Log written to:  $LOG_FILE"

9. Have a separate Console just for the Vagrant up log (ideally)
10. Project sync directory so that as code changes, it gets auto-deployed into Vagrant VM: https://github.com/DominoIDP/domino_idp/blob/master/Vagrantfile

(Note: For 1 and 2, usually auto-setup logic handles by MSDKI codes in Moonshine; Since it'd be better to keep the MSKDI changes in Phase 2, we can arrange a static path-check logic in Moonshine side for now)

[JoelProminic]

To clarify, MacPorts has nothing to do with Vagrant and VirtualBox. See #921 for MacPorts.

My suggestion for the developmemnt order on Vagrant support is:

1. Add new Settings tab for Vagrant. This should only require a setting for the Vagrant Path
2. Add Vagrant to About page
3. Add context menu item: Vagrant > vagrant up
4. Implement "vagrant up" action, writing to a log file
5. Add a new tab on the bottom to view Vagrant output
6. Add entry in Getting Started
7. Add "vagrant reload" and "vagrant halt" actions
8. Add "vagrant ssh" action, which opens a Terminal/Command Line
9. MSDKI installation for Vagrant - this requires two large installers, and I'm not sure how well we can automate this.

We can break this into multiple issues if desired.

[rat-moonshine]

Thank you, @JoelProminic , for setting up the ordering priorities to this implementation. It'll help me.

I have updated the previous ordering/breakups of the tasks.

[rat-moonshine]

While running vagrant up in Moonshine, console shows following error and terminates the process:

: vagrant up
: Missing vbguest plugin.  Install using 'vagrant plugin install vagrant-vbguest'

I remember last night I was required to run this particular command manually on Terminal before running vagrant up. Do we need this to be a standard to execute the vagrant plugin install vagrant-vbguest before running vagrant up - every time?

This was during running from https://github.com/Moonshine-IDE/VagrantRoyaleExample.

[rat-moonshine]

Covered so far:

• Moonshine > Settings > Vagrant
• Moonshine environment variable setup for Vagrant
• Context menu generation against Vagrantfile
• vagrant up is running - check for holding
• New MSDKI entry for Vagrant and requisite initial handling
• New Vagrant entry in Getting Started
• Vagrant version tests in About
• Other related fixes

(Task breakups)

[JoelProminic]

You shouldn't need to install vagrant-vbguest before every vagrant up call, but it is something we should include with the Vagrant installation in MSDKI when we get to this point. It is odd that it showed as uninstalled for you though, so let me know if you see this problem again.

[rat-moonshine]

I'm seeing the error during every run.

[rat-moonshine]

I'm not entirely sure what is going on, but proposing an inspection to these logs and suggest me.

Since this run error, I started to execute the command as this:
vagrant plugin install vagrant-vbguest; vagrant up 2>&1 | tee vagrant_up.log

First run output:

: Installing the 'vagrant-vbguest' plugin. This can take a few minutes...
: Installed the plugin 'vagrant-vbguest (0.30.0)'!
: Bringing machine 'default' up with 'virtualbox' provider...
: ==> default: Clearing any previously set forwarded ports...
: ==> default: Clearing any previously set network interfaces...
: ==> default: Preparing network interfaces based on configuration...
:     default: Adapter 1: nat
: ==> default: Forwarding ports...
:     default: 8080 (guest) => 8080 (host) (adapter 1)
:     default: 22 (guest) => 2222 (host) (adapter 1)
: ==> default: Booting VM...
: ==> default: Waiting for machine to boot. This may take a few minutes...
:     default: SSH address: 127.0.0.1:2222
:     default: SSH username: vagrant
:     default: SSH auth method: private key
:     default: Warning: Connection reset. Retrying...
:     default: Warning: Remote connection disconnect. Retrying...
: ==> default: Machine booted and ready!
: Got different reports about installed GuestAdditions version:
: Virtualbox on your host claims:   
: VBoxService inside the vm claims: 6.1.30
: Going on, assuming VBoxService is correct...
: [default] GuestAdditions seems to be installed (6.1.30) correctly, but not running.
: Got different reports about installed GuestAdditions version:
: Virtualbox on your host claims:   
: VBoxService inside the vm claims: 6.1.30
: Going on, assuming VBoxService is correct...
: Redirecting to /bin/systemctl start vboxadd.service
: Job for vboxadd.service failed because the control process exited with error code. See "systemctl status vboxadd.service" and "journalctl -xe" for details.
: Redirecting to /bin/systemctl start vboxadd-service.service
: Job for vboxadd-service.service failed because the control process exited with error code. See "systemctl status vboxadd-service.service" and "journalctl -xe" for details.
: Got different reports about installed GuestAdditions version:
: Virtualbox on your host claims:   
: VBoxService inside the vm claims: 6.1.30
: Going on, assuming VBoxService is correct...
: VirtualBox Guest Additions: Starting.
: VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
: modules.  This may take a while.
: VirtualBox Guest Additions: To build modules for other installed kernels, run
: VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
: VirtualBox Guest Additions: or
: VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
: VirtualBox Guest Additions: Kernel headers not found for target kernel 
: 3.10.0-1127.el7.x86_64. Please install them and execute
:   /sbin/rcvboxadd setup
: modprobe vboxguest failed
: The log file /var/log/vboxadd-setup.log may contain further information.
: ==> default: Checking for guest additions in VM...
:     default: No guest additions were detected on the base box for this VM! Guest
:     default: additions are required for forwarded ports, shared folders, host only
:     default: networking, and more. If SSH fails on this machine, please install
:     default: the guest additions and repackage the box to continue.
:     default: 
:     default: This is not an error message; everything may continue to work properly,
:     default: in which case you may ignore this message.
: The following SSH command responded with a non-zero exit status.
: Vagrant assumes that this means the command failed!
: /usr/sbin/rcvboxadd setup
: Stdout from the command:
: VirtualBox Guest Additions: Starting.
: VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel 
: modules.  This may take a while.
: VirtualBox Guest Additions: To build modules for other installed kernels, run
: VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup <version>
: VirtualBox Guest Additions: or
: VirtualBox Guest Additions:   /sbin/rcvboxadd quicksetup all
: VirtualBox Guest Additions: Kernel headers not found for target kernel 
: 3.10.0-1127.el7.x86_64. Please install them and execute
:   /sbin/rcvboxadd setup
: Stderr from the command:
: modprobe vboxguest failed
: The log file /var/log/vboxadd-setup.log may contain further information.

Second run output (same session):

: Installing the 'vagrant-vbguest' plugin. This can take a few minutes...
: Installed the plugin 'vagrant-vbguest (0.30.0)'!
: Bringing machine 'default' up with 'virtualbox' provider...
: ==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
: ==> default: flag to force provisioning. Provisioners marked to run always will still run.
: ==> default: Running provisioner: shell...
:     default: Running: inline script
: ==> default: Running provisioner: shell...
:     default: Running: inline script
:     default: #### Server is starting. See log at /home/vagrant/server.log ####
:     default: #### Open the application at:  http://127.0.0.1:8080/index.html ####
: ==> default: Running provisioner: shell...
:     default: Running: inline script

While the second run output seems to start the Vagrant successfully, I'm wondering why the first run terminates abruptly.

Further observation: Now if I restarts Moonshine and run only vagrant up - it produce only the first run output.

[rat-moonshine]

Covered so far:

• Separate console window for Vagrant-only output
• Tailored context-menu in new console

[JoelProminic]

Yeah, I noticed in my testing that the script worked on the second time even if there was an error on the shared folder configuration. I think that is is skipping the shared folder setup step in this case and starting anyway. Does the server work properly in your test (and is ~/server populated)?

Looking at this error, I think there is something wrong with your current VirtualBox installation. You may want to try reinstalling:

: Got different reports about installed GuestAdditions version:  
: Virtualbox on your host claims:   
: VBoxService inside the vm claims: 6.1.30

[rat-moonshine]

Does the server work properly in your test (and is ~/server populated)?

No, running http://127.0.0.1:8080/index.html on a browser gives me this error in browser:

Error response
Error code 404.
Message: File not found.
Error code explanation: 404 = Nothing matches the given URI.

I also receive following error in running Vagrant console in Moonshine:

:     default: #### Server is starting. See log at /home/vagrant/server.log ####
:     default: #### Open the application at:  http://127.0.0.1:8080/index.html ####
: ==> default: Running provisioner: shell...
:     default: Running: inline script
:     default: 10.0.2.2 - - [03/Jan/2022 05:22:42] code 404, message File not found
:     default: 10.0.2.2 - - [03/Jan/2022 05:22:42] "GET /index.html HTTP/1.1" 404 -

I tried to re-install from VirtualBox-6.1.30-148432-OSX.dmg, but that doesn't makes any difference from earlier tests.

[rat-moonshine]

• vagrant halt implemented
• vagrant reload implemented

Add "vagrant ssh" action, which opens a Terminal/Command Line

I'm unclear about the expected behaviour from vagrant ssh, I probably need more information.

Task breakups

(A build can be downloaded from Bamboo branch build for Moonshine on macOS)

[JoelProminic]

I met with @MarkProminic, @Aszusz, and Jesse today to do some testing on macOS and Windows

macOS

We tried to test this on Jesse's mac, but we found that her hardware did not support VirtualBox.

We were also able to reproduce the issue with missing VirtualBox. After some investigation, we wound that the install location for VirtualBox (and Vagrant), /usr/local/bin, is not included in the default PATH on macOS. It seems that we will need to configure "VirtualBox Home", and add it to the PATH. We were able to test this by adding a symlink to VBoxManage in one of the existing MoonshineSDKs directories.

Also note that VirtualBox will require macOS security permissions in order to run properly. The user should normally be prompted automatically for this.

Windows

The tee command discussed above will be important to monitor the status of the Vagrant task in Moonshine. This was a major annoyance when testing today, so I'd like to get this resolve soon.

Vagrant > SSH did not work. It opened a Command Line to the correct directory, but the vagrant ssh command didn't run.

We also found some errors with the Vagrantfile for VagrantRoyaleExample on Windows. I'll create an new issue for this on that repository.

[JoelProminic]

Some more details for "VirtualBox Home":

• This should be added in the Vagrant settings page
• Title: "(Optional) VirtualBox Home - Parent directory of VBoxManage
• This should be automatically detected based on the VBoxManage command. The default path for MacOS is /usr/local/bin/VBoxManage
• If the value is populated, then define a VIRTUALBOX_HOME environment variable and add $VIRTUALBOX_HOME entry in the path
• Do not send any alerts if VIRTUALBOX_HOME is not populated, so that the user has the option to use a different provider if it is available.

[JoelProminic]

When revisiting my tests on macOS, I see that I am also now getting the VirtualBox path error:

: "/usr/local/bin/vagrant" halt 
: The provider 'virtualbox' that was requested to back the machine
: 'default' is reporting that it isn't usable on this system. The
: reason is shown below:
: Vagrant could not detect VirtualBox! Make sure VirtualBox is properly installed.
: Vagrant uses the `VBoxManage` binary that ships with VirtualBox, and requires
: this to be available on the PATH. If VirtualBox is installed, please find the
: `VBoxManage` binary and add it to the PATH environmental variable.

It seems that /usr/local/bin was not on PATH for Catalina, either! I suspect that /usr/local/bin was on the PATH previously for a different SDK, like Haxe/Neko and VAGRANT_HOME (now disabled).

I checked that VIRTUALBOX_HOME does not have special meaning for VirtualBox, so it should be fine to use it.

[JoelProminic]

I confirmed that changing the Haxe and Neko Home to /usr/local/bin cleared the VBoxManage error in Moonshine. This is not a proper solution, though - it is just a temporary workaround.

[JoelProminic]

I tried to open vagrant_up.log in Moonshine, and I got this prompt:

Moonshine should treat .log files as .txt files. Is this checking something besides the extension?

[rat-moonshine]

I have added a new "VirtualBox Home" under Settings > Vagrant.

Some notes,

• The new setting is provided through Moonshine only and there is not separate reference added through MSDKI or the Getting Started
• The default location set to /usr/local/bin on macOS and $programFiles/Oracle/VirtualBox on Windows. The path on macOS will auto-setup only on non-sandbox build (as Vagrant) since the directory will explicitly need bookmarking on sandbox
• A VIRTUALBOX_HOME variable sets to environment setting based on the validity of the path

Please, check.

[rat-moonshine]

On executing PowerShell through batch-command on Windows, I have adjusted Vagrant run-codes to accommodate PowerShell path to run with tee:

• 32/64 bit path detection
• Running with tee instead of earlier type command - I confirm the outputs are available immediately to Moonshine console
• Shall notify in console if PowerShell is not available on any particular Windows

However, I see other problem during vagrant up run on Windows - but this could be a separate thing:

: "C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe" "C:\HashiCorp\Vagrant\bin\vagrant.exe up 2>&1 | tee vagrant_up.log" 
: Log file location: F:\DevareaLocal\Prominic\GIT\VagrantRoyaleExample\vagrant_up.log 
: Bringing machine 'default' up with 'virtualbox' provider...
: ==> default: Clearing any previously set forwarded ports...
: ==> default: Clearing any previously set network interfaces...
: ==> default: Preparing network interfaces based on configuration...
:     default: Adapter 1: nat
: ==> default: Forwarding ports...
:     default: 8080 (guest) => 8086 (host) (adapter 1)
:     default: 22 (guest) => 2222 (host) (adapter 1)
: ==> default: Booting VM...
: C:\HashiCorp\Vagrant\bin\vagrant.exe : There was an error while executing `VBoxManage`, a CLI used by Vagrant
: At line:1 char:1
: + C:\HashiCorp\Vagrant\bin\vagrant.exe up 2>&1 | tee vagrant_up.log
: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:     + CategoryInfo          : NotSpecified: (There was an er...used by Vagrant:String) [], RemoteException
:     + FullyQualifiedErrorId : NativeCommandError
:  
: for controlling VirtualBox. The command and stderr is shown below.
: Command: ["startvm", "5d3fc0a0-90d6-43e7-97ba-5b6f273767c4", "--type", "headless"]
: Stderr: VBoxManage.exe: error: The virtual machine 'VagrantRoyaleExample_default_1641467976898_91276' has terminated 
: unexpectedly during startup with exit code 1 (0x1).  More details may be available in 'C:\Users\Devsena\VirtualBox 
: VMs\VagrantRoyaleExample_default_1641467976898_91276\Logs\VBoxHardening.log'
: VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

[rat-moonshine]

I tried to open vagrant_up.log in Moonshine, and I got this prompt:

Moonshine should treat .log files as .txt files. Is this checking something besides the extension?

I see .log file opens in Windows Moonshine, but on macOS.

Moonshine tries to determine a file if binary by its content - here's the current code that to determine if a file is binary - https://github.com/Moonshine-IDE/Moonshine-IDE/blob/master/ide/MoonshineSharedCore/src/actionScripts/utils/UtilsCore.as#L150. I'm not sure what in the log file makes the difference to determine between Windows and macOS, but I'd prefer to adjust the logic rather than adding any explicit handling for .log file.

[rat-moonshine]

Vagrant > SSH did not work. It opened a Command Line to the correct directory, but the vagrant ssh command didn't run.

This should be fixed now.

[JoelProminic]

I tried to open vagrant_up.log in Moonshine, and I got this prompt:

Moonshine should treat .log files as .txt files. Is this checking something besides the extension?

I see .log file opens in Windows Moonshine, but on macOS.

Moonshine tries to determine a file if binary by its content - here's the current code that to determine if a file is binary - https://github.com/Moonshine-IDE/Moonshine-IDE/blob/master/ide/MoonshineSharedCore/src/actionScripts/utils/UtilsCore.as#L150. I'm not sure what in the log file makes the difference to determine between Windows and macOS, but I'd prefer to adjust the logic rather than adding any explicit handling for .log file.

We saw some cases today where we could open a vagrant .log file in Moonshine.

Looking at the code snippet, I see that it considers files binary if it finds unicode characters in the ranges 00-08 or 0E-1F. I did some searching in a failing file, and I found a 0x1B character (ESC).

It looks like vagrant is writing some control characters to change the position of the cursor, so we may find similar problems for other characters. We may need to investigate a better solution for detecting binary files.

UPDATE: Here is a command to test for 0x1B:

grep "$(printf '\u001b')" vagrant_up.log 

[JoelProminic]

VirtualBox Home seems to work like I expect now after @rat-moonshine fixed a bug we found in the morning chat.

[rat-moonshine]

It looks like vagrant is writing some control characters to change the position of the cursor, so we may find similar problems for other characters. We may need to investigate a better solution for detecting binary files.

Looking through StackOverflow articles, it seems the most discussed and obvious solution on Unix is using file:
file -b --mime-type fileName

Unfortunately, an equivalent solution not easy available for Windows. There is a Win32 port of file available but it seems to have many of its overheads to use, on Windows.

[rat-moonshine]

A temporary fix added to open problematic .log file for now. We shall remove the fix once #966 been addressed.

[JoelProminic]

I confirmed that I can open vagrant_up.log and other .log files now, at least on macOS Catalina.

There was a bug earlier today where Vagrantfile would not open with the below error:

: Workspace changed to: Vagrant
: Error #1009
: TypeError: Error #1009
: 	at Function/actionScripts.controllers:OpenFileCommand/protected:prepareBeforeOpen/actionScripts.controllers:fileLoadCompletes()

But @rat-moonshine has already resolved the problem.

[JoelProminic]

@Aszusz and @MarkProminic reported that if we run Vagrant > Destroy and then try Vagrant > Up again, then we get errors because some Ruby processes are still running. I would like to investigate this before we close the issue, but otherwise this is looking good.

[rat-moonshine]

In a cleanly environment, I couldn't able to reproduce the Ruby process hold-up situation when tested between destroy and up respectively.

1. Chose Vagrant > Destroy from the context-menu
2. Console starts populating with output, a process/progress-bar shown up at bottom right corner
3. After some time the process over and the progress-bar disappeared from bottom right corner
4. Chose Vagrant > Up
5. A new process being started without any error

I wonder if Ruby process hold-up is reason of running many different Vagrant command in a session and if also terminates some process abruptly.

[JoelProminic]

Ugh, I had done some tests for this last week, but I don't see this in a comment:

Test	Result
Destroy then Up	Works properly
Retry above	Works properly
Run up, then kill with red button	All processes closed
Run up, then Halt	ruby command remains open for a few seconds until vagrant up finishes

I remember the last case was a problem with the original VagrantRoyaleExample, since that script itentionally never finished.

I confirmed that killing the "vagrant up" command is not enough to stop the ruby process.

1. Start Vagrant > Up in Moonshine. A fresh run will give you the more time to run this test

2. Kill the "vagrant up" process (the one with lots of environment variables)

3. Confirm that there is still a running ruby process

4. Try another vagrant up or Vagrant > Up. The command fails with the below error:

   An action 'up' was attempted on the machine 'default',
   but another process is already executing an action on the machine.
   Vagrant locks each machine for access by only one process at a time.
   Please wait until the other Vagrant process finishes modifying this
   machine, then try again.

   If you believe this message is in error, please check the process
   listing for any "ruby" or "vagrant" processes and kill them. Then
   try again.

[JoelProminic]

I moved the hanging process issue to #970.

Otherwise, I think basic Vagrant support is mostly working well.