Virtualbox Case Study: Making host only networking work between two Ubuntu Guest OS (virtual machine) on Windows Vista host

Preface

In the past articles, I have talked about how to make internal networking work between two virtual machines built using Virtualbox. In this article, we will see seeing a configuration of host only networking between two virtual machines built on virtualbox.

The advantages of configuring host only networking are :

1) Internet works (yes!)

2) You get an IP on the LAN for each virtual machine. Yes, this is really possible. So this means that you can have 2 more real LAN IPs coming out of a single windows desktop/laptop in the LAN. Isn't that amazing?

3) Due to 2), your host machine can also ping or access your virtual machine

4) Each virtual machine can access the other virtual machine. E.g. ping/ssh/telnet into it.

For most purposes, this kind of setup should be optimal or sufficient. Hey, if you can access your machines in the LAN and internet works from them, that should be good enough. And, its for free.

Here is a bird's eye overview of the end setup..

click here to enlarge this diagram

The Virtualbox Network Adapter configuration

We start with the Virtualbox Network Adapter configuration. We create a host only network interface on each virtual machine definition.

For Virtual machine1 - Gutsy:



For Virtual machine2 - gutsy2:



Please note here that while this article primarily deals with setting up host only networking, in the previous article, I had setup internal networking too, so these VMs also have a Virtual Host Interface 2 for internal networking within themselves.

Install the Guest Operating system on the virtual machines

Now, do the installation of the guest operating system in the virtual machine and setup the two network interfaces like this.

Note here that I chose static IP 192.168.0.5 because my windows machine (host OS) had the IP 192.168.0.3 and the IP had to be in the 192.168.0.x subnet. My windows host was behind a Netgear router.


We need to make sure we choose non-conflicting IPs for the host only interface otherwise you will get an IP conflict in your LAN domain. For the other machine, the eth0 static IP was 192.168.0.4.

An interesting fact here was that if I chose DHCP for eth0 in the VM, i was getting an IP of 192.168.0.3, the same as that of my windows host!! This is another reason why I had to choose static IP address.

For eth1, i chose a random IP in the subnet 192.168.2.x for no particular reason. The eth1 IP of the other virtual machine was 192.168.2.1

Make sure to restart the network after doing this network setup to bring it into effect.

Do not bother about the SIOCADDRT: No such process error:

gverma@gverma-laptop:~$ sudo /etc/init.d/networking restart
[sudo] password for gverma:
* Reconfiguring network interfaces...
SIOCADDRT: No such process
Failed to bring up eth1.
[ OK ]

For the benefit of the reader, the DNS and host information is also reproduced here, although the only thing of significance should be the DNS and default gateway, both of which were set to be the same as that on windows host:

This is how the network configuration on the other virtual machine looked like:

For those who are interested, here is the output of the route command:

gverma@gverma-laptop:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth0
default         192.168.0.1     0.0.0.0         UG    100    0        0 eth0

A quick side note for Windows Vista

Here is a quick side note for Vista or windows in general. It is preferable to disable the UAC (user access control) setting and also disable the firewall on the host windows machine.



Disable the User Access Control (UAC) feature on vista to make your life easier:

Network bridging: the key to make host only networking work

The KEY to make host only networking work on windows is to bridge the real working network interface (either wireless connection of a hard wired ethernet) with the virtual adapter network interface. You can do this by selecting two network interfaces, right click, choose bridge and voila, there you have it.

A network bridge is nothing but a simplified concept of joining two connections into one. Its like joining two rivers into a bigger river. When water will flow into the bigger river, it will flow into both the rivers. At least, this is how I understand it.

ALSO, we have to enable promiscuous packet routing mode in ALL the member network interfaces that are in the bridge. This is an important setup to make it work.

Initially, I had struggled a lot to make host only networking work by enabling promiscuous for only the Virtualbox Adapter in the bridge, but was not successful. That is when I read a cryptic posting on the Virtualbox forum saying that it has to be done for all the member bridge interfaces; and thats when it worked.

A note of caution

When we add an adapter to the bridge, the connection of the main wireless network is lost for a moment, but it is re-enabled back. This is also covered in the user manual in secion 6.3 (Virtualbox version 1.5.6)

Warning: Setting up Host Interface Networking requires changes to your
host’s network configuration, which will cause the host to lose its network
connection. Do not change network settings on remote or production systems
unless you know what you are doing.

Later on, I assigned Virtualbox Host Interface 2 (on windows) to NAT0 (eth0) of Virtual machine 2 and bridged it to the wireless network connection too:

After the bridging, this is how the ipconfig output looked like (the IP of the windows host is 192.168.0.3):

Now, we were one BIG, HAPPY Family. Make sure the connection status shows as connected.

Testing the connections - Internet works!

At this point, the internet was working from the virtual machines:

Another real quick check is to use the wget utility:

