CHAPTER

27

Oracle VM Maintenance

Proper maintenance of the Oracle VM system is important for its reliable operation. The Oracle VM servers can be easily updated (patched), which ensures that fixes to issues discovered in between errata releases get applied to the servers. The update process follows these simple steps:

1. Create the Yellowdog Updater Modified (yum) infrastructure. (Although this is done only once, periodic changes are required to maintain access to the latest version.)

a.   Create a yum infrastructure.

b.   Update the yum systems from the Oracle Unbreakable Linux Network (ULN).

c.   Configure settings for Server Update Groups in the Oracle VM Manager.

2. Periodically update or patch the Oracle VM servers.

a.   Upgrade to the latest version of Oracle VM Manager. You must always update the Oracle VM Manager before updating servers. This is a nonintrusive process and has no impact on running Oracle VM servers or guests.

b.   Update the Oracle VM servers using the Oracle VM Manager.

This chapter covers how to perform these steps. We’ll start with the first step, which is creating the yum repository.

Creating a Repository

Patching an Oracle VM system requires the administrator to configure a yum repository. The yum repository is a warehouse of RPM package files, which allow for quick and easy software installation on Red Hat/Oracle Linux. YUM repositories hold several RPM package files and enable the downloading and installation of new software. YUM repositories normally share their files via an HTTP or HTTPS server, which is generally installed on the yum server. Oracle VM can update the Oracle VM servers in yum, providing for a simple way to maintain larger numbers of Oracle VM Server (OVS) systems. The same yum repository for Oracle VM can also serve as a yum repository for Oracle Linux. This is because each YUM server subscribes to distribution channels in the Unbreakable Linux Network. Although Oracle VM is free, the access to OLN is limited to customers who have a subscription. The good news is that a subscription is free for Oracle hardware under a valid support contract, and it comes at low cost for users running on non-Oracle systems.

YUM Repository Server Prerequisites

The onsite yum repository is created and managed on a physical server or virtual machine in your data center. Although it is not installed on any of the Oracle VM servers in your environment, you can use the same server where Oracle VM Manager was installed. Simply enable the HTTP server that is normally installed with Oracle Linux or Red Hat where you installed the Oracle VM Manager. Before you can create a local repository, you must have the following items:

   A server running Oracle Linux 6 or Oracle Linux 7. This can also be a virtual machine.

   At least 2GB of RAM must be available, although 6GB is recommended.

   The available disk space varies, depending on the channels subscribed to. For just Oracle VM, at least 6GB is recommended. Some channels can consume over 80GB of data, so be sure to refer to https://linux.oracle.com for the requirements for each channel.

   The httpd RPM must be installed.

   An active Internet connection, either direct or through a proxy. This is required for the repository to update itself.

   A valid Oracle Support Identifier (SI, or often also called a CSI). This is included in an Oracle Support Contact for Oracle VM and is free with Oracle hardware support. An Oracle Support Contract for Oracle VM can be purchased through your preferred Oracle Partner.

   A valid Oracle Single Sign-On (SSO) account associated with the support identifier. For Enterprise deployments, the login e-mail is often a role e-mail, such as [email protected].

ULN Registration

The following steps are performed on the yum repository server. To register the yum server, use the command uln_register. This will provide you with a few prompts for registering the server with the ULN. To start the process, run the command uln_register as root.

The first prompt, shown next, will ask you to verify that the network is connected and that an Oracle Single Sign-On account is available.

Next, enter in the e-mail address and password for the Oracle Single Sign-On account, along with the CSI that includes a subscription to the ULN, as shown next.

In the next step, shown here, you verify the profile name for this repository. By default, it will be the fully qualified domain name (FQDN) on the repository.

In the next step, the system automatically adds all the packages for the server. However, because this will be a repository server, you do not need to include all the RPM packages already installed on the server. In an upcoming step, the server will get a subscription to the OVM channel, which allows the repository to be populated, as shown here, with all the OVM RPMs.

The final step, shown next, officially kicks off the registration process by sending the profile to the ULN servers and registering the server. The ULN profile contains the software inventory data that allows the ULN to select the appropriate packages for the system.

Sending the profile can take some time, as shown next, depending on the bandwidth available.

Once the registration is complete, you have the option to configure the system for Ksplice (shown next), a technology that allows the server to be patched without rebooting. For a repository, this option can be disabled because the repository server is not normally patched directly from the ULN.

