In my article, Create a Private Oracle Test Lab I expressed my opinion that every serious student of Oracle databases should have their own private computer lab. In Configuring the Oracle Virtual Box Network, I detailed the specifics of configuring the network adapters in virtual machines running under VirtualBox. In the time since I wrote those articles I have observed many people on the Oracle Technology Network forums attempt to create a test setup, but with no real thought going into creating a coherent framework in which to build a useful and flexible laboratory.
Now I would like to “connect the dots” and detail the framework within which I have created scores of virtual machines on either my personal laptop or my company-issued desktop. Within this framework, I have had a full suite of virtual machines running Oracle Linux, Suse, Ubuntu, Solaris and Windows, with as many as three different machines running simultaneously. All of these virtual machines communicate with each other using standard network protocols, exactly as if they were physical servers in my company’s data center.
In this article, I will detail exactly what goes into creating that framework. In reality, the actual framework is little more than a few standard directories and the installation and configuration of the virtualization software, which will be detailed at the end of the article. Before getting there, I will explain the thought process that went into the creation of my virtual test labs and the standards I set for myself. It is my hope that the reader will be able to use that to develop a framework that works for him.
I will not be discussing the actual creation of a VM or the installation of any software on that VM. Once you have a consistent framework, there are is any number of resources on the web to help with the creation of specific VMs. And who knows? I may add my own contributions to that body of work, in later articles.
Before getting into the details, I would like to recap and expand my original rational for building a private virtual computer lab, and add some additional points based on my observations since publishing the original article.
For the working professional, even systems designated as ‘test’ or ‘development’ have certain up-time and stability requirements. Loss of a “test” system can have a severe impact on the developers. For the student, access to a live system may be non-existent. For these reasons, it is imperative that every professional or student leverage the power of their personal computers and the availability of virtualization products to create a private (or “sandbox”) computer laboratory consisting of one or more virtual computers. Such an environment allows testing of almost any aspect of the system without concern for damaging a system that others rely on. There is simply no excuse for anyone to say, “I don’t have a system to test that on.”
Another advantage of the private virtual laboratory is that it allows the operation of a test system on an operating system other than that of the host system. The vast majority of personal computers are a “Home” edition of Windows, with a lesser number of Macs. A virtual machine can run any operating system supported by the virtualization software. The database software is concerned only with the operating system on which it is installed, not the host operating system behind the virtual machine. So even if the only computer you actually have administrative access to is your personal Windows 7 Home Edition you can still have a Unix or Windows Server test machine.
A third advantage of the virtual laboratory is that it allows the test system run with its own network identity. This allows it to be dealt with exactly as if it were a live system in the corporate data center instead of something grafted into the desktop system. I often help people on OTN who are installing Oracle database software directly on their desktop OS. Quite often, their problems stem from being blissfully unaware of the networking implications of true client-server architecture. They are then flummoxed when faced with a real system and the network considerations that entails.
Before getting into the configuration of your PC, let’s consider a few items.
Before anything else, we need to clarify some terms
Host. Within the context of this article, the term “host” refers to the physical computer and its own operating system.
Server. Within the IT industry, the term “server” is used in two ways. First and foremost, it refers to a process that provides services to one or more other processes running on the same or other computers. Second, it may to refer to a computer whose primary purpose is to run server processes.
Client. In general, a “client” is any process that requests services from a server process. However, in the context of creating virtual machines that run as a task under a host operating system, it is common to refer to those virtual machines as “client machines”. This can be rather confusing since we also commonly refer to them as “servers”. However, in the context of the relationship of the VM to the host it is technically correct. The virtual machine itself is requesting hardware services from the host OS. As far as the host is concerned, the VM itself is a client. On the other hand, the purpose of these virtual machines is to act as a server – usually a database server. Within the framework of our lab, the client process requesting services from the virtual machine server will often be running on the host OS.
The better you understand “client” and “server” in terms of processes instead of machines, the better you will understand this article. In fact, the better you understand “client” and “server” in terms of processes instead of machines, the better you will understand many other things about computer technology.
Unix. While I make frequent reference to the Unix operating system, it should be understood that what is said can apply equally to any Unix-based system, such FreeBSD, AIX, Solaris, Linux, etc.
You probably already own your own personal computer. If it is relatively new, it will most likely meet your needs for at least one VM. However, if you are considering buying a new one, or are a bit unsure of the suitability of your current PC, here are some things to consider.
You will want a machine with a 64-bit processor. As of this writing, it appears that all available consumer-class desktop/laptop computers are built with 64-bit Intel or AMD processors. 32-bit processors are a thing of the past, so this may no longer be a point of real concern.
RAM (Random Access Memory) will be the limiting factor on how many VMs you can have running simultaneously. If you are planning to run only one VM at a time, 4 GB may be sufficient. However, if you will need to run multiple VMs at one time (as in an Oracle RAC environment) you really should get 8 GB, which as of this writing seems to be the maximum available for most laptops. True desktop machines can easily accommodate up to 16 GB. While most desktop class machines are pre-configured with 2 GB to 4 GB, an upgrade to as much as 16 GB can be well worth the incremental additional expense.
When you create the virtual machine, the memory that you specify for it will be allocated out of the real memory of the host system. If you specify the VM has 2 GB of memory, when you start that VM it will require 2 GB of real memory from the host. One must keep in mind how much memory the host OS requires for its own operations. For example, on a minimally configured 4 GB host running Windows, the host Windows OS will require 2 GB for itself, leaving only 2 GB for any and all other processes, including any VMs.
Disk space will be the limiting factor for how many VMs you create, irrespective of how many are running simultaneously. As of this writing, most entry-level desktop class machines come standard with 500 GB hard drives, and one terabyte drives are becoming increasingly common. Plan on 30 GB to 50 GB per VM. The purpose of these VMs is not to have fully populated application databases, but to have a system on which to test features and techniques.
Host Operating System
The host OS can be any OS capable of running the selected virtualization product. Given the proper hardware support in the CPU, it is possible to run a 64-bit virtual machine on a 32-bit host. However, given that virtually all consumer-class computers are built on 64-bit hardware there is simply no reason to be running a 32-bit host OS.
NOTE: Since Windows is by far the most prevalent desktop OS, all procedures in this and related documents will assume the host OS is Windows. It should be very easy to adopt the principles to other desktop systems such as Apple or Linux.
When I started building my first VMs I used VMware’s VMplayer. It was a very capable product and was free. While it was fully capable of meeting my needs, it did lack some nice management features, so I soon shelled out $180 to purchase the full-featured VMworkstation. After a few years, I became aware of a product called VirtualBox. That product had all of the features of VMworkstation and was available at no cost. It was increasingly becoming the product of choice in the Oracle community so I made the switch. As I write this, it appears that VMware no longer has a free offering, and VMware Worksation Pro now costs $250.
Oracle VM VirtualBox was created by Innotek GmbH, purchased in 2008 by Sun Microsystems, and acquired by Oracle in 2010 as part of their purchase of Sun. VirtualBox (aka “VBox”) provides the same full feature set as VMworkstation, but is available as a free download from Oracle. There is no official support, but there are two user forums, one at the Oracle Technology Network forums and forums.virtualbox.org. It has come to be the de facto standard among the Oracle community for creating personal virtual environments. For that reason, it is the product that will be used in this and related documents.
Before beginning to create the infrastructure, it is best to think through some standards. While the specific standards may be considered somewhat arbitrary, experience has shown that systems are much easier to manage when standards are well thought out and detailed. A good standard will provide names that are meaningful and a structure that is predictable and allows for future growth. It will be extensible and flexible, yet not overly complex – not too restrictive, yet not so broad as to be meaningless.
In the end, the existence and use of a well thought out standard is more important than the details of a specific standard. The naming standards really are at the heart of creating the virtual laboratory framework.
For my laboratory framework, I start with standards for naming the virtual machines and for a directory structure that will be created on the host system.
The naming standard for VMs presented here is only an example. The reader is encouraged to develop their own, especially in light of any standard used in their corporate environment. If building a virtual server to mimic a live server in a corporate environment, one should adopt a naming convention that will both distinguish the virtual server from its live counterpart and at the same time make it clear which live system the virtual system is replicating. For instance, if the organization has a naming convention in the format
IT – fixed literal
xxxxx – variable identifying information
One might replace the corporate fixed literal of “IT” with literal of “VB” for “Virtual Box”. For example, if the corporate machine were named ITORASRV, then the name of the VM running under VirtualBox would be VBORASERV.
In the infrastructure detailed in this series of documents, virtual machines are named as follows.
Sever name = aabbbcccnn where
aa – Virtualization Product
vb – the VM runs under VirtualBox
vm – the VM runs under VMware
bbb – Operating system
olx – Oracle Linux
ubn – Ubuntu Linux
sus – Suse Linux
sol – Solaris
win – Windows
ccc – user defined
Within the overall naming standard set forth here, this lends itself to whatever makes sense in the user’s own experience. One might use this to differentiate between database and application servers, or between server and desktop systems, or to designate the application associated with it. Just determine for yourself how it will be used, then stick with it.
nn – Sequence to create a unique name within the previous indicators. Number from 01 to 99. Always use two digits
Configuring the host system
Finally! Now that we’ve gotten all the preliminaries out of the way, let’s start configuring the host system.
Configuring the host system consists of the following steps
- Create a common directory structure on the host
- Install and configure VirtualBox
- Install ssh client
- Install x-windows server
Create a Common Directory Structure
While the virtualization products themselves can be installed into whatever default directory they normally use, it is helpful to keep all files and directories created to support the VMs under a common directory, with sub-directories for the various support files
Create the following directories.
|C:\VMLab||Parent directory for the entire VM infrastructure.|
|C:\VMLab\VBMachines||Parent directory of VMs created under VirtualBox. (If using VMware products, the directory would be C:\VMLab\VMMachines.
NOTE: The virtualization products have a default location in relation to their software installation location. In keeping with our objectives, we will modify this default to use the directories we create for this purpose.
|C:\VMLab\VBMachines\backups||Directory where you will keep backups of the virtual machines. More on that later.|
|C:\VMLab\VBShared||Virtual disks that are shared across VMs under VirtualBox. Used when creating Oracle RAC setups.|
|C:\VMLab\hostshare||Shared across all VMs; holds files that are shared across VMs or persisted across changes to a VM. Will be mounted to each VM through the VirtualBox “shared folders” facility.|
|C:\VMLab\hostshare\setup||Shared across all VMs; holds the scripts that I use specifically for the initial setup of the VM once the OS is installed.|
|C:\VMLab\media||Staging area for software installed on the VMs. You may find it useful to create product-specific sub-directories below this.|
|C:\VMLab\media\OracleDatabase_112010_linux_x64||Example of a product-specific subdirectory under the media directory. Under this directory, I would place the downloaded distribution files for Oracle Database, version 126.96.36.199.0, for 64-bit Linux. I have a further naming standard for these directories of
Install and Configure VirtualBox
VirtualBox is an open source product distributed by Oracle Corp. It is freely available in the “Downloads” section at www.oracle.com. Download and installation instructions are available at that point.
Once installed, start VirtualBox and set the default directory in accordance with our standards, as detailed in the following procedure.
1. Open the “File” menu
After starting the VirtualBox Manger, open the “File” menu
2. Select “Preferences”
In the File sub-menu, select “Preferences
3. Set the default machine folder
In the “VirtualBox – Settings” window, select the “General” tab in the options list, then set the “Default Machine Folder” to the host system folder created for this purpose.
NOTE: The drop-down for this field will lead to a dialog that will allow you to navigate and drill down to the selected folder, eliminating the need to type in the specification.
4. Save the settings
Click “OK” to save the settings, then exit VirtualBox
5. Note the address of the VirtualBox network adapter
Installing VirtualBox created a network adapter on the host system. You will need to know the IP address of this adapter when you create your virtual machines.
On the host desktop, open a command prompt and enter the “ipconfig” command
C:\>ipconfig Windows IP Configuration Wireless LAN adapter Wireless Network Connection 2: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . :
Make a note of the IP address assigned to the VirtualBox host network adapter. In this example, the address is 192.168.56.1.
Ethernet adapter VirtualBox Host-Only Network: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::70fb:5067:d2c5:6586%29 IPv4 Address. . . . . . . . . . . : 192.168.56.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . :
Install ssh client
The standard interface to Unix systems is a simple command-line ssh client. There are several products available, but my favorite is the simple, lightweight PuTTY. The official download page is at chiark.greenend.org.uk.
The architectures of Unix and Windows are vastly different. One place this becomes apparent is in their implementation of a graphical interface. With Unix you can install any number of different products to provide a graphical desktop. The most common are Gnome and KDE. I’ve played around with them a bit, but I still prefer the speed and simplicity of the simple command line shell. If you insist on using a graphical desktop with a Unix system, Google will be your friend.
Any time a *nix system executes a program with a graphical interface (such one of the aforementioned graphical desktops, or the Oracle Universal Installer) the program redirects it’s graphical interface to a specified network address and port, where it expects to find an x-server process capable of handling it. Therefore, we must install an x-server on our host desktop. I recommend a product known as ‘xming’. It is free, has a small footprint and simple installation. X-ming can be downloaded from the Sourceforge.net site.
If you have followed this article carefully, you should now have the following:
- A clear directory structure for placing your virtual machines and installation software to be used on those machines
- An installation of Oracle Virtual Box, configured to place any virtual machines within the custom directory structure.
- The “client” programs necessary to interface with any Unix virtual machines you create.
- A workable naming standard to bring some consistency and sanity to naming your virtual machines.