Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The VirtualBox "Host-only Adapter" creates a virtual private LAN. First, VirtualBox creates a dummy LAN connector on the host computer. In Windows you get a system dialog asking if you want to install a new device. It looks just like a real LAN adapter, only there is no hardware. Then VMs that are configured to use "Host-Only adapters" each get their own simulated LAN adapter hardware. VirtualBox connects the host computer and the VMs to each other as if all these simulated LAN adapters were plugged into a simulated Ethernet switch. The VMs can talk to the host and to each other, but VirtualBox does not create a NAT function.

There is actually a virtual LAN adapter that appears to the host computer as an additional Ethernet adapter connected to a separate network. The VMs that are configured to use "Host-only Adapter" then get connected to this virtual network. The result is essentially the same as plugging a real LAN adapter into your development computer, then connecting it to a small desktop Ethernet switch and plugging in real computers that are running instances of the Sandbox operating system.

This small virtual private network has to have its own IP addresses, and following the universal convention for home or office private networks we assign a 192.168.*.* address. Windows likes 192.168.137.* for reasons that will become clear below. The host is assigned address 192.168.137.1 and the VMs are 192.168.137.10 (and 11 and so on). The VMs believe that the host 192.168.137.1 is the IPv4 gateway address connecting them to the outside world (Yale and the Internet).

Desktop computers are not IP routers by default. You have to turn something on. Windows calls this Internet Connection Sharing (ICS) and the Mac has the same feature without the formal name.

On Windows, go to Control Panel - Network and Internet - Network Connections. Right click the real Ethernet adapter (not the VirtualBox Host-Only adapter). Select Properties from the menu. At the top of the dialog there is a Sharing tab. Click the first check box "Allow other users to connect ..." and unclick the second checkbox. Click OK. There will be a large popup warning you (not very clearly) that this is going to change the IPv4 address of the other adapter (the VirtualBox adapter) to 192.168.137.1 and you should only enable sharing if this is OK. Since 192.168.137 is built into Windows, this explains why that particular address was selected for VirtualBox.

ICS is designed for end user client machines. In a home network it allows one desktop machine to share its connection to an ISP with other computers. These days this function is performed by a separate Wireless Router box, so ICS is not widely used any more. Turning on ICS triggers several distinct configuration steps. Because a developer operates in a more complicated environment than the typically home network, it is useful to explain how it works:

  1. Although you configure ICS on the adapter that you are supposed to be "sharing" with other computers, that adapter (the real LAN adapter) is not changed at all. It has the same IP address or continues to get its address from DHCP. It can be a wired LAN, Wireless LAN, or a VPN simulated LAN adapter.
  2. The IP address of the other LAN adapter (the VirtualBox Host-Only adapter) is changed one time only to 192.168.137.1. We have arranged for this to be the right address, but if you don't like it you are free to change it after you turn ICS on.
  3. ICS enables a DHCP server on your Windows host operating system. The DHCP only serves the VirtualBox Host-Only adapter. It vends 192.168.137.* subnet addresses to any VMs that do not have a static IP address assigned to them. However, the Sandbox CAS cluster uses static IP addresses, so it never actually uses the DHCP server. If you change the IP address of the Host-Only adapter to use another subnet, the DHCP server is not reconfigured. It continues to vend 192.168.137.* addresses to the VMs, but now if the host is no longer 192.168.137.1, any VM that uses DHCP will get a useless address and not be able to communicate. Since we do not use DHCP, this is not a problem.
  4. A NAT Router is set up between the two LANs. Any client connection request that comes in from the VirtualBox Host-Only adapter is assigned a new port number and the IP address of the host computer on the real Yale network and is then forwarded to the real server somewhere out on the internet. Traffic between that server and the client on the VM is routed through the host OS between the real Internet and the virtual Host-Only adapter. This NAT function works no matter what IP address the Host-Only adapter has been assigned.

