CHAPTER
18
Creating Virtual Machines Using Templates
Now we come to the crux of cloud computing: the creation of the guest virtual machine. This is the process through which the target host operating system will run using resources that have been defined and presented to the Oracle VM infrastructure and application systems, databases, and any program that would otherwise execute on bare-metal but is now executing in the virtual machine. With rare exception, anything that runs in the bare-metal machine environment can run without modifications in the virtual machine environment.
The following sections present the process of creating a virtual machine in the Oracle VM infrastructure. Other sections of this book covered processes where the necessary resources are configured and presented, including network and storage resources. As a prerequisite to creating virtual machines, the network and storage resources must be available and understood.
The process of importing templates is slightly different from importing appliances. Most notable are the “undefined networks” imported along with templates. This can be addressed as follows:
1. Remove any undefined networks from the templates.
2. Associate the correct networks with the templates.
The “undefined network” needs to be deleted from the Networking section of Oracle VM Manager. With respect to importing and preparing Oracle VM appliances, this is the newer and now preferred construct for using pre-built virtual machines. The process differs slightly from templates because these will not come based on OVM 2 xenbrX bridge names.
Oracle VM Template or Appliance as a VM Source
The Oracle VM creation process is the same whether it’s done from an imported template or an imported appliance. The most common (and overall simplest) method of creating a virtual machine is to use a template or virtual appliance. Oracle Corporation provides numerous Oracle VM templates and appliances that can be downloaded from the eDelivery site edelivery.oracle.com. A template can also be generated from an existing virtual machine using the Oracle VM Manager GUI. Alternatively, a virtual machine can be created manually by cloning another virtual machine or by installing the target operating system from an ISO using the same process as if you were installing the operating system on a bare-metal machine. The manual process of creating a virtual machine is covered in the next chapter.
The process of creating a virtual machine from a template can be summarized as follows:
1. Import the template into a storage repository (this process is detailed later in this chapter in “Importing a Template”).
2. Present the necessary storage LUN(s) if using physical disks for the virtual machine boot disk.
3. Add one or more networks (the process of creating Oracle VM networks is detailed in the “Network Management” section of this chapter).
4. Create the template clone customizer. The clone customizer is particularly useful to ensure that the storage components associated with the Oracle VM (the ISOs, templates, appliances, vm.cfg, and virtual disks) are kept is the same place, especially since NFS-based repositories can be shared across server pools.
5. Clone the template to a virtual machine.
Understanding the Resources
The Oracle VM Manager operations can be performed using the web-based graphical user interface (GUI) or the command-line interface (CLI), which can be launched from any machine with SSH connectivity to the machine running the VM manager software. For more information about the Oracle CLI-based operations, refer to the VM manager CLI documentation. The process of creating a virtual machine is presented in this document through the use of the web-based GUI.
Network Management
The Oracle VM network environment supports detailed Layer 2 and Layer 3 switching and routing and advanced configurations, and it’s fully virtualized. This includes VLAN definitions and support as well as other advanced network concepts. Figure 18-1 shows the Networking tab of the Oracle VM Manager GUI and reflects various networks defined for the network channels used by the Oracle VM operations. Note that any detailed network administration tasks will be discussed in a separate section and/or will reference Oracle VM networking documentation. Also, although a single virtual machine network may be defined and assigned to the Oracle VM for virtual machine communications, the best practice recommendation is to dedicate network processes based on the following specific types of traffic (that is, each of the following should be on a physically separate and dedicated network).
FIGURE 18-1. Network Management screen
Cluster Heartbeat The heartbeat network is required for clustered VM servers in the server pool and is used as the “interconnect” between the servers. It should have extremely low latency and near-zero dropped packets. Heartbeat operations have an extremely low tolerance. Virtually any degradation to the communications over the heartbeat network will cause VM server eviction or fencing, resulting in unplanned guest VM migrations to the remaining operating VM servers.
Virtual Machine The guest VM network is used for normal network communications between guest VMs, whether running on a given VM server or across VM servers, either in the same server pool or across server pools. The Virtual Machine checkbox also instructs OVM to create a Xen bridge on the OVM servers to allow VMs to connect to the rest of the world through the network. This virtual network is what the guest VMs will use for their access to resources in the Oracle VM infrastructure, resources across the enterprise, or Internet-based resources.
Server Management, Live Migrate, and Storage These network services are described in detail in the Oracle documentation, but it suffices to say the recommended best practice is to dedicate a physical network for each of these, depending on the level of activity required across the enterprise. If the resources are available, each physical network should be configured to use a bonded interface of two or more network interface cards.
Storage Management
As with network operations, details of storage management can be found in the Oracle documentation. Here, we discuss the tasks related to guest VMs that are deployed from templates or used as the source to create a template. In general, two types of disks are associated with guest virtual machines and templates:
Virtual disks Virtual disks are sparse files that are contained in Oracle VM storage repositories for use by Oracle VM guests. Virtual disks are optional but pretty common; they are created and used by Oracle VM guests to contain the guest operating system or any other data the VM owner requires.
Physical disksPhysical disks can be local disks found on each Oracle VM server or LUNs that reside on external storage arrays. LUNs can be presented to the Oracle VM servers using iSCSI or Fibre Channel and then presented to the Oracle VM guests through the Oracle VM servers. LUNs can be presented directly to the Oracle VM guests if iSCSI is used, but not Fibre Channel.
NOTE
The choice of which type of disk to use and which protocol is best depends entirely on requirements. The “best” storage is what is deemed to be the best fit for your needs; you don’t need to limit yourself to just one storage protocol—use all protocols if that helps you achieve your goals.
Repository-Based Storage
To be supported in a production capacity, virtual machines must be deployed using physical disk definitions for disks used by database management systems to contain data. Virtual disks used to contain the guest operating system are fully supported in production. With that said, virtual disk definitions provide more rapid deployment of guest virtual machines because the disks do not need to be pre-allocated and can be used from storage assigned to the repository “on the fly.” Naturally, care must be taken to ensure that storage is available for the virtual machine to be deployed from the template, and this can be determined by examining the template storage requirement on the Disk tab of the expanded template or the expanded source guest VM from which the template was created.
Figure 18-2 shows the information screen of an Oracle VM repository where the information of available storage for use by virtual disks can be quickly gleaned.
FIGURE 18-2. Repository management screen
Physical Disk-Based Storage
Even though the name implies a physical disk allocation, the physical disk definition merely indicates a disk allocation with a definition that is closer to an actual physical allocation with physical beginning and ending points (that is, the LUN beginning and ending blocks, which are defined at the hardware layer of the storage source). Care is taken here not to refer to the storage source as network-attached storage because the storage source may be locally attached disks that are local to the VM server running the guest VMs. Note, however, that if local storage (that is, local to the VM server) is used for a particular VM, then it follows that guest VMs cannot run on any other VM server and must always execute on the VM server where the local storage is defined. This means that in the event of any migrations, the guest VM will not be able to run except on the VM server where the storage physically resides.
Figure 18-3 shows the storage management screen with a SAN logical volume that has been allocated for use by a repository. Similarly, a file server could have been used to allocate file system– based files for use by the repository. In either case, the storage allocated for the repository is destined to contain the same types of files—ISO files, guest VM virtual disks, assemblies, and so on.
FIGURE 18-3. Storage management screen
Oracle VM Server Resources
This section provides an overview of the VM server resources used by guest virtual machines.
Processors
The number of processors available to guest virtual machines can theoretically exceed the number of processors (or processor cores) available on the VM server. However, if the actual number of processors required by the guest virtual machines is larger than the number of physical processors available on the VM server hosting the virtual machines, there is a risk the virtual machines will cause the VM server to crash or at the very least be evicted (or “fenced”) from the cluster or server pool where the VM server is running. In the event a VM server is fenced, all virtual machines (even the ones that are not currently running) will be migrated to the remaining VM servers.
Memory
Just like the number of processors available to guest virtual machines, the amount of memory allocated to guest virtual machines can theoretically exceed the amount of memory available on a given VM server. But again, as with processor availability, if the amount of memory required by active guest virtual machines exceeds the physical memory available on a VM server, node eviction/fencing can occur. With processor and memory limits in mind, as a general rule, the number of processors and the amount of memory allocated to the virtual machines should be lower than the actual physical number of processors and the physical amount of memory available. Even though this may seem to be a commonsense statement, it is often misunderstood that virtualization does not magically allow processor or memory requirements to exceed physical availability.
VM Server Storage
VM server-based storage is a very tricky thing. It can be used for virtual disk or physical disk definitions used by templates, repositories, and/or virtual machines; however, it restricts the associated operations of the virtual machines to be limited to working only on the VM server that owns the storage. In the past, this was a crippling limitation. With the release of OVM 3.4, a very important feature has been included called “live migration.” OVM 3.4 incorporates storage live migration, which allows for the live migration of VMs and their storage from the local disk on one OVM server to the local disk on another OVM server. For the purposes of this chapter, all references to storage allocated to virtual or physical disks will be with respect to shared network-based storage—whether it’s storage area network, network attached storage, network file systems, or file servers—and this shared storage is available to all the VM servers in the server pool where the virtual machines will be operating.
Using a Template or Appliance to Create an Oracle VM
Although the template and appliance creation processes are outside the scope of this chapter, for reference purposes, the steps are listed here. Depending on the source of the template or appliance, it is a good idea to become familiar with the configuration items within its definition. Figure 18-4 shows an example of an expanded template in the repository management screen. Each of the primary candidate configuration items can be selected from the Network and Disk tabs. To edit a templates configuration, highlight the template and select the Edit icon (the pencil in the menu bar), as shown in Figure 18-5.
FIGURE 18-4. Repository-based source template
FIGURE 18-5. Template edit screen
There are two methods for creating a template: you can clone a virtual machine to a template or you can clone a template to another template. In either case, you must complete the previous steps to allocate storage and configure a network for each template. The template customizer is a construct that is used during the cloning process to specify the specific storage and network components that will be incorporated into the template. The customizer is also used when deploying a virtual machine from a template and/or migrating templates, virtual machines, and so on, from one repository to another and the general processes are described here.
Importing a Template
The following process describes template creation using a .tar file as the source:
1. Place the .tar file in a directory accessible to the HTTP or FTP service.
a. Determine the stub or parent directory structure for the HTTP or FTP service.
b. Create a dedicated directory where the .tar file will reside (at least one directory name must be specified during the import operation).
2. Verify the target repository has sufficient resources to support the import operation.
a. Increase the storage for the repository or create a new repository.
b. Present the repository to the administration VM server.
c. Designate the refresh VM server.
d. Refresh the Oracle VM storage and repository.
3. Begin the import operation using the HTTP or FTP service. The command will look similar to the following (Figure 18-6 shows an example of the dialog used to input this information):
FIGURE 18-6. Template import dialog
where:
uname:pwd is the username and password of an account that has access to the .tar file.
@192.168.2.61 is the IP address or fully qualified server name where the HTTP or FTP service is running and the file is located.
/tplts/OVM_MADB_1of2.tgz is the path to the .tar file that is a directory subordinate to the HTTP or FTP default service directory. (Note that the parent folders /var/http/www and /var/ftp/pub are not specified.)
Exporting a Template
The following process describes .tar file creation using a VM template as the source. Although this process is not required in order to create a virtual machine from a template, the steps are provided here in support of moving a template from one Oracle VM infrastructure installation to another.
1. Verify that the target file system has sufficient resources to support the .tar file creation operation.
a. Identify VM physical disk storage and configuration file size.
b. Identify VM virtual disk storage size.
2. Locate the virtual machine directories in the repository file system shared with the VM servers.
The location of the virtual machine–related files can be determined based on the repository file system where the virtual machine definition is located. For more information about the file system structure, refer to the Oracle VM Manager Administration Guide.
3. Use the UNIX tar command create the .tar file using compression. The contents of the .tar file will include the following:
All virtual machine virtual disks
All virtual machine physical disks
The virtual machine configuration file
Any other files stored in the virtual machine repository directory
The file size maximum needed for a file transfer can be determined using one or more of the following criteria:
File transfer across the Internet
File transfer across the local network
File transfer during the import process
If the virtual machine being exported exceeds the predetermined amount, the exported .tar file may need to be broken up into two or more files.
Oracle Corporation recently released additional information regarding the creation of template files. This information is captured in the backup and recovery strategy of an Oracle VM infrastructure. Specifically, the .tar file can be created by using the repository export feature and a shell script that is passed the unique identifier of the VM guest. For more information, refer to the Oracle documentation regarding repository exports.
Creating a Virtual Machine from a Template
The following describes the virtual machine creation process using a template that was imported as described in the “Importing a Template” section of this chapter:
1. Import the template as described in the “Importing a Template” section of this chapter.
2. Identify the resource requirements (storage and network).
3. Allocate and configure resources as required.
4. Create a virtual machine clone customizer using the resource requirements identified and allocated. Figures 18-7 through 18-10 show the basic progression within the VM Manager GUI when a clone customizer is created for a given template that is about to be used to generate a guest VM. To add a clone customizer to a given template, highlight the template, select the Manage Customizers icon from the menu bar, and then click the Add Customizer icon (the big green plus sign) from the Manage Clone Customizers for VM dialog.
FIGURE 18-7. Initial clone customizer screen
FIGURE 18-8. Storage Mappings clone customizer screen
FIGURE 18-9. Network Mappings clone customizer screen
FIGURE 18-10. Final clone customizer screen
Note that in the storage management clone customizer screen, after you select the target storage type (virtual or physical disk), the search icon (the magnifying glass) will reveal only available storage objects (that is, predefined storage) available for use.
After you complete the Network Mappings dialog and click the Finish button, the VM Manager will kick off the jobs to create the clone customizer, which includes the processes associated with network and storage mappings and the clone customizer definition being added to the template in the repository. These jobs can be seen executing in the status window at the bottom of the VM Manager GUI. If they are successful, the Manage Clone Customizer window is displayed showing the newly added clone customizer to the list of customizers available for the given template.
5. Select the template to be cloned to the virtual machine.
6. Select the clone customizer created earlier.
7. After the VM has been created, adjust the CPU and memory allocations accordingly.
Adding Resources to the New Virtual Machine
Modifications to the configuration of CPUs, memory, and/or storage after creating the virtual machine may be needed. The process of modifying the virtual machine processor and/or memory is straightforward and is only limited by the amount of physical memory available on the VM server. Simply put, figure out the total amount of resources available and subtract the amount of the resources currently allocated to other virtual machines running on the virtual machine server; whatever remains is what is available for the given virtual machine in question. For example, if the virtual machine server is equipped with two quad-core processors, a total of eight cores are available. If four virtual machines will run on this particular VM server, then theoretically each virtual machine could be configured with two processors each. However, this is not a best practice because the VM server requires some processing power for its own background operations. Hence, the maximum number of available processor cores in this example would be seven.
When it comes to memory, however, there is no definitive limit to the amount that can be allocated to the virtual machines, other than the physical limit of the memory currently available. With that said, service requests have been opened related to virtual machines causing VM server eviction from a cluster when the active virtual machine memory requirements approach 100 percent of the available memory. Keep in mind that the memory requirements of the VM server background operations are not significantly large. The 80/20 rule is very likely the safest ratio of allocated memory to available memory.
Oracle VM Assemblies
Creating guest virtual machines from a template is performed as a “single result” set of operations (that is, the guest virtual machine is the single result of the overall set of tasks). There are other, more advanced ways to deploy a set of virtual machines, including some specific interoperability configuration items that can be controlled during the deployment of multiple machines that are tightly integrated; this construct is known as an assembly. Deploying an assembly is a one-shot process, which results in multiple virtual machines based on multiple templates. However, deploying a set of templates in a “one-shot” stream of processes requires the use of Oracle Enterprise Manager 12c or 13c. It should be noted that the exact same process can be done without using Enterprise Manager. However, the process is done one virtual machine at a time and is still based on a template for each virtual machine.
With the release of Oracle VM 3.4, assemblies are no longer part of the Oracle VM Manager GUI and are, in fact, managed only through Oracle Enterprise Manager. An assembly is a tightly coupled set of virtual machines with complex deployment requirements, which are part of the assembly definition and are managed during the deployment process. One such example is the Oracle eBusiness Suite Oracle VM Assembly, which can be downloaded from the eDelivery site. After successfully importing the assembly into the OEM software library and after deploying the Oracle VMs inside the assembly using the template import and deployment processes described in this chapter, an entire eBusiness suite set of virtual machines will be running. This suite includes a multi-node RAC database, a highly available and load-balanced middle tier, and a fully populated and production-ready vision database with a network-file-system-capable management layer, which is also production ready. All these components make up a single assembly, which is composed of several template or appliance files (close to 30 files). After applying the underlying principles of this chapter, you will have multiple Oracle virtual machines in a tightly integrated configuration, deployed from an assembly that is constructed and subsequently deconstructed using Oracle VM Manager.
Summary
Creating an Oracle guest virtual machine using templates is the most common method and the basic foundation of deploying complex, loosely coupled machines in a virtualized infrastructure. A more advanced method of integrating templates is through the use of an assembly, which is basically a collection of templates with specific deployment characteristics that, when combined with the basic deployment of a guest from a template, can be used to deploy tightly coupled guest virtual machines. For example, Oracle Corporation has made assemblies available that include all the pieces and parts of a complete E-business Suite infrastructure, including the database machines and databases (in RAC and stand-alone configurations) and the middle-tier application servers, including the SOA infrastructure and WebLogic hosts.
