5.5 Upgrading Oracle VM Server for x86 from Release 3.2.10 or later

Complete the tasks in this section to upgrade to Release 3.4 from Oracle VM Server Release 3.2.10 or a later version such as Oracle VM Server Release 3.2.11.

Note

Beginning with Release 3.4.6, upgrades from Oracle VM Server for x86 at Release 3.2.10 or 3.2.11 and Oracle VM Agent for SPARC at Release 3.3.1 are not supported. Users on these older server releases must first upgrade to a supported version (e.g. 3.4.5) before upgrading to a later version.

Before you attempt to upgrade Oracle VM Server to Release 3.4, you must prepare your environment. See Section 5.2, “Preparing to Upgrade Oracle VM”.

You must set up and configure both Yum repositories and use the UpgradeServers.py script to upgrade Oracle VM Server from Release 3.2.10. Oracle VM Manager does not allow you to upgrade from Release 3.2.10 with any other method.

As an alternative to using the UpgradeServers.py script, you can reinstall Oracle VM Server using the Release 3.4 installation media. However, reinstalling Oracle VM Server deletes all configuration settings.

5.5.1 Upgrading Oracle VM Server from Release 3.2.10

This section describes how to upgrade Oracle VM Server from Release 3.2.10, or a later version such as Release 3.2.11, with the UpgradeServers.py script.

Important

As of Oracle VM Release 3.4.5, management of Oracle VM Server for x86 at 3.2.1x and Oracle VM Agent for SPARC at Release 3.3.1 is deprecated. If management of Oracle VM Servers at these release versions is still required, see Section 7.6, “Enabling the TLS Version 1 Protocol” in the Oracle VM 3.4 Installation and Upgrade guide.

As of Oracle VM Release 3.4.6, management of Oracle VM Server for x86 at 3.2.1x and Oracle VM Agent for SPARC at Release 3.3.1 is removed. No error events are raised if Oracle VM Servers at these unsupported versions are discovered; however, the following message is displayed at the end of an upgrade, indicating that these versions are no longer supported: "3.2.10/3.2.11 Oracle VM x86 Servers and SPARC agent 3.3.1 managed Servers are no longer supported in Oracle VM Manager 3.4. Please upgrade your Server to a more current version for full support."

Beginning with Release 3.4.6, upgrades from Oracle VM Server for x86 at Release 3.2.10 or 3.2.11 and Oracle VM Agent for SPARC at Release 3.3.1 are not supported. Users on these older server releases must first upgrade to a supported version (e.g. 3.4.5) before upgrading to a later version.

5.5.1.1 Setting Up the Yum Repositories

The upgrade process from Release 3.2.10, or a later version such as Release 3.2.11, involves two steps. The first step is transitional and upgrades the kernel and core packages. The second step upgrades Oracle VM Server to Release 3.4.