With this technical description that can be understood by someone familiar with TCP/IP and basic internet protocols, now consider the higher level functional result of using Host-Only virtual LAN and ICS:

  • The Virtual Machines appear to be real computers connected to a real but private network. You can interact with them as if they were actual computers and use all the regular network protocols (file sharing, SSH, FTP, HTTP, ...).
  • The VMs have assigned IP addresses and hostnames. The Sandbox VM comes with an /etc/hosts file that maps the names to IP addresses ("vm-ssoboxapp-01.web.yale.internal" is mapped to 192.168.137.1 for example). You should change your host computer "hosts" file (C:\Windows\system32\drivers\etc\hosts for example) to have the same mapping for the same names. CAS cluster configuration then works, and you can use http://vm-ssoboxapp-01.web.yale.internal/cas from a browser on the host computer to test access to the VM CAS, provided that JBoss is started with the parameter that binds it to "0.0.0.0" so it accepts requests from other machines (by default JBoss binds to the loopback address 127.0.0.1 and will only respond to local browser requests on the same VM).
  • The VMs now have names and network configurations as close as possible to the DEV, TEST, and PROD clusters in the machine room.
  • However, the two VMs are invisible to anyone who is not on the host computer. No other machine can logon to them, or access their Web pages, or hack them.
  • Because the host computer is serving as a NAT router, the VMs can access the Yale network and Internet as clients. They can access the SVN server to commit changes or update source. They can download software updates from the Red Hat site.
  • Because the virtual Host-Only network is invisible outside the host computer, two developers can be using the same Sandbox configuration on two laptops on the same Yale subnet and they do not interfere with each other. The 192.168.137.* addresses have no meaning on the Yale network.
  • If you happen to take the laptop home and use this configuration, there is no problem if the LAN address of the real Ethernet adapter is the 192.168.1.* range traditionally used by Linksys routers. The 137 subnet is distinct from the 1 subnet. However, if you use ICS at home instead of a separate router box and your home network is already 192.168.137.* then you better configure the VirtualBox Host-Only adapter to use a different subnet number than 137.
  • CAS requires AD to authenticate netids and passwords. Technically, it requires a configured LDAP server. You could create a dummy LDAP server on your host computer. Windows provides AD LDS, but you can use any LDAP server for this purpose. If you want to use the real AD and you need to do so from outside the Yale network, then you need to use a VPN to get access to any real Yale AD. In this case, you install ICS to share the VPN "LAN adapter" instead of the physical LAN adapter. This is sufficiently complicated that it is not recommended (Cisco Anyconnect is just not that reliable).

If you use a Mac or Linux as your native laptop OS, you are going to have to set up NAT routing yourself, although you might Google for "mac nat router" and start at http://www.cyberciti.biz/faq/howto-configure-macosx-as-nat-router/a "NAT Network" that allows VMs to talk to each other and the outside world, but it does not allow the host computer to talk directly to the VMs.

Each solution has a problem. The simple NAT adapter does not allow the VMs to talk to each other and makes it hard for programs on the host to talk to programs on the VM. The bridged solution allows everyone to talk to everyone, but it exposes your VMs to the outside world and requires registering the VMs as if they were real machines. The private network allows VMs to talk to each other and to the host, but not to the outside world. The NAT Network allows the VMs to talk to each other and to the outside world, but not to programs on the host.

You can use the private network solution and then install a non-Virtualbox NAT service on the host OS. It works, but it is a fairly complicated configuration option. So eventually it became clear that the simplest solution was to configure two LAN adapters on each VM. One is connected to a private virtual network connecting the host computer and the VMs to each other. This allows CAS to replicate tickets between VMs and it allows a browser on the host computer to connect to CAS on a VM. The other virtual LAN adapter on each VM is connected through a NAT service to the Yale network and Internet. It allows the VM to communicate with the Yale SVN server or the Centos software update servers.

On the virtual private network, the host computer has IP address 192.168.137.1 and the Sandbox VMs have addresses starting at 192.168.137.10.

The Sanbox VM image is designed to be Cloned (a VirtualBox operation) to create a second VM for a CAS cluster. There are two hostnames (vm-ssoboxapp-01 and -02) with two IP addresses (192.168.137.10 and 11) on two Ethernet adapters (MAC address 08:00:27:A9:84:AD and AE). The distributed VM uses the first hostname, IP address, and MAC address. After cloning it, and before you start the cloned VM, change its MAC address so the last byte changes from AD to AE. When the cloned VM first comes up, issue the following command once:

...