Image Source: Oracle
TL;DR version: if you run multiple VirtualBox VMs on the same desktop, setup 3 network interfaces on each such VM (one NAT, one internal, one bridged).
Now for the long, more entertaining (hopefully!) version:
Recently I switched from VMware Workstation to Oracle VirtualBox for my personal virtualization needs. I’m very happy overall. VirtualBox seems faster to me – when I minimize a VM, do lots of other work, then restore the VM, it is responsive right away; where vmWare would page for a minute or two. And each VirtualBox VM is in a separate host window, which I like more than VMware’s single tabbed window.
Still, I must say VMware’s networking was easier to deal with. Here’s how I ended up with 3 IP addresses in each of my local VMs…
I have a CentOS VM running Alfresco and Oracle; a Fedora VM running Apache SOLR and IntelliJ IDEA; and a Windows 2012 Server VM running Active Directory. I need connectivity to each of them from my host desktop (Windows 8.1), and they need connectivity to each other, and they need to be able to connect to Armedia’s corporate VMs. Plus, I’d rather not update my hosts file or IP settings every time I move between the office and home!
1st VirtualBox network: a Network Address Translation (NAT network) which allows each VM to talk to the other VMs, but not to any other machine; and does not allow connection from the host desktop. This meets Goal #2 (connectivity to each other). But Goals #1 and #3 are not met yet.
2nd VirtualBox network: a VirtualBox Host-Only network which allows connectivity from the host desktop. Now Goals #1 (connectivity from the host) and #2 (connectivity to each other) are just fine.
Also, both the NAT and the host-only network offer stable IP addresses; whether at home or at work, my VM’s get the same address each time, so I don’t spend 10 minutes updating IP references every time I switch location.
Danger! Here is where VirtualBox tricks you! It seems like Goal #3 (access to corporate VMs) is met too! With the NAT and internal IP addresses, I can see our internal websites and copy smaller files to and from the data center VMs. But if I transfer a larger file, I get a Connection Reset error! Twice in the last month, I’ve spent hours tracking down the “defect” in the corporate network settings. (You’d think I’d remember the problem the second time around, but in my defense, the error manifested in different ways).
Solution? Add the 3rd VirtualBox network: a bridged network (i.e. bridged to your physical network adapter, so this network causes each VM to have an IP address just like the host gets, from the corporate/home DHCP server): Now the 3rd goal is really met! I can transfer files all day long, no worries.
Something to watch out for: when you disconnect a wired ethernet cable, VirtualBox automatically changes the bridged network to bind to your wireless interface. This is nice since your VMs automatically get new addresses. BUT! When you plug in the ethernet again (which in my case deactivates the wireless), VMware does NOT switch back to the wired interface! That happened to me this morning. Spent a few hours trying to figure out why my file uploads failed. Finally saw where VirtualBox re-bound my bridged network. Changed it back to the wired interface, and all was well.