Maybe we have very different use cases, but I almost never use bridged networking. Typically what I want is all outgoing connections to be NATed through the host.
That said I agree, it should be an option. There are certainly use cases for it.
That said I agree, it should be an option. There are certainly use cases for it.
I'm a sysadmin, so I like tools like this to test out provisioning of servers with configuration management such as Ansible or Puppet.
Running tests at the end where I actually test the endpoints of the deployed services would be really nice to have, but impossible to do through NAT.
I guess that's a niche use case for this because Vagrant had the same issue for a long time, where setting up a bridged network was not possible or required some hacks.
As one example, VirtualBox[0] only allows host -> VM via port forwards when using NAT networking.
[0] see table 6.1 here: https://www.virtualbox.org/manual/ch06.html
VMware:
> The host computer has an adapter on the NAT network (identical to the host-only adapter on the host-only network). This adapter allows the host and the virtual machines to communicate with each other for such purposes as file sharing. The NAT never forwards traffic from the host adapter.
Libvirt/KVM:
> By default, guests that are connected via a virtual network with <forward mode='nat'/> can make any outgoing network connection they like. Incoming connections are allowed from the host, and from other guests connected to the same libvirt network, but all other incoming connections are blocked by iptables rules.
Hyper-V lets you connect from host to NAT'd guests, though the documentation doesn't explicitly say this. Parallels works this way too. Xen is a weird one, because it doesn't really do the NAT itself; if you follow the Linux instructions it'll work the way I describe.
Either way, thanks for the research. I stopped after checking VMware.
This streamlines the use cases where I need a _local_ VM that I can access from my workstation; I don't need (or even want) a tool like this to generate VMs that are externally accessible.
Vagrant — as you pointed out — already does the thing you want it to do. It's more powerful, more flexible, and more complicated.
These are just two different tools.
Think about this as if you want to carry around 3-4 hosts running different services and interacting with each other... on your laptop.
You don't really want bridged networking, because you connect to a different network and screw up the entire environment with different numbering, etc.
This way you can be on a plane without network access and still get work done, or carry a complete demonstration environment to a customer site, or...