Creating a New Virtual Machine from an Existing Virtual Disk

In previous posts I described how I set up an OEL6 machine under VirtualBox that can run an 11gR2 database and FMW 11.1.1.5.  That is great if you want the DB and FMW running in the same virtual image and it has served me well for some proof of concepts and also for some testing of different JVMs.  However I also wanted to run some testing of FMW with the database running on a separate physical machine.  So in this post I will show how to take a VirtualBox image and create a new image based on the disks from that original image.

What are my Options?

There is more than one way to skin a cat, or in this case to create two separate VMs that can run on different hardware.  Some of the options include:

1. Create new virtual disk images for each new VM.
2. Clone the existing disk images and point the new VM at the cloned images.
3. Point the new VM at the existing snapshots.

#1 is too much like hard work, install OEL twice, install a database again, install FMW again, run RCU again!  Life is too short!

#2 is probably the safest way of doing things.  VirtualBox allows you to clone a disk image for use in a separate machine.  However this of course duplicates the disk and means that it is now occupying 3 times the space, once for the original disk and twice more for the two clones I would need.

#3 is the most space efficient way of doing things.  It does mean however that I can only run the new “cloned” images if I have access to the original image because that is where the base snapshots reside.  However this is not a problem for me as long as I remember to keep all threee images together.  So this is the approach we will follow.

Snapshot, What Snapshot?

As we are going to create new virtual machines based on existing snapshots we need to figure out which snapshot to use.  We do this by opening the “Media Manager” from within VirtualBox and moving the mouse over the snapshot images until we find the snapshots we want – the snapshot name is identified in the “Attached to:” comment.  In my case I wanted the FMW installed snapshot because that had a database configured for FMW alongside the FMW software.  I made a note of the filename of that snapshot (actually I just noted the first 5 characters as that was all that was needed to uniquely identify the snapshot file).

When we create the new machines we will point them at the snapshot filename we have just checked.

Network or NotWork?

Because we want the two new machines to communicate with each other when hosted in different physical machines we can’t use the default NAT networking mode without a lot of hassle.  But at the same time we need them to have fixed IP addresses relative to each other so that they can see each other whilst also being able to see the outside world.

To achieve all these requirements I created two network adapters for each machine.  Adapter 1 was a standard NAT mapping.  This will allow each machine to get a dynamic IP address (10.0.2.15 by default) that can be used to access the external world through the VBox provided NAT gateway.  This is the same as the existing configuration.

The second adapter I created as a bridged adapter.  This gives the virtual machine direct access to the host network card and by using fixed IP addresses each machine can see the other.  It is important to choose fixed IP addresses that are not routable across your internal network so you don’t get any clashes with other machines on your network.  Of course you could always get proper fixed IP addresses from your network people, but I have serveral people using my images and as long as I don’t have two instances of the same VM on the same network segment this is easier and avoids reconfiguring the network every time someone wants a copy of my VM.  If it is available I would suggest using the 10.0.3.* network as 10.0.2.* is the default NAT network.  You can check availability by pinging 10.0.3.1 and 10.0.3.2 from your host machine.  If it times out then you are probably safe to use that.

Creating the New VMs

Now that I had collected the data that I needed I went ahead and created the new VMs.

When asked for a “Boot Hard Disk” I used the “Choose a virtual hard disk file…” link to find the snapshot I had previously selected and set that to be the existing hard disk.  I chose the previously existing SOA 11.1.1.5 install for both the new DB and FMW machines because that snapshot had the database with the RCU completed that I wanted for my DB machine and it had the SOA software installed which I wanted for my FMW machine.

After the initial creation of the virtual machine go into the network setting section and enable a second adapter which will be bridged.  Make a note of the MAC addresses (the last four digits should be sufficient) of the two adapters so that you can later set the bridged adapter to use fixed IP and the NAT adapter to use DHCP.

We are now ready to start the VMs and reconfigure Linux.

