Enhancement Request: Disable Vagrant Communicator

[Wenzel]

Is your feature request related to a problem? Please describe.

I'm currently unable to use Vagrant purely as a VM manager without a communicator. My use case involves using Vagrant to manage a VM under test with kAFL (a fuzzer for OS kernels). Since the harness runs inside the kernel at boot time, I cannot rely on SSH becoming available. However, Vagrant enforces the presence of a communicator, making it impossible to proceed without workarounds.

I've also noticed community interest in this feature:

• StackOverflow: How to disable SSH when running vagrant up
• Community-developed vagrant-none-communicator
• Ruby gem vagrant-dummy-communicator

Describe the solution you'd like I propose adding an option to explicitly disable the communicator in the Vagrantfile, for example:

Vagrant.configure("2") do |config|
  config.vm.communicator = "none"  # New option to disable SSH/WinRM
end

This would:

• Prevent Vagrant from expecting SSH/WinRM to be available.
• Allow VM lifecycle management without unnecessary connection attempts.

Describe alternatives you've considered I've explored using custom communicators, but existing solutions (e.g., vagrant-none-communicator, vagrant-dummy-communicator) are unofficial and may not be fully maintained. The alternative is to manually manage the VM outside of Vagrant, which defeats the purpose of using Vagrant for orchestration.

Additional context If this feature aligns with Vagrant’s roadmap, I’d appreciate guidance on contributing:

1. What components need modification? Which parts of the Vagrant codebase enforce communicators?
2. Where should the none communicator be implemented? Should it be a built-in option, or would extending the plugin API be a better approach?
3. Estimated effort and complexity? Would implementing this require deep changes to Vagrant’s internals, or is it a relatively isolated modification?

Let me know if this is feasible, and if there's an existing design pattern that should be followed for such an addition.

Thanks !

---

Environment Details

• Vagrant Version: Latest
• Provider: vagrant-libvirt
• Guest OS: Windows 10 or Ubuntu 24.04
• Host OS: Ubuntu 24.04

[rreye]

I am also interested in this enhancement

[chrisroberts]

Hi there! Since Vagrant has an expectation of a viable communicator for configuring the guest, not having a working communicator can introduce unexpected instability. This is especially true for the behavior of plugins. Since the communicator is expected to be available, updating the API to make it optional would have a significant impact not only within the internal code base, but also break the contract with third party plugins.

Instead of a very high impact change, I threw together a quick :none communicator implementation that just pretends to be a communicator. With this, Vagrant is still able to behave as it always has without needing any internal modifications (along with third party provider plugins). The communicator simply stubs out all the required methods with a successful result, and Vagrant is mostly happy.

In spot testing the behavior with VirtualBox, this all works relatively well. The guest machines are spun up with the up command, though it reports /vagrant synced folder being successfully setup when it is not. They are properly destroyed with the destroy command. Running reload works, but it's not clean and will depend on a provider's implementation. Using VirtualBox, reload will attempt to gracefully shutdown the guest by sending it a command. After so long of the guest not shutting down, it will forcibly stop it and then start it back up. If a provider doesn't have a timeout defined, it would result in the command just hanging.

Running an up using VMware workstation, it fails at the end due to the inability to properly setup the synced folder in the guest.

I think that this communicator can be added, it just needs to provide some warnings to the user when in use, and some guard rails for the guest configuration (like ensuring the guest has all synced folders disabled, not provisioners defined, etc.). Once I've had time to suss out what that looks like, I'll get the PR updated and pulled out of draft.

[chrisroberts]

I'll be pushing out a patch release in the morning to address #13652. I've merged in the basic implementation of the :none communicator and hidden it within an experimental block so it will be accessible to try out, but not generally available. This will provide the ability to try it out with the caveat that it may cause unexpected results.

With the 2.4.5 release, you'll be able to enable the none communicator using the VAGRANT_EXPERIMENTAL environment variable:

export VAGRANT_ENVIRONMENTAL=none_communicator

And within your Vagrantfile, it can be set:

Vagrant.configure("2") do |config|
  config.vm.box = "..."
  config.vm.communicator = :none
end

And a follow up PR with added notifications and guards will be added shortly.