The Yum repositories you must set up to upgrade Oracle VM Server from Release 3.2.10 to Release 3.4 are as follows:

  • Transitional update repository

    • This repository contains the packages required to upgrade Oracle VM Server to a transitional state before upgrading to Release 3.4.

    • You must configure this repository as a server update repository in the Oracle VM Manager Web Interface. The repository name must be 3.4_trans_repo.

    • The packages for this repository reside in the Oracle VM Server installation media in the Transition/* directory. You must make the Oracle VM Server installation media available over the network so that the contents of this directory are accessible. Alternatively, you can set up this Yum repository to mirror the contents of the ovm3_x86_64_3.4_transition ULN channel.

  • Release 3.4 update repository

    • This repository contains the packages required to upgrade Oracle VM Server to Release 3.4.

    • This repository can contain additional packages such as third-party Oracle VM Storage Connect plug-ins.

    • You must configure this repository as a server update repository in the Oracle VM Manager Web Interface. The repository name must be 3.4_ovs_repo.

    • The packages for this repository reside in the Oracle VM Server installation media in the Server/* directory. You must make the Oracle VM Server installation media available over the network so that the contents of this directory are accessible. Alternatively, you can set up this Yum repository to mirror the contents of the ovm34_x86_64_latest ULN channel.

Creating the Yum Repositories

You must create both Yum repositories on a system that is accessible through HTTP or HTTPS.

Oracle recommends that you copy the content of the Oracle VM Server installation media to the Yum repositories. However, you can set up your Yum repositories to mirror specific Oracle VM ULN channels.

Using the Oracle VM Server installation media
  1. Download the most recent Oracle VM Server installation ISO file.

  2. Create a folder to mount the ISO file, for example:

    # mkdir /tmp/ovs-mount
  3. Mount the ISO file, for example:

    # mount -o loop OVS-3.4.1.iso /tmp/ovs-mount
  4. Create a directory for repository access using any appropriate HTTP server, for example:

    # mkdir /var/www/repos
  5. Copy the mounted ISO folder to the directory using -r for recursive and -p for preserve, for example:

    # cp -rp /tmp/ovs-mount/* /var/www/repos/
  6. Check that both of the repositories are accessible. You should access both repositories on a different system, such as an instance of Oracle VM Server. To ensure both repositories are accessible, download a small file such as repomd.xml as follows:

    # wget http://example.com/repos/Server/repodata/repomd.xml
    # wget http://example.com/repos/Transition/repodata/repomd.xml
Tip

Temporarily serve your repositories with the Python SimpleHTTPServer module, as in the following example:

# cd /var/www
# python -m SimpleHTTPServer 80
Creating mirrors of ULN channels

Set up your Yum repositories to mirror the following ULN channels:

  • ovm3_x86_64_3.4_transition

    Contains the packages required to upgrade Oracle VM Server to a transitional state before upgrading to Release 3.4.

  • ovm34_x86_64_latest

    Contains the packages required to upgrade Oracle VM Server to Release 3.4.

For more detailed information about setting up a Yum repository to mirror a ULN channel, see the following document: http://www.oracle.com/technetwork/articles/servers-storage-admin/yum-repo-setup-1659167.html

Including Additional Packages

You can include additional packages for Oracle VM Server, such as a third-party Oracle VM Storage Connect plug-in, in the Release 3.4 update repository. These packages are then included in the upgrade for Oracle VM Server.

Note

Any additional packages that you add to the repository must be compatible with Oracle Linux 6.

To add packages to the Yum repository, do the following:

  1. Download the packages from the appropriate vendors.

  2. Copy the packages into the Server/Packages directory in the Oracle VM Server 3.4 Update Repository, for example:

    # cp osc-sun7k.rpm /var/www/repos/Server/Packages/
  3. Change directory so that you run the following commands from the root, for example:

    # cd /var/www/repos/Server
  4. Find the repository configuration file:

    # find ./ -name "*comps-ovs-core.xml"
    ./repodata/3bbd98ef14e1e62734b8df6360825010001323218736-comps-ovs-core.xml
  5. Use the filename for the repository configuration to recreate the repository:

    # createrepo -g ./repodata/3bbd98ef14e1e62734b8df6360825010001323218736-comps-ovs-core.xml ./
Adding Server Update Repositories in Oracle VM Manager

After you set up both Yum repositories, you must add them in the Oracle VM Manager Web Interface as server update repositories in the x86 server update group. The Oracle VM Manager Web Interface provides a Create Server Update Repository dialog where you specify details for both Yum repositories.

The following tables provide the information you need to create the server update repositories in the Oracle VM Manager Web Interface:

Table 5.2 Oracle VM Server 3.4 Transitional Update Repository

Field

Value

Notes

Name

3.4_trans_repo

By naming the repository in this way within Oracle VM Manager you are able to use the UpgradeServers.py script described in Section 5.5.1.2, “Running the UpgradeServers.py Script”. The name is case sensitive.

Repository Name

3.4_trans_repo

URL

http://example.com/repos/Transition

Substitute this URL with the URL to your repository.

Enabled

Yes

This repository must be enabled if you intend to use the UpgradeServers.py script described in Section 5.5.1.2, “Running the UpgradeServers.py Script”.

Package Signature Type

GPG or None

If you want to verify the validity of packages provided by the repositories, set the signature type to use a GPG key. Alternatively, use NONE if there is no verification required.

Package Signature Key

http://example.com/repos/RPM-GPG-KEY-oracle-ol5

If you opted to verify the validity of packages provided by the repository, provide the verification signature for the repository. Substitute this URL with the URL to the verification signature for the repository. Note that this should be the GPG key provided for the Oracle Linux 5 repository.


Table 5.3 Oracle VM Server 3.4 Update Repository

Field

Value

Notes

Name

3.4_ovs_repo

By naming the repository in this way within Oracle VM Manager you are able to use the UpgradeServers.py script described in Section 5.5.1.2, “Running the UpgradeServers.py Script”. The name is case sensitive.

Repository Name

3.4_ovs_repo

URL

http://example.com/repos/Server

Substitute this URL with the URL to your repository.

Enabled

Yes

This repository must be enabled if you intend to use the UpgradeServers.py script described in Section 5.5.1.2, “Running the UpgradeServers.py Script”.

Package Signature Type

GPG or None

If you want to verify the validity of packages provided by the repositories, set the signature type to use a GPG key. Alternatively, use NONE if there is no verification required.

Package Signature Key

http://example.com/repos/RPM-GPG-KEY-oracle

If you opted to verify the validity of packages provided by the repository, provide the verification signature for the repository. Substitute this URL with the URL to the verification signature for the repository. Note that this should be the GPG key provided for the Oracle Linux 6 repository.


For detailed instructions, see Create New Server Update Repository in the Oracle VM Manager User's Guide.

5.5.1.2 Running the UpgradeServers.py Script

To upgrade Oracle VM Server with the UpgradeServers.py script:

  • You must first upgrade Oracle VM Manager to Release 3.4.

  • Oracle VM Manager must be running. The upgrade script does not work if Oracle VM Manager is stopped.

  • The Oracle VM Server that you plan to upgrade must:

    • Be owned by the Oracle VM Manager from which you run the script.

    • Be running.

    • Be at Release 3.2.10 or Release 3.2.11.

    • Be on x86 hardware.

    • Cannot have any critical errors.

  • Virtual machines that are running must be able to migrate to an Oracle VM Server within the server pool during the upgrade, otherwise you must stop the virtual machines before performing the upgrade.

To run the script, do the following:

  1. Start an ssh session to the Oracle VM Manager host.

  2. Change to the following directory:

    /u01/app/oracle/ovm-manager-3/ovm_tools/bin/
  3. Run the script, specifying any appropriate parameters:

    $ ./UpgradeServers.py

When you run the script, maintenance mode operations occur to automatically migrate virtual machines between available servers. This ensures that Oracle VM Server can complete the upgrade process and restart with minimal downtime.

Syntax

UpgradeServers.py [ -h | --help | ? ] [ { --host-name | -H } host ] [ { -P | --port } port ] [ { -u | --user-name } user ] [ { -l | --pools } pool ] [ { -v | --servers } server ] [ { -L | --logfile } filepath ] [ --noprompt ]

Options

Using the UpgradeServers.py script with no options prompts you to enter the username and password for an instance of Oracle VM Manager on the localhost.

The following table shows the available options for this tool.

Option

Description

[ -h | --help | ? ]

Display the UpgradeServers.py command parameters and options.

{ --host-name | -H } host

Host name of the server running Oracle VM Manager. The default value is localhost.

This options is required only if you run the script on a system other than the Oracle VM Manager host.

{ -P | --port } port

Port number for the Oracle VM Manager instance. The default is 7002.

{ -u | --user-name } user

User to log into the Oracle VM Manager instance. You are prompted for the password.

{ -l | --pools } pool

Names or IDs of any server pools to upgrade. To specify multiple server pools, enter them in a comma separated list, with no spaces.

{ -v | --servers } server

Names or IDs of any Oracle VM Servers to upgrade. To specify multiple Oracle VM Servers, enter them in a comma separated list, with no spaces.

{ -L | --logfile } filepath

Location of the UpgradeServers.log to which the script writes.

The default path is the current working directory, or /tmp if the current directory is not writeable.

--noprompt

Do not prompt to continue the upgrade. If packages are missing, the upgrade exits immediately, see Non-native Packages. Otherwise, the upgrade continues without prompting.

Example 5.1 Upgrading Oracle VM Servers in a server pool

Upgrading all Oracle VM Servers in two server pools, named pool1 and pool2 and prompting for required options:

$ ./UpgradeServers.py -l pool1,pool2

Example 5.2 Upgrading Oracle VM Servers

Upgrading three Oracle VM Servers named server1, server2 and server3, and suppressing all prompts (except errors and the password prompt):

$ ./UpgradeServers.py -v server1,server2,server3 --noprompt

Example 5.3 Upgrading Oracle VM Servers on a remote Oracle VM Manager

Upgrading Oracle VM Servers on a remote host that has an Oracle VM Manager instance:

$ ./UpgradeServers.py -H ovmmanager.example.com -u admin -v server1,server2,server3

Non-native Packages

If you have installed any packages on any of your Oracle VM Servers after the initial Oracle VM Server installation (non-native packages), it is possible that the presence of those packages may cause the upgrade to fail. For the script to succeed, you must place new Oracle Linux 6 compatible versions of these non-native packages in the Oracle VM Server 3.4 Update Repository before starting the upgrade. See Creating the Yum Repositories for more information on updating non-native packages.

Before starting any Oracle VM Server upgrades, the upgrade script checks for non-native packages that may have been installed on any of the servers to be upgraded. The script also checks the 3.4_ovs_repo to determine whether any of these packages exist in that repository. To perform this check, the script makes use of a text file that enumerates the set of packages included in Oracle VM Server Release 3.2.10. The upgrade script compares the list of packages on the server to the appropriate version in this file to determine the list of non-native packages on the server. This file is located at:

/u01/app/oracle/ovm-manager-3/ovm_tools/etc/UpgradeServersYumPkgLists.txt

The script displays the status of all detected non-native packages:

timestamp INFO: Non-native package      Status in 3.4_ovs_repo
timestamp INFO: ------------------      -----------------------
timestamp INFO: osc-oracle-netapp       OK: package exists
timestamp INFO: osc-oracle-s7k          OK: package exists
timestamp INFO: python-ontapi           OK: package exists

If a non-native package is found that is not in the 3.4_ovs_repo, its status is described as MISSING, and you are prompted to fix the problem before proceeding with the upgrade. There are two approaches to dealing with a MISSING package:

  • Manually add an Oracle Linux 6 compatible version of the package to the repository as described in Creating the Yum Repositories if you intend to continue to use it in your upgraded environment.

  • On each Oracle VM Server where the package is currently installed, you can manually uninstall the package if it is not required in your upgraded environment, or if you intend to install an alternative after upgrade is complete.

Post-upgrade Storage Array Plug-in Reconciliation

After all Oracle VM Servers have been upgraded, it is possible that any non-generic Oracle VM Storage Connect plug-ins have also been updated to a newer version. In this situation, there may be a version mismatch in the configuration of the plug-in on any Oracle VM Server that is configured to use the storage array. This could result in errors whenever a storage array operation is performed since the expected plug-in version is no longer installed on any of the servers.

For this reason, when the upgrade is complete, the script checks the plug-ins for all storage arrays configured within Oracle VM Manager. If a plug-in is found within the Oracle VM Manager repository that no longer exists on any server that is configured for that storage array, the script attempts to determine whether a newer version of the same plug-in has been installed. If the script is able to find a newer version of the plug-in already installed on the servers, it automatically updates the configuration of the storage array to use the new plug-in.

Due to the way that this is handled, the storage array is only usable after the upgrade is complete, since the storage array's plug-in is not updated until all running servers using that plug-in have been upgraded.

Typical Output From the UpgradeServers.py Script

In the following example, the UpgradeServers.py script is used to update a single Oracle VM Server. The example shows typical output for the upgrade process, but you should be aware that output may vary depending on the parameters used when invoking the script:

$ cd /u01/app/oracle/ovm-manager-3/ovm_tools/bin/
$./UpgradeServers.py --noprompt -u admin -H localhost -v MyServer1
Enter your OVM Manager password:timestamp INFO:  
timestamp INFO:  UpgradeServers script starting...
timestamp INFO:  OVM Manager version: 3.4.x.y
timestamp INFO:  Command line args: ['UpgradeServers.py', '--noprompt', '-v',
  'MyServer1']
timestamp INFO:  
timestamp INFO:  Ensure the server(s) has at least 200MB of available space for the 
 /boot partition
 and 3GB of available space for the / partition.
timestamp INFO:
timestamp INFO:
Enter YES to continue with upgrade: yes
timestamp INFO:  Server: MyServer1. Transition Server Update Repository: 
  3.4_trans_repo, URL/path: http://myrepos.example.com/ovs_upgrade_repo/Transition
timestamp INFO:  Server: MyServer1. OVS Server Update Repository: 3.4_ovs_repo, 
  URL/path: http://myrepos.example.com/ovs_upgrade_repo/Server
timestamp INFO:  Getting update packages list in Server Update Repository: 
  3.4_ovs_repo, using oldest server: MyServer1, version: 3.2.9-xxx
timestamp INFO:  Disabling Server Update Repository: 3.4_trans_repo
timestamp INFO:  Waiting up to 35 seconds for updates of the Server Update 
  Repositories to complete on server MyServer1.
timestamp INFO:  Finished updating Server Update Repositories.
timestamp INFO:  Checking servers for non-native packages (those installed after 
  initial server installation)
timestamp INFO:  Non-native package status:

timestamp INFO:  Non-native package              Status in 3.4_ovs_repo
make timestamp INFO:  -----------------------------   ----------------------
timestamp INFO:  osc-oracle-netapp               OK: package exists
timestamp INFO:  osc-oracle-s7k                  OK: package exists
timestamp INFO:  python-ontapi                   OK: package exists

timestamp INFO:  Non-generic plug-ins have been found: [u'Oracle/Oracle NetApp 
  Filer Plugin'], that are in use on existing storage arrays.
timestamp INFO:  Evaluating server: MyServer1, version: 3.2.9-xxx, for 
  upgrading. [1 of 1 servers].
timestamp INFO:  Disabling Server Update Repository: 3.4_ovs_repo
timestamp INFO:  Enabling Server Update Repository: 3.4_trans_repo
timestamp INFO:  Waiting up to 35 seconds for updates of the Server 
  Update Repositories to complete on server MyServer1.
timestamp INFO:  Finished updating Server Update Repositories.
timestamp INFO:  Starting upgrade of server: MyServer1, type: X86_64, 
  version: 3.2.9-xxx, using Server Update Repository: 3.4_trans_repo
timestamp INFO:  No VMs are on server: MyServer1, starting server upgrade.
timestamp INFO:  Waiting for upgrade of server: MyServer1, to complete. 
  The server is running. [RUNNING]
timestamp INFO:  Server: MyServer1, upgraded successfully to version: 
  3.2.9-xxx (using Server Update Repository: 3.4_trans_repo).
timestamp INFO:  Disabling Server Update Repository: 3.4_trans_repo
timestamp INFO:  Enabling Server Update Repository: 3.4_ovs_repo
timestamp INFO:  Waiting up to 35 seconds for updates of the Server 
  Update Repositories to complete on server MyServer1.
timestamp INFO:  Finished updating Server Update Repositories.
timestamp INFO:  Starting upgrade of server: MyServer1, type: X86_64, 
  version: 3.2.9-xxx, using Server Update Repository: 3.4_ovs_repo
timestamp INFO:  No VMs are on server: MyServer1, starting server upgrade.
timestamp INFO:  Waiting for upgrade of server: MyServer1, to complete. 
  The server is performing the upgrade. [STOPPING]
timestamp INFO:  Waiting for upgrade of server: MyServer1, to complete. 
  The server is performing the upgrade. [STOPPING]
...
timestamp INFO:  Waiting for upgrade of server: MyServer1, to complete. 
  The server is rebooting after the upgrade. [STOPPED]
timestamp INFO:  Waiting for upgrade of server: MyServer1, to complete. 
  The server is rebooting after the upgrade. [STOPPED]
...
timestamp INFO:  Waiting for upgrade of server: MyServer1, to complete. 
  The server is starting back up. [STARTING]
timestamp INFO:  Server: MyServer1, upgraded successfully to version: 3.4.x-y 
   (using Server Update Repository: 3.4_ovs_repo).
timestamp INFO:  Evaluating if any storage arrays need their plug-ins updated.
timestamp INFO:  No plug-ins were found that needed updating.
timestamp INFO:  Log file is available at \
    /u01/app/oracle/ovm-manager-3/ovm_tools/bin/UpgradeServers.log
timestamp INFO:  UpgradeServers script stopping...

5.5.1.3 Removing the Transitional Yum Repository

When the server upgrade is complete, the transitional Yum repository is no longer required. Subsequent upgrades perform a check to determine if any transitional Yum repositories exist and then automatically disable them. However, it is best practice to disable or remove the transitional Yum repository when you successfully complete the Oracle VM Server upgrade process. For more information about adding, editing and deleting server update repositories, see Server Update Groups in the Oracle VM Manager User's Guide.

5.5.2 Reinstalling Oracle VM Server

To upgrade Oracle VM Server from Release 3.2.10, or a later version such as Release 3.2.11, to Release 3.4, you can reinstall Oracle VM Server.

Reinstall Oracle VM Server as follows:

  1. Migrate all virtual machines off the Oracle VM Server that you plan to upgrade. See Migrate or Move Virtual Machines in the Oracle VM Manager User's Guide.

  2. Unpresent all repositories from the Oracle VM Server. See Present or Unpresent Repository in the Oracle VM Manager User's Guide.

  3. Delete the Oracle VM Server from Oracle VM Manager. See Delete Server in the Oracle VM Manager User's Guide.

  4. Reinstall the Oracle VM Server with the Release 3.4 installation media. See Section 2.1.2, “Installing Oracle VM Server From a DVD-ROM”.

    Important
    • Reinstalling Oracle VM Server deletes all configuration settings.

    • When you start the Oracle VM Server installer, it detects the existing installation and prompts you to select between performing an upgrade or a new installation. If you are reinstalling from Release 3.2.10, you must perform a new installation. You cannot upgrade Oracle VM Server with the installation media if you are currently at Release 3.2.10.

  5. Discover the Oracle VM Server with Oracle VM Manager and add it to the appropriate server pool after the installation is complete. See Discover Servers in the Oracle VM Manager User's Guide.

  6. Re-configure the Oracle VM Server environment to restore the settings for networks, storage, repositories, and so on.

  7. Test the networking and storage connections of the Oracle VM Server that you reinstalled. You should confirm that failover redundancy and performance function correctly. You should also perform some testing on virtual machines and applications on the Oracle VM Server to ensure that they also function as expected. If you can confirm that the reinstalled Oracle VM Server is working correctly and no performance issues exist, you should then proceed with the incremental upgrade and verification of other Oracle VM Server instances.