When the process is complete, as shown here, the system is ready for the next set of steps, which will subscribe the repository to the patches. This process requires a web browser pointed to https://linux.oracle.com.

Channel Subscription

With the server registered to the ULN, you now need to register the server to the OVM channel, which contains the RPMs required to patch and upgrade OVM. Using a browser, log into https://linux.oracle.com using the same SSO ID you used to register the system. When you first log into the ULN, the Home tab is displayed (see Figure 27-1). It shows all the registered servers and a list of recently updated and added channels. The following tabs are also available to display additional information:

FIGURE 27-1.    The ULN Home page

   Channels    Provides a list of all the channels available and the number of packages in each channel

   SystemsProvides a list of all systems this account supports, with the CSI number for each system, along with the number of subscribed channels for each server.

   ErrataProvides notifications from the ULN, announcing updates, bug fixes, as so on. These are sorted by severity, date, or advisory. This tab also links the systems affected to the server managed by this account.

   CVEProvides a list of all common vulnerabilities and exposures. Common Vulnerabilities and Exposures (CVE) is a dictionary of common names for security vulnerabilities.

   CSI Administration    This is where you can manage the Support Identifier (SI) to which the account has access.

The next task is to subscribe the repository server to the Oracle VM channel. Under the Recently Registered Servers list, click the new repository server. This brings up the System Details page, shown in Figure 27-2, which shows what channels the system is subscribed to, along with system information such as operating system version, server architecture, and date registered.

FIGURE 27-2.    The System Details page

Next, the server must be modified to make it a yum server. To do so, click the Edit button and then check the Yum Server box (highlighted next) to apply the change. This will promote the server to being a yum server, with access to all channels.

Now, back on the System Details page, click the Manage Subscriptions button. This allows you to select other channels, shown here, to subscribe the yum server to.

Scroll down in the Available Channels list and find the Oracle VM 3.X Latest channel, where X is the version of Oracle VM being run. Click the channel name to move it to the Subscribed Channels list. Then click Save Subscriptions. Now the server is subscribed to the Oracle VM channel. Optionally, to save space, you can unsubscribe from the Oracle Linux, Ksplice, and UEK channels, which are normally used in production environments.

In the next set of steps, you will configure the yum server to synchronize the RPMs.

YUM Server Configuration

The following steps configure the server and a yum repository (repo) for synchronizing the RPMs from the ULN to the repo server.

The first step is to edit the /etc/yum.repos.d/public-yum-ol6.repo file to enable the Oracle add-ons. This will make available several useful RPMs, including the uln-yum-mirror RPM. In the yum configuration file, find the following stanza and make sure that enabled=1 is set:

Next, install the uln-yum-mirror RPM using the command yum -y install uln-yum-mirror, as shown next. Yum will automatically install all the dependencies if needed.

Next, you need to create the directory where all the files will be installed. By default, they go into /var/www/html/yum. It is recommended that you make this a separate filesystem, under Logical Volume Manager (lvm) control. (Note that over time, more disk space will be required. In the example, 100GB of space is used.)

Next enable the httpd server:

Now, you can verify what channels are subscribed to by using the command yum repolist, as shown here:

Because this is a yum server, the channels should be disabled in the rhnplugin.conf file. This will disable the channels from being used by the yum process when using yum to patch the server that is hosting the local copy of the yum repository. The file is /etc/yum/pluginconf.d/rhnplugin.conf. For each of the channels in the repo list, add in a stanza in the rhnplugin.conf file with the parameter enabled=0. If new channels are subscribed to, do not forget to add them to the rhnplugin.conf file with the channels disabled. In our example, the following lines will be added:

By default, the repo is synchronized nightly, but this can be done manually using the command uln-yum-mirror. The first synchronization will take several hours, depending on the available Internet bandwidth.

The final step is to configure the yum server to use the local repository instead of one on the Internet. To do this, you need to create a new configuration in /etc/yum.repos.d with the yum repository configuration. You can browse to http://<repository>/yum/ to find the base URL for each repository. You can also use the $releasever and $basearch parameters. For our example, the file /etc/yum.repos.d/m57.local.repo was created:

The GPG key also needs to be imported using the command rpm --import /usr/share/rhn/RPM-GPG-KEY. To verify that the repository is working correctly, run the commands yum clean metadata and yum repolist.