gverma@gverma-laptop:~$ wget yahoo.com
--18:32:56--  http://yahoo.com/
=> `index.html'
Resolving yahoo.com... 216.109.112.135, 66.94.234.13
Connecting to yahoo.com|216.109.112.135|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.yahoo.com/ [following]
--18:32:57--  http://www.yahoo.com/
=> `index.html'
Resolving www.yahoo.com... 69.147.114.210
Connecting to www.yahoo.com|69.147.114.210|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,490 (9.3K) [text/html]

100%[=====================================================>] 9,490         --.--K/s

18:32:57 (258.06 KB/s) - `index.html' saved [9490/9490]

Testing the connections - Host only networking

Now comes the acid test of whether the virtual machines and hosts can see each other.

Windows could see the individual virtual machines:

C:\Users\gaurav> ping 192.168.0.4
Pinging 192.168.0.4 with 32 bytes of data:

Reply from 192.168.0.4: bytes=32 time<1ms TTL=64
Reply from 192.168.0.4: bytes=32 time<1ms TTL=64
Reply from 192.168.0.4: bytes=32 time<1ms TTL=64
Reply from 192.168.0.4: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\gaurav> ping 192.168.0.5
Pinging 192.168.0.5 with 32 bytes of data:

Reply from 192.168.0.5: bytes=32 time<1ms TTL=128
Reply from 192.168.0.5: bytes=32 time<1ms TTL=128
Reply from 192.168.0.5: bytes=32 time<1ms TTL=128
Reply from 192.168.0.5: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.0.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging the windows host IP from inside the VMs worked beautifully:



And, pinging to the other virtual machine from each VM worked beautifully too:



Taking this a step further, since ssh was enabled on both the virtual machines, I was able to login to the individual virtual machines also:

gverma@gverma-laptop:~$ ps -ef | grep ssh
gverma    4684  4643  0 21:27 ?        00:00:00 /usr/bin/ssh-agent x-session-manager
root      5422     1  0 22:20 ?        00:00:00 /usr/sbin/sshd
gverma    5456  4864  0 22:23 pts/0    00:00:00 grep ssh
gverma@gverma-desktop:~$ ssh 192.168.0.5

gverma@192.168.0.5's password:
Linux gverma-desktop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Mon Apr 14 22:20:55 2008 from gverma-laptop.local
gverma@gverma-desktop:~$

gverma@gverma-desktop:~$ ssh 192.168.0.4
The authenticity of host '192.168.0.4 (192.168.0.4)' can't be established.
RSA key fingerprint is a8:29:91:97:7d:99:37:6e:31:f1:06:ec:04:39:78:d7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.4' (RSA) to the list of known hosts.

gverma@192.168.0.4's password:

Linux gverma-laptop 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Private networks

To make things better, the private networks were working too (thanks to the good karma accumulated in the previous article - Case study: Configuring Internal networking work for talking two linux guest OS (Ubuntu) on windows vista host ) :

gverma@gverma-laptop:~$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.200 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.16 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.000 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.073 ms
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.000/0.358/1.160/0.468 ms

gverma@gverma-laptop:~$ ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=4.49 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=0.368 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=1.65 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=3.15 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=64 time=1.51 ms

A moment of Triumph

So here we are. Let us take a moment to sit back, relax and let reality sink it. It is really working! I am reminded of the umpteen times I had gone to forums.virtualbox.org to find the answer to this riddle and here it is, solved.

I hope this guide is of use to someone else who is trying to make a similar configuration work or just trying to understand -- what is it that we can achieve from host only networking??

Nothing could be sweeter, nothing.

Case study: Making Internal networking for talking between two linux guest OS (Ubuntu) on windows vista host

Preface

For the past few days, I had been struggling with making internal networking work on two (or more) linux guest OSes on Windows host using virtualbox.

The advantage of this setup is we can setup an internal networking lab between two or more nods using regular windows, which can be used for a variety of purposes. My primary purpose behind this setup was to simulate an environment for implementing Oracle 10gR2 RAC cluster.

As we know, setting up 10g RAC on a node needs a public network and a private network. The public network is achieved right off the bat with the NAT network configuration in Virtualbox, but the internal network setup is one that is pretty tricky.

I will give credit to both http://www.virtualbox.org/wiki/Testing_Networks and http://blogs.sun.com/manoj/entry/netowkring_with_virtualbox for the ideas tested, but more so to http://www.virtualbox.org/wiki/Testing_Networks

That being said, I would daresay that the content authoring in Virtualbox user manual about setting up internal networking on windows host deserves a little more attention. I was able to find several posts on the internet, including a particular Virtualbox wiki page, that dealt with making host only networking or internal networking work on Ubuntu host, but was not able to find the same for windows host.

Lets get to the setup now..

This is how the GUI setup looks like internal network (Adapter 1 - 2nd adapter) for the two virtual machines:

The caveat...

The first thing which we need to understand that is the Virtualbox GUI for setting up internal network is BROKEN!

You need to set it up using the command line interface (VboxManage command) Also, be aware that the internal network settings are reset by the GUI if any of the VM settings are changed, so you better do this AFTER you are done with all the other VM changes.

As per the User manual, the default internal network name is "intnet", but you can choose any other name. I chose the intnet for no particular reason.

This is what we need to do with the VboxManage command. (here, we assume that there are two guest OSes - "Gutsy" and "gutsy2"). Mind you, the virtual machine name is case-sensitive in the VboxManage command.

c:\Program Files\Innotek> VboxManage modifyvm Gutsy -nic2 intnet

c:\Program Files\Innotek> VboxManage modifyvm Gutsy -intnet2 intnet

c:\Program Files\Innotek> VboxManage modifyvm gutsy2 -nic2 intnet

c:\Program Files\Innotek> VboxManage modifyvm gutsy2 -intnet2 intnet

Default Gateway and DNS of eth1 interfaces - (used for private network as per our semantics)

If you already have the eth0 in the guest OS (linux) as NAT, it will automatically acquire a DHCP assigned IP in the subnet 10.0.2.x, and will have a default gateway of 10.0.2.2. The names server will be 10.0.2.3. With this setup, internet will work on the linux guest OS, (provided it is works on the windows host too).



We will need to make the default gateway of the private network (eth1) in guest OS (linux) as 10.0.2.2 too -- whichever is causing the internet to work.

Private IPs should be the same subnet...

Another thing to notice here is that all the guest OSes that are intended to be connected through internal network should have the private interface IP (eth1) in the SAME subnet. You can choose any private subnet like 192.168.x.x or 10.10.x.x:

Here are three valid combinations of eth1 IPs:

a) Gutsy could have 192.168.2.1, and gutsy2 could have 192.168.2.2

b) Gutsy could have 192.168.3.2, and gutsy2 could have 192.168.3.4

c) Gutsy could have 10.10.1.1, and gutsy2 could have 10.10.1.2

( I hope you get the idea).

For the sake of illustration, I chose this combination of private IPs:

• 192.168.2.1 (for linux guest OS 1 - Gutsy)


• 192.168.2.2 (for linux guest OS 1 - gutsy2)

Restart networking

After doing this, you need to restart the networking on the linux host. On Ubuntu, it is done with the sudo /etc/init.d/networking restart command:

gverma@gverma-desktop:~$ sudo /etc/init.d/networking restart
[sudo] password for gverma: ********
* Reconfiguring network interfaces...
SIOCADDRT: No such process
Failed to bring up eth1.
[ OK ]

Overview of the networking configuration

Here is how the ifconfig for Gutsy - linux guest OS 1 looks like (as you can see the eth0 IP has been acquired in 10.0.2.x subnet by the DHCP server):

And this is how it looks of Gutsy2 (as you can see, the eth0 IP has been acquired in 10.0.2.x subnet by the DHCP server):

By mistake, I have put the same image for the ifconfig output (that of Gutsy) for Gutsy2  as well. The hardware MAC address for eth1/0 should be different and so should be the the IP address for eth1 -- it should be 192.168.2.1. The eth0 IP for Gutsy2 would still be 10.0.2.x as it was of NAT type. -- Thanks, Gaurav

A variation...

Let us consider a variation here.

If the Virtual machines have only 1 virtualbox network adapter defined of type internal network, then the internal static IP within the Virtual machine would have needed to use a default gateway == host's IP default gateway.

For example, if the windows host had an IP of 192.168.0.4 (say), by virtue of being behind a router, then the default gateway of eth0 interface in in the virtual machine should be 192.168.0.1. (Again, this is assuming ONLY if you do not have a NAT type virtual interface defined for the VM.)



In my case, since I had two virtual network interfaces defined (one NAT and one internal networking type) for the VMs, I had to make the default gateway of the eth1 (private interface) of guest OS the same as that of eth0 -- which was 10.0.2.2.

The default gateway can be verified by the output of route command.

Interesting Trivia

In addition, the media state of the Virtual TAP Adapters in windows host were showing up as media disconnected, but still the internet was working for the Virtual machines AND the pings to each other were working. So, don't be fooled by the status of Virtulbox Adapters in the windows host.

gverma@gverma-desktop:~$ ping 192.168.2.1
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=0.030 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=0.109 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=0.031 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=64 time=0.036 ms
64 bytes from 192.168.2.2: icmp_seq=6 ttl=64 time=0.033 ms
64 bytes from 192.168.2.2: icmp_seq=7 ttl=64 time=0.110 ms

--- 192.168.2.2 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5998ms
rtt min/avg/max/mdev = 0.030/0.054/0.110/0.035 ms

gverma@gverma-desktop:~$ ping 192.168.2.2
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.398 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.304 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.380 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=7.20 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=0.407 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=0.272 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=3.42 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.411 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.398 ms

--- 192.168.2.1 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8004ms
rtt min/avg/max/mdev = 0.272/1.465/7.200/2.241 ms

Viola! The same result can be seen on gutsy2 too.

Well done!

Congratulations on setting up a private internal network between multiple virtual machines using Virtualbox. I hope this tutorial is of use to someone exploring the virtualbox tool. I personally feel it is a lot leaner and powerful, as compared to the vmware's size. It is also more robust performance wise.

If you feel this was helpful, send me a note at gaurav_verma two two [at] yahoo dot com or just leave me a comment.