Reconfiguring Linux

Because I now have two new machines I need to change their network configuration.  In particular I need to change the hostname, update the hosts file and change the network settings.

Changing the Hostname

I renamed both hosts by running the hostname command as root:

hostname vboxfmw.oracle.com

I also edited the /etc/sysconfig file and set the correct hostname in there.

HOSTNAME=vboxfmw.oracle.com

Changing the Network Settings

I needed to change the network configuration to give the bridged network a fixed IP address.  I first explicitly set the MAC addresses of the two adapters, because the order of the virtual adapters in the VirtualBox Manager is not necessarily the same as the order of the adapters in the guest OS.  So I went in to the System->Preferences->Network Connections screen and explicitly set the “Device MAC address” for the two adapters.

Having correctly mapped the Linux adapters to the VirtualBox adapters I then set the Bridged adapter to use fixed IP addressing rather than DHCP.  There is no need for additional routing or default gateways because we expect the two machine to be on the same LAN segment.

Updating the Hosts File

Having renamed the machines and reconfigured the network I then updated the /etc/hosts file to

• refer to the new machine name
• add a new line to the hosts file to provide an additional IP address for my server (the new fixed IP address)
• add a new line for the fixed IP address of the other virtual machine

10.0.3.101      vboxdb.oracle.com       vboxdb  # Added by NetworkManager
10.0.2.15       vboxdb.oracle.com       vboxdb  # Added by NetworkManager
10.0.3.102      vboxfmw.oracle.com      vboxfmw # Added by NetworkManager
127.0.0.1       localhost.localdomain   localhost
::1     vboxdb.oracle.com       vboxdb  localhost6.localdomain6 localhost6

To make sure everything takes effect I restarted the server.

Reconfiguring the Database on the DB Machine

Because we changed the hostname the listener and the EM console no longer start so I need to modify the listener.ora to use the new hostname and I also need to rebuild the EM configuration because it also relies on the hostname.

I edited the $ORACLE_HOME/network/admin/listener.ora and changed the listening address to the new hostname:

      (ADDRESS = (PROTOCOL = TCP)(HOST = vboxdb.oracle.com)(PORT = 1521))

After changing the listener.ora I was able to start the listener using:

lsnrctl start

I also had to reconfigure the EM database control.  I first deconfigured it using the command:

emca -deconfig dbcontrol db -repos drop

This drops the repository and removes any existing registered dbcontrols.

I then re-configured it using the following command:

emca -config dbcontrol db -repos create

This creates the EM repository and then configures and starts dbcontrol.

Now my database machine is ready so I can close it down and take a snapshot.

Disabling the Database on the FMW Machine

I set up the database to start automatically by creating a service called “dbora”.  On the FMW machine I do not need the database running so I can prevent it auto-starting by running the following command:

chkconfig –del dbora

Note that because I am using a snapshot it is not a waste of disk space to have the DB installed but not used.  As long as I don’t run it, it won’t cost me anything. I can now close the FMW machine down and take a snapshot.

Creating a New Domain

The FMW machine is now ready to create a new domain.  When creating the domain I can point it at the second machine which is running the database.  I can potentially run these machines on two separate physical machines as long as I have the original virtual machine available to both of the physical machines.

Gotchas in Snapshotting

VirtualBox does not support the concept of linked machines in a network like some virtualization technologies so when creating a snapshot it is a good idea to shut both VMs down and then take a snapshot on both of them.  This is because we want to keep the database in sync with the middleware.  One way to make sure that this happens would be to place all the domain configuration files on the database server via an NFS share, this would mean that all we would need to snapshot would be the database machine because that would hold all the state and configuration.

The Sky’s the Limit

We have covered a simple case of having just two machines.  I have a more complicated configuration in which two machine run a RAC database off the same base OS image, and two more machines run a SOA cluster based on the same OS image.  Just remember what machine holds state and what are the consequences of taking a snapshot.