[kenny_r]

They're marketing this as a "mini-cloud". If it can only network through NAT, that eliminates all use cases where the VM instances would act as a server.

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.

[mlyle]

> They're marketing this as a "mini-cloud". If it can only network through NAT, that eliminates all use cases where the VM instances would act as a server.

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...

[trynewideas]

For a DevOps tool this seems way more developer-oriented than ops-oriented.

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.

[tomjakubowski]

I'm missing something - even without bridged networking, the VMs should still be able to network with each other, and the VM host should also be able to reach each VM. So I don't see how the lack of bridged networking prevents you from testing the deployed VMs. Do you need to control the tests from somewhere outside the VM host?

[jsjohnst]

NAT networking does not imply the host running Multipass can access ports exposed on the VMs, quite the opposite. Host only would imply that, but not typical NAT in a virtual machine. Not saying it’s not possible with Multipass, just saying it shouldn’t be assumed it does.

[mlyle]

Generally if you are on a router performing NAT, you have routes to the hosts behind the NAT. Whenever I've used VMs with NAT I've been able to interact with the NAT'd network from the actual hypervisor host.

[jsjohnst]

Which hypervisor are you using?

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

[mlyle]

Yes, VirtualBox is an exception, because it does its own weird NAT.

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.

[jsjohnst]

While I agree, some hypervisors act differently, but my original comment stands as due to at least one major hypervisor not allowing direct host access to NAT’d VMs, you can’t assume it works given no context.

Either way, thanks for the research. I stopped after checking VMware.