Patching an Oracle VM Server

One of the most common tasks an administrator has is patching systems on a regular basis. Patching consistently using a schedule is important for both the security and health of the servers. The patches address bugs, improve features, and fix security vulnerabilities. Not patching will lead to more outages and result in significantly more exposure to the systems being compromised.

Patching Oracle VM Server requires that a yum repository be built and subscribed to the appropriate ULN channel. Once subscribed, the repository should have the latest patches from Oracle. Patching is different from upgrading: a patch is usually for servers with the same major or minor number, whereas an upgrade is generally used when the major or minor number changes. On occasion, the upgrade process can use the yum repository, but often an upgrade from a .iso file is the correct process to use. Upgrades are addressed later in this chapter.

Configuring Server Update Groups in Oracle VM Manager

Before Oracle VM servers can be patched, Oracle VM Manager needs to be configured to use the yum repository. To manage the server update setting, from OVMM navigate to the Reports and Resources tab and then select Server Update Groups, as shown next.

From this section, you can create a new update group. Although OVMM supports this for both SPARC and X86 systems, only X86 will be used in our example.

First, highlight the GlobalX86ServerUpdateConfiguration option and then click the green plus sign icon to add a new configuration, as shown next. This will start the dialog to create a new server update repository.

It is possible to configure multiple repositories in OVMM to allow the admin to patch against different release schedules. The most common example is to have a separate yum directory for each quarter to enable consistency when patching. This can also be done for OVS upgrades, because the administrator can make a repository specific to upgrading the OVS from one release to another. The configuration of the repository, shown next, can be edited once it has been created. The configuration includes the following parameters:

   Name This is the name of the rule.

   Repository Name This is the name of the repository used.

   URL    This is the URL to the yum repository (note that this is not the main page of the yum server, but the specific path that will be used for updates). There should be an updateinfo.xml file in the directory.

   Enabled If this option is not checked, the system will ignore the update repository. This is helpful when multiple update repositories are configured, because any repositories not needed for the current patch activity can easily be disabled without configuration data being lost.

   Package Signature Type GNU Privacy Guard (GPG) can be used to verify the signature of the files in the yum repository.

   Package Signature Key If a package signature is used, the corresponding key must be entered.

   Description You can place any additional information required to document the entry here.

Once the configuration is set, the server can be patched via yum.

Updating the Oracle VM Servers

Identifying servers that need to be patched is a straightforward process. You can see the current state of each Oracle VM server from the server’s view by selecting Servers and VMs | Server Pools, as shown here.

In this view, the column Update Required shows what servers require an update. Before the server is updated (patched), it is set to maintenance mode, which triggers the live migration of running VMs from the server being updated to other Oracle VM servers in the server pool. Checking their status from this screen is helpful in large server pools. To select a server to patch, highlight the server and then click the Update Server icon, highlighted here.

This starts the upgrade process. A warning message will appear (shown next), informing you that the server will be placed into maintenance mode and that all VMs will be live migrated to other hosts, which means they will be moved with no outage.

As the VMs are migrated, the servers in the pool will be locked, so it is best if no other activities are planned while the servers are being patched. The patch process also kicks off a job to upgrade the installed server. This job can be tracked in the job Summary section of the management interface. Once the OVS is patched, the system will show back online in OVMM, but the server will be in maintenance mode. No VMs can be moved to this system until the state is cleared. This gives you a chance to verify that all the network and storage is visible on the server prior to moving workloads back to the server.

To take the server out of maintenance mode, select the server and then click the edit icon (highlighted here).

Next, uncheck the Server in Maintenance Mode box (highlighted here) and then click OK. A short job will run that takes the server out of maintenance mode.

Once the server is out of maintenance mode, the process can continue with the other servers in the server pool.

Summary

This chapter covered how to prepare for and perform Oracle VM server patching. Patching is a simple process, and it is critical to the reliable operation of your private cloud. The chapter also showed you how to configure a repository server by enabling a local copy of Oracle RPMs used not only for patching Oracle VM systems but also many other Oracle technologies, including Oracle Linux. In the next chapter, you learn about some common troubleshooting tasks. The ability to troubleshoot issues with an Oracle VM installation is a critical skill to learn—not because problems happen often, but because you’ll want to be able to resolve them quickly if they occur.