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.
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.
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.
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.
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 theovm3_x86_64_3.4_transitionULN 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 theovm34_x86_64_latestULN channel.
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
Download the most recent Oracle VM Server installation ISO file.
Create a folder to mount the ISO file, for example:
# mkdir /tmp/ovs-mount
Mount the ISO file, for example:
# mount -o loop OVS-3.4.1.iso /tmp/ovs-mount
Create a directory for repository access using any appropriate HTTP server, for example:
# mkdir /var/www/repos
Copy the mounted ISO folder to the directory using
-rfor recursive and-pfor preserve, for example:# cp -rp /tmp/ovs-mount/* /var/www/repos/
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.xmlas follows:# wget http://example.com/repos/Server/repodata/repomd.xml # wget http://example.com/repos/Transition/repodata/repomd.xml
TipTemporarily 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_transitionContains the packages required to upgrade Oracle VM Server to a transitional state before upgrading to Release 3.4.
ovm34_x86_64_latestContains 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
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.
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:
Download the packages from the appropriate vendors.
Copy the packages into the
Server/Packagesdirectory in the Oracle VM Server 3.4 Update Repository, for example:# cp osc-sun7k.rpm /var/www/repos/Server/Packages/
Change directory so that you run the following commands from the root, for example:
# cd /var/www/repos/Server
Find the repository configuration file:
# find ./ -name "*comps-ovs-core.xml" ./repodata/3bbd98ef14e1e62734b8df6360825010001323218736-comps-ovs-core.xml
Use the filename for the repository configuration to recreate the repository:
# createrepo -g ./repodata/3bbd98ef14e1e62734b8df6360825010001323218736-comps-ovs-core.xml ./
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 |
| 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 |
| |
URL |
| 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
|
Package Signature Key |
| 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 |
| 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 |
| |
URL |
| 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
|
Package Signature Key |
| 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.
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:
Start an ssh session to the Oracle VM Manager host.
Change to the following directory:
/u01/app/oracle/ovm-manager-3/ovm_tools/bin/
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 |
|---|---|
[
| Display the UpgradeServers.py command parameters and options. |
{
|
Host name of the server running Oracle VM Manager. The default
value is This options is required only if you run the script on a system other than the Oracle VM Manager host. |
{
|
Port number for the Oracle VM Manager instance. The default is
|
{
| User to log into the Oracle VM Manager instance. You are prompted for the password. |
{
| Names or IDs of any server pools to upgrade. To specify multiple server pools, enter them in a comma separated list, with no spaces. |
{
| 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. |
{
|
Location of the
The default path is the current working directory, or
|
| 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
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:
timestampINFO: Non-native package Status in 3.4_ovs_repotimestampINFO: ------------------ -----------------------timestampINFO: osc-oracle-netapp OK: package existstimestampINFO: osc-oracle-s7k OK: package existstimestampINFO: 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.
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.
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:timestampINFO:timestampINFO: UpgradeServers script starting...timestampINFO: OVM Manager version: 3.4.x.ytimestampINFO: Command line args: ['UpgradeServers.py', '--noprompt', '-v', 'MyServer1']timestampINFO:timestampINFO: Ensure the server(s) has at least 200MB of available space for the /boot partition and 3GB of available space for the / partition.timestampINFO:timestampINFO: Enter YES to continue with upgrade: yestimestampINFO: Server: MyServer1. Transition Server Update Repository: 3.4_trans_repo, URL/path: http://myrepos.example.com/ovs_upgrade_repo/TransitiontimestampINFO: Server: MyServer1. OVS Server Update Repository: 3.4_ovs_repo, URL/path: http://myrepos.example.com/ovs_upgrade_repo/ServertimestampINFO: Getting update packages list in Server Update Repository: 3.4_ovs_repo, using oldest server: MyServer1, version: 3.2.9-xxxtimestampINFO: Disabling Server Update Repository: 3.4_trans_repotimestampINFO: Waiting up to 35 seconds for updates of the Server Update Repositories to complete on server MyServer1.timestampINFO: Finished updating Server Update Repositories.timestampINFO: Checking servers for non-native packages (those installed after initial server installation)timestampINFO: Non-native package status:timestampINFO: Non-native package Status in 3.4_ovs_repo maketimestampINFO: ----------------------------- ----------------------timestampINFO: osc-oracle-netapp OK: package existstimestampINFO: osc-oracle-s7k OK: package existstimestampINFO: python-ontapi OK: package existstimestampINFO: Non-generic plug-ins have been found: [u'Oracle/Oracle NetApp Filer Plugin'], that are in use on existing storage arrays.timestampINFO: Evaluating server: MyServer1, version: 3.2.9-xxx, for upgrading. [1 of 1 servers].timestampINFO: Disabling Server Update Repository: 3.4_ovs_repotimestampINFO: Enabling Server Update Repository: 3.4_trans_repotimestampINFO: Waiting up to 35 seconds for updates of the Server Update Repositories to complete on server MyServer1.timestampINFO: Finished updating Server Update Repositories.timestampINFO: Starting upgrade of server: MyServer1, type: X86_64, version: 3.2.9-xxx, using Server Update Repository: 3.4_trans_repotimestampINFO: No VMs are on server: MyServer1, starting server upgrade.timestampINFO: Waiting for upgrade of server: MyServer1, to complete. The server is running. [RUNNING]timestampINFO: Server: MyServer1, upgraded successfully to version: 3.2.9-xxx(using Server Update Repository: 3.4_trans_repo).timestampINFO: Disabling Server Update Repository: 3.4_trans_repotimestampINFO: Enabling Server Update Repository: 3.4_ovs_repotimestampINFO: Waiting up to 35 seconds for updates of the Server Update Repositories to complete on server MyServer1.timestampINFO: Finished updating Server Update Repositories.timestampINFO: Starting upgrade of server: MyServer1, type: X86_64, version: 3.2.9-xxx, using Server Update Repository: 3.4_ovs_repotimestampINFO: No VMs are on server: MyServer1, starting server upgrade.timestampINFO: Waiting for upgrade of server: MyServer1, to complete. The server is performing the upgrade. [STOPPING]timestampINFO: Waiting for upgrade of server: MyServer1, to complete. The server is performing the upgrade. [STOPPING] ...timestampINFO: Waiting for upgrade of server: MyServer1, to complete. The server is rebooting after the upgrade. [STOPPED]timestampINFO: Waiting for upgrade of server: MyServer1, to complete. The server is rebooting after the upgrade. [STOPPED] ...timestampINFO: Waiting for upgrade of server: MyServer1, to complete. The server is starting back up. [STARTING]timestampINFO: Server: MyServer1, upgraded successfully to version: 3.4.x-y(using Server Update Repository: 3.4_ovs_repo).timestampINFO: Evaluating if any storage arrays need their plug-ins updated.timestampINFO: No plug-ins were found that needed updating.timestampINFO: Log file is available at \ /u01/app/oracle/ovm-manager-3/ovm_tools/bin/UpgradeServers.logtimestampINFO: UpgradeServers script stopping...
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.
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:
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.
Unpresent all repositories from the Oracle VM Server. See Present or Unpresent Repository in the Oracle VM Manager User's Guide.
Delete the Oracle VM Server from Oracle VM Manager. See Delete Server in the Oracle VM Manager User's Guide.
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”.
ImportantReinstalling 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.
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.
Re-configure the Oracle VM Server environment to restore the settings for networks, storage, repositories, and so on.
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.