In “Create Your Own Test System” I made the case that there is no excuse for someone who considers themselves to be a professional DBA to NOT have their own personal database for testing and learning. I pointed out that by using VMware’s VMplayer, Oracle Linux, and Oracle database under the terms of the developer license agreement, one could create their own private test system legally and at no cost.
I should note that VMware actually has two products that can be used for this purpose. VMplayer is distributed freely, and VMworkstation which costs US$249 as of this writing. (Note: I was rather shocked just now when I checked the current price. When I wrote my original post on the subject, the cost was only US$185.) The difference is that VMplayer is a very bare-bones product, while VMworkstation comes with a very nice management console, full support for snaphsot management, and flexible network management. The actual virtualization engine is the same across the entire range of VMware products, including their enterprise data center products.
In recent months the use of VirtualBox as the virtualization software has come into more prominence in the Oracle community. In comparison to VMware’s products, VirtualBox is much more like Vmworkstation in that it includes a management console for management of the overall virtual environment, vm snapshot management, etc. It should also be noted that VirtualBox appears to be intended as a virtualization product for the desktop. I do not see it as an enterprise solution for the datacenter.
When I first started working with VirtuaBox the first problem I ran into was dealing with the network configuration and it is at this point that I see a recent uptick in questions discussed on OTN.
I am not a networking expert and it is not my intent in this posting to give a detailed comparison between the way it is handled in VMware vs. VirtualBox. Rather, I simply want to lay out what I discovered I needed to do to get my virtual servers running under VirtualBox to network according to my requirements.
Terminology used in this post
Before continuing, let me define some of the acronyms and abbreviations I will be using.
VM – when I use the term “vm” I am simply using it as an abbreviation for the term “virtual machine”. I do not use it to refer to any product of the VMware corporation, or the VMware corporation itself. When referring to these entities, I will always use the actual product or company name – VMplayer, Vmworkstation, VMware. Also, I use the term ‘vms’ as the plural of ‘vm’. This is not to be confused with Digital Equipement Corporation’s ‘vms’ operating system. A lot of people would avoid this amgiguity by using “vm’s” as the plural of “vm”, but I was too well schooled in English grammer to use a possessive as a plural.
VBox – I use the term VBox to refer to VirtualBox. It is quite common on Vbox message boards to refer to it as simply VB. That is fine within the context of those forums, but in a broader sense I fear it may be confused with Microsoft’s Visual Basic product which is also widely referred to as “VB”.
My requirements
When I create a vm on my desktop, have four fundamental, non-negotiable requirements:
- I must be able to work with, access, and manage the vm exactly as I would any real server in my data center. That means it has to be accessible from my desktop OS using exactly the same tools I use with my live database servers: putty for my ssh client, sqlplus, and any GUI database access tool like Toad, SQL-Navigator, SQL Developer, etc.
- The vm must be able to access the internet to download OS packages from Oracle’s public yum server.
- The vm must have a fixed IP address. You really can’t run a server (and that’s what this vm is) with a DHCP address.
- The vm must be invisible to my network administrators. It cannot occupy an IP address on my company’s or ISP’s network. The “network nazis” must never know it’s there.
Network Modes
Let me digress for a moment to explain the different network modes in use with a virtualization product.
NAT (Network Address Translation)
With NAT, the guest (virtual) os has it’s own IP address, but communicates to the outside world thorough the host OS’s ip address. Requests are translated from the guest IP address to the host’s address before the host passes the request on. Messages received back are translated back to the guest OS’s ip address for the final leg of the trip. Honestly, I studied the details once, but have since forgotten them.
Bridged
Using a bridged adapter, the vm has an ip address that actually occupies a space on the host’s network. As such it communicates with the network under its own credentials and is visible (and controllable) by the network administrators.
Host Only
With a host only adapter, the vm can communicate only with the host OS or other vm’s running on the same hostonly adapter.
Setup the Virtual Machine
With VMware, meeting my four requirements was so simple I really just took it for granted and never gave it a thought. When you install VMware on your desktop two network adapters are created. VMnet1 is configured for ‘hostonly’ connections. VMnet8 is configured for NAT. I knew that I wanted to hide behind NAT, so gave my first vm an IP address in the subnet controlled by VMNet8 and everything “just worked”. I never gave it another though.
When I started to use VB I immediately ran into problems. After a lot of trial and error and, um, “animated” discussions on the VB user’s forum, I found that the VB implemented it’s networking entirely differently than VMware, and that impacted how the different configurations like NAT behaved.
So, without further ado, let’s get into how I set up my virtual machines running under Vbox. I am running VirtualBox on a Windows 7 Home Premium laptop, 64-bit.
Install VirtualBox
The installation of Vbox itself will create a network adapter on the host os. This can be seen by opening a command prompt and executing the ‘ipconfig’ command:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\ed>ipconfig
Windows IP Configuration
Wireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . : ****.**.comcast.net.
Link-local IPv6 Address . . . . . : ****::****:****:5fc8:e17c%12
IPv4 Address. . . . . . . . . . . : 192.168.1.***
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
Ethernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Ethernet adapter VirtualBox Host-Only Network:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::300a:4cfd:f300:133d%23
IPv4 Address. . . . . . . . . . . : 192.168.56.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter VMware Network Adapter VMnet1:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::3538:74ea:6db:e40d%26
IPv4 Address. . . . . . . . . . . : 192.168.236.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Ethernet adapter VMware Network Adapter VMnet8:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::d144:2412:3a94:53da%28
IPv4 Address. . . . . . . . . . . : 192.168.111.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
Tunnel adapter isatap.{D3A1FFA7-BF1E-4938-B01A-B8DFE49B3F7F}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
|
Reading this from the top down, we see the following
Line 8 , “ Connection-specific DNS Suffix” lists the information assisgned to the host OS (Windows 7) by the network to which it is currently connected. This is a DHCP assigned address and at the time of this snapshot, my primary connection was to my ISP. (key details are masked with asterisks.
Line 21. “Ethernet adapter VirtualBox Host-Only Network:”. This is the adapter created by the installation of Vbox. Please note the Ipv4 address of 192.168.56.1. at line 25. This will be important later on.
Line 29. “Ethernet adapter VMware Network Adapter Vmnet1:” This is the hostonly adapter created by the installation of Vmworkstation. I still have it installed on my laptop and have vm’s running under it was well as Vbox.
Line 37. “Ethernet adapter VMware Network Adapter Vmnet8”. This is the NAT adapter created by the installation of Vmworkstation.
I will leave the details of exactly how these adapters function to people who are more qualified than I. As explained to me, I simply think of them as being the routers to which my vms are connected. The adapter associated with NAT also acts as a DHCP server, assigning ip addresses to any NIC that is so configured.
Creating the virtual machine
At this point, we have simply installed the Vbox product. Doing so has also create the network environment in which our vms will operate. They will all exist on the same subnet as our Ethernet adapter VirtualBox Host-Only Network – that is 192.168.56.
Now comes the ‘tricky’ part. As mentioned above, with VMware I simply configured my vm with a fixed ip in the same subnet as my NAT adapter – the Vmnet8 adapter, at 192.168.111.1. What I found with Vbox was that the NAT configuration requires a DHCP address. The solution to my four fundamental requirements was to create my vm with two virtual Network Interface Cards (NIC). The first would be configured for DHCP for NAT connections, the second with a fixed IP for hostonly connections. Here’s how I did it.
In this example, I have just created a new virtual machine, named ‘vblnxsrv99′. I have not yet installed and operating system. We can think of ‘vblnxsrv99′ as a physical server that we have just unpacked and set on the workbench in the data center.
Now let’s open the network configuration for this machine. Click on the “Network” link in the configuration area:
By default, Adapter 1 will already be enabled and configured for NAT. We can leave that one alone.
Now we need to add a second Network Interface Card (NIC) to this virtual machine.
Click on the “Adapter 2” tab to bring up the configuration for this second NIC:
And we get this:
Check the “Enable Network Adapter” box, and select “Host-only adapter” from the drop-down list. The “Name” will automatically be filled.
Click “OK” and your machine is ready to have an operating system installed.
Configuring the Guest Operating System
We now have a virtual machine prepared with the NICs we will need to properly configure the OS we are going to install. We can now treat this virtual server just as if it were a physical server in our data center, mounted in its rack and connected to the router.
I will show the OS configuration for Oracle Linux 5.7, bypassing the details of the full installation and focusing only on the network configuration done during the installation process. Please understand that this is just a convenience during the OS installation. Just as on a physical machine you can add, remove, and reconfigure NIC’s and other networking configurations after the OS is installed and initially configured, these same operations could also be done after the fact on this vm.
When installing Oracle Linux, one has the choice of a ‘graphical’ or a ‘text’ installation. For reasons I won’t get into here, I choose the ‘text’ installation, so that is what you will see in the screen shots that follow.
During the installation of Oracle Linux you will arrive at the “Network Configuration” dialog. At this point select adapter eth0 and “Edit”
Select “Activate on boot” and “Enable IPv4 Support”, then “OK”
At the “IPv4 Configuration for eth0″ accept the default for DHCP configuration, and click “OK”
Back at Network Configuration, select adapter eth1 and “Edit”
Again, select “Activate on Boot” and “Enable IPv4 Support”, and click “OK”
At the configuration of eth1, select “Manual Address Configuration” and assign a fixed IP address.
IMPORTANT: please note that the IP address assigned must be in the same subnet as the VirtualBox Host-Only ethernet adapter that we noted on the host os. In this example that adapter is at 192.168.56.1. For my own naming conventions, my virtual Linux servers will be in the range 192.168.56.101-199, and virtual Windows servers will be in the range 192.168.56.201-299. In both cases, the last two digits of the ip match the two-digits in the server name itself. Thus, the server created for this demo, which has a name of vblnxsrv99 will have an ip address of 192.168.56.199.
With both NICs configured to the OS, we click “OK”.
That brings up the “Hostname Configuration” screen. Here we assign the actual server name and a domain. It is important that we select to assign the address manually (NOT using DHCP).
At this point we select “OK” and continue with the rest of the installation.
Once the installation of the OS is complete, we can check the network configuration of the vm’s OS. At this point I can already start using my standard desktop tools to connect to the vm. I use putty as my ssh client to establish a connection, using the fixed IP we assigned the server. In this case that is 192.168.56.199
Once connected, let’s check the configuration with the ‘ifconfig’ command:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
[root@vblnxsrv99 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:5C:8F:98
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1325 (1.2 KiB) TX bytes:3180 (3.1 KiB)
eth1 Link encap:Ethernet HWaddr 08:00:27:EC:0C:47
inet addr:192.168.56.199 Bcast:192.168.56.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:882 errors:0 dropped:0 overruns:0 frame:0
TX packets:244 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:100764 (98.4 KiB) TX bytes:33696 (32.9 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)
[root@vblnxsrv99 ~]#
|
Remember that we configured eth0 to the NAT adapter and using DHCP. The ip address you see at line 3 is the DHCP assigned address of 10.0.2.15. While it is true that in this limited environment that will probably always be the address assigned, as a matter of practice you can never count on what address will be assigned by DHCP, so this is not the address we use to connect to the server. We have it only to support the NAT adapter so that we can reach the internet to download packages.
The NIC we are interested in is eth1, which we see at line 10, with the ip we assigned to it (192.168.56.199) shown at line 11.
We have one bit housekeeping left. For reasons I don’t understand, when Oracle Linux installation (5.x versions) creates the local hosts file /etc/hosts, it assigns the host name to the local loopback address. We can see this here:
1
2
3
4
5
6
|
[root@vblnxsrv99 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 vblnxsrv99.vbdomain vblnxsrv99 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
[root@vblnxsrv99 ~]#
|
We want to associate the server name with the fixed ip address we assigned, so modify the hosts file by adding a line for the fixed ip address, and reassigning the host name to that address:
1
2
3
4
5
6
|
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
192.168.56.199 vblnxsrv99.vbdomain vblnxsrv99
::1 localhost6.localdomain6 localhost6
[root@vblnxsrv99 ~]#
|
Conclusion
And there you have it. A Linux machine running under VirtualBox with it’s networking configured to our specification. It can reach the internet for downloading of packages, which will be needed when you start to install the Oracle database. It is completely hidden from our corporate and public networks. And we can reach it from our desktop operating system using the very same tools as any server in our data center. If you get to this point, there is no reason you should not be able to treat this server just like any other server in terms of installing and configuring Oracle databases – or anything else for that matter.
