I have an application which comes with a Vagrant setup that is designed for this usage scenario:

Laptop (Windows, Virtualbox host) => edit source code
+----> Vagrant VM (Linux) => build and run

Plain, default, simple, works. The sources are on a shared/synced directory, i.e., they are usually edited on the Windows host and then compiled and ran inside the VM.

Unfortunately, I prefer to use Linux development tools myself. Right now, I have this setup:

Laptop (Windows)
+----> Vagrant VM
+----> My personal VM (Linux, non-vagrant)

So my editor etc. run in the personal VM, and I have a common directory shared through Virtualbox. Again, everything works just fine.

Here is the problem:

To control the vagrant stuff, I need to enter the vagrant commands in the Windows shell, which is slowing me down. For example, to run the build inside the vagrant VM, I would prefer to use a hotkey in my editor to start vagrant ssh build.sh instead of switching to the CMD.EXE and entering that command. Unneccessary context switch.


I don't wish to open the can of worms that is "virtualization inside virtualization" (i.e., I won't run Linux Virtualbox inside a Windows-hosted VM); so this keeps me with these two alternatives:

Is there a way to control the "Windows-Vagrant" that is running on the Windows host from inside a Linux VM (which itself is not under Vagrant control), i.e., to use vagrant up or vagrant ssh?

Alternatively, is it possible to install "Linux-Vagrant" in my existing VM right away (i.e. the Debian version) and have it create its VM in the Windows host?

Or is there a completely different way to solve this problem in an elegant fashion?

  • Why do you need this setup? Do you use the right tool for the job? – 030 Jan 4 '18 at 20:42
  • @030, I must use a Windows laptop issued by my company. But as mentioned in the question, I much prefer a Linux environment for development work. Hence I usually develop in a Linux VM, with a tight workflow (Emacs etc., lots of hotkeys for starting compilations etc.). – AnoE Jan 4 '18 at 21:16
  • The actual source files are on a NTFS directory. Why? What VCS is used in the company? – 030 Jan 4 '18 at 21:38
  • It is not about the VCS, but about using Vagrant here. Vagrant is running on the host OS (Windows), and the question is about trying to control Vagrant from inside the VM (to be able to do quick keyboard-based vagrant up etc. from my editor inside the Linux VM instead of switching back to a Windows cmd shell all the time. This point actually is not of importance for the question, I have removed it. – AnoE Jan 4 '18 at 22:03

Is the answer as simple as setting up a dual-booted machine? Linux partitions for development tasks and as the VM host, Windows partitions for normal computing use.

  • Laptop
    • Windows partition
    • Linux Partition
      • Vagrant VM
  • Thanks for the suggestion, but that is not possible. – AnoE Dec 5 '17 at 18:05

One possible but kind of ugly and very brittle workaround could be to use winrm to launch the vagrant commands on windows from linux 'remotely'.

This need a networking setup for the VM so it can talk to the host through tcp/ip (configuration done on the virtualization you use), configuring winrm on the windows host (if your company allows it) and then using something like pywinrm (first found with a quick search) or any other tool in your language of choice.


I also wish to know this answer. Did you come up with anything yet? The only way I can think of is to install/create a proxy like service on the host that exposes the virtualbox/vmware command line for vagrant to use. Might also be possible for a small service on the host that listens/reads from a socket/file for incoming commands while the vm writes the commands to the socket/file. This socket/file would be in the shared directory. You would probably need 2 sockets (one for read, one for write). This could be turned into a vagrant plugin that would initially extend virtualbox plugin.

I am literally just spitballing here though. You probably can't stand up adhoc tcp servcies on you laptop but you might be able to get by with a socket/file based mechanism.

  • No, I did not... although I did not look into it anymore either. – AnoE Apr 6 at 11:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.