hashicorp / hashicorp/vagrant

Enhancement Request: Disable Vagrant Communicator

Open
#13,619 3 comments 5 reactions 0 assignees View on GitHub
enhancement
Dominant language
Ruby
Stars
27.2k
Forks
4.4k
Avg merge
1m
Merged PRs (30d)
1

Description

**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](https://github.com/IntelLabs/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`](https://stackoverflow.com/questions/49217621/how-to-disable-ssh-when-running-vagrant-up)
- [Community-developed `vagrant-none-communicator`](https://github.com/soapy1/vagrant-none-communicator)
- [Ruby gem `vagrant-dummy-communicator`](https://preview.rubydoc.info/gems/vagrant-dummy-communicator)

**Describe the solution you'd like**
I propose adding an option to explicitly disable the communicator in the `Vagrantfile`, for example:
```ruby
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

Contributor guide

Open the contributing guide

Research direction

Begin with Vagrantfile communicator configuration, especially the proposed config.vm.communicator = "none" option, and compare the community none and dummy communicator approaches linked in the issue. Done means defining the required behavior and implementation boundary so VM lifecycle management works without SSH or WinRM, with appropriate tests identified during the investigation.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.