Oracle® VM Installation and Upgrade Guide for Release 3.4

5.1 Upgrade Overview

From a high level, the steps to upgrade Oracle VM are as follows:

Download the Oracle VM software from the Oracle Software Delivery Cloud and then extract the software to the component ISO files.
Prepare the Oracle VM environment for upgrade. For example, you must ensure that the Oracle VM Server you want to upgrade is at Release 3.2.10 or later, has the minimum partition sizes, and that the Oracle VM Agent is running.
Upgrade Oracle VM Manager as follows:
1. Mount the Oracle VM Manager ISO image file or burn and load the bootable physical media on the Oracle VM Manager host computer.
2. On the Oracle VM Manager host computer, run the runInstaller.sh script to upgrade Oracle VM Manager and select the Upgrade option.
Important
- You must upgrade Oracle VM Manager first and then upgrade each instance of Oracle VM Server that is managed by the upgraded Oracle VM Manager. Oracle does not support different versions of Oracle VM Server in a server pool. However, as of Oracle VM Release 3.4.2, you can have different versions of Oracle VM Server for different server pools. This is only possible if all instances of Oracle VM Server within each server pool are at the same release version. For example, Oracle VM Manager Release 3.4.2 can manage the following server pools:
  Server Pool A: consists of instances of Oracle VM Server at Release 3.2.11
  
  Server Pool B: consists of instances of Oracle VM Server at Release 3.3.4
  
  Server Pool C: consists of instances of Oracle VM Server at Release 3.4.2
  Although Oracle VM Manager supports current and previous Oracle VM Server releases, it is highly recommended that you upgrade all instances of Oracle VM Server to the latest release version to ensure that you have the latest supported operations and features. See the Oracle VM Release Notes for more information about Oracle VM Manager support for previous Oracle VM Server releases, as well as known issues and caveats that you should be aware of.
- Do not use Oracle VM Manager Release 3.4 to discover or interact with any instances of Oracle VM Server earlier than Release 3.2.10.
  
  If you discover an instance of Oracle VM Server that is earlier than Release 3.2.10 with Oracle VM Manager Release 3.4, an error message is returned for the job and conflicts occur between the databases that Oracle VM Manager requires for maintaining synchronization between internal components.

Upgrade Oracle VM Server using the appropriate steps for the platform, as follows:

Table 5.1 Oracle VM Server Upgrade Methods

Platform	Upgrade Path	Upgrade Method
x86	From Release 3.3.`x` Or Between Release 3.4.`x` Releases	Set up a Yum repository which retrieves updates from the Oracle VM 3.`x` channel on the Unbreakable Linux Network (ULN). You must have an Oracle Support contract to access ULN. From Oracle VM Manager, add the Yum repository as a server update repository. Update each Oracle VM Server from the Oracle VM Manager Web Interface. Tip For 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 Alternatively, you can upgrade Oracle VM Server as follows: Burn the Oracle VM Server ISO file to bootable physical media, such as a DVD-ROM. Upgrade each Oracle VM Server using the bootable physical media. Another method to upgrade Oracle VM Server is to reinstall using the Release 3.4 installation media, as follows: Remove the Oracle VM Server from the server pool and then delete the Oracle VM Server from Oracle VM Manager. Reinstall the Oracle VM Server using the Release 3.4 installation media. Discover the Oracle VM Server with Oracle VM Manager and add it back to the server pool after installation is complete.
x86	From Release 3.2.10 or a later version such as Release 3.2.11	Set up two Yum repositories: A transitional repository that contains the packages for Release 3.2 A target repository that contains the packages for Release 3.4. Run the UpgradeServers.py script on the Oracle VM Manager host to batch update servers as required. Alternatively, you can upgrade Oracle VM Server as follows: Remove the Oracle VM Server from the server pool and then delete the Oracle VM Server from Oracle VM Manager. Reinstall the Oracle VM Server using the Release 3.4 installation media. Discover the Oracle VM Server with Oracle VM Manager and add it back to the server pool after installation is complete.
SPARC	From Release 3.3.`x` Or Between 3.4.`x` Releases	Set up a Solaris IPS (Image Packaging System) repository to store the software packages used for the upgrade. The Oracle VM Server for SPARC packages are provided as part of the default Oracle Solaris installation packages. Download the Oracle VM Agent for SPARC software and manually transfer it to the IPS repository. Upgrade Oracle VM Server for SPARC or the Oracle VM Agent for SPARC using the Oracle VM Manager Web Interface or Oracle VM Manager Command Line Interface.
SPARC	From Release 3.2.10 or a later version such as Release 3.2.11	Upgrade to Oracle Solaris 11.3 or higher. Download the Oracle VM Agent for SPARC software. Upgrade the Oracle VM Agent for SPARC using the `update` script.

5.2 Preparing to Upgrade Oracle VM

The first step in the upgrade process is to prepare your Oracle VM environment. This task involves both understanding changes to Oracle VM in Release 3.4 and completing specific procedures before starting the upgrade process.

To ensure a successful upgrade, you should review this section carefully before you begin.

5.2.1 Checking Minimum System Requirements

You must ensure that your environment meets the minimum system requirements for both Oracle VM Manager and Oracle VM Server.

Review the minimum system requirements for Oracle VM Manager at Section 4.2.1, “Hardware Requirements”.

Note

If you increase the RAM available to your system, you should also increase the amount of swap space available. In general, you should set the swap space to an equivalent of the amount of physical RAM on your system if the amount of RAM exceeds 8 GB.
Review the minimum system requirements for Oracle VM Server.
- Oracle VM Server for x86, see Section 2.1.1.1, “Hardware Requirements”.
- Oracle VM Server for SPARC, see Section 2.2.1.1, “Hardware Requirements”.

5.2.2 Validating Oracle VM Server Version Compatibility

To upgrade Oracle VM, you must ensure that all instances of Oracle VM Server are at the minimum supported version for upgrade and are at the same minor version within each server pool.

You cannot upgrade Oracle VM if:

The Oracle VM Manager that you plan to upgrade manages an instance of Oracle VM Server earlier than Release 3.2.10. You can only upgrade to Release 3.4 if all Oracle VM Servers are at Release 3.2.10 or later, Release 3.3.x, or Release 3.4.x.

Important

Although Oracle VM Manager supports current and previous Oracle VM Server releases, it is highly recommended that you upgrade all instances of Oracle VM Server to the latest release version to ensure that you have the latest supported operations and features. See the Oracle VM Release Notes for more information about Oracle VM Manager support for previous Oracle VM Server releases, as well as known issues and caveats that you should be aware of.
There are different minor versions of Oracle VM Server within a server pool. Each instance of Oracle VM Server within a server pool must be the same minor version. For example, all servers in a server pool must be at Release 3.2.10, Release 3.3.x, or Release 3.4.x. A server pool cannot contain a server at Release 3.2.10 and a server at Release 3.3.x. In this case you must upgrade each server at Release 3.2.10 in the server pool to Release 3.3.x before you start upgrading the servers to Release 3.4.x.

Note

This applies to all servers within the Oracle VM model, even if the servers are not running. If your environment contains servers with different minor versions that are not running, you should delete them if you do not plan to start them again in future.

As a pre-upgrade validation, you receive a warning message if:

The Unassigned Servers folder contains servers with different minor versions.
If any instances of Oracle VM Server within the Oracle VM model have different minor versions.

Note

You also receive a warning message if any virtual machines have the HugePages feature enabled. This feature is deprecated in Oracle VM Release 3.4.1 and will be removed in a future release of Oracle VM. See the Oracle VM Release Notes for more information.

If you have HugePages enabled for any PVM guests, Oracle recommends that you change the domain type for virtual machines from Paravirtualized (PVM) to Hardware virtualized, with paravirtualized drivers (PVHVM). If you cannot change the domain type for a virtual machine, you should disable the HugePages setting and then restart the virtual machine.

5.2.3 Preparing to Upgrade Oracle VM Manager

Before you upgrade Oracle VM Manager, you must do the following:

Review the README file and the Oracle VM Release Notes for any specific issues relating to the Oracle VM Manager release version that you are upgrading to.

Note

If you are running a version
Ensure that no other Linux users have access to the Oracle VM Manager host and that any monitoring services are disabled for the duration of the upgrade.
If necessary, set the umask default on Oracle VM Manager to 0022 before you begin the upgrade process. If umask is set to another value, it can cause the upgrade process to end unexpectedly.

Before you upgrade Oracle VM Manager, you should do the following:

Perform a full backup of your Oracle VM Manager database and configuration file before you attempt to upgrade Oracle VM Manager. See Backing up the Oracle VM Manager Configuration File for information.

Caution

Database backups from an earlier 3.4.x release (for example 3.4.4) cannot be used in a later Oracle VM Manager deployment (for example 3.4.5) due to database schema changes.

Note

If necessary, set the location for storing backups of the local MySQL database for Oracle VM Manager to the default path before you attempt to upgrade Oracle VM Manager. Ensure that the default path is configured until the upgrade completes successfully. See Backing up the MySQL Database Repository for information on default paths and procedures.
Make sure there are no database corruptions, as those would cause the upgrade to fail.

If the database has been corrupted, the Oracle VM Manager backup cannot complete. As a consequence, failed jobs occur in the event log, and no new files appear in the backup directory.
Remove temporary files no longer required. For example, run the following command as the root user on the Oracle VM Manager host before you upgrade:
```
# rm -Rf /tmp/workdir_sel
# rm -Rf /tmp/ovm* 
```
When you start the upgrade process, you should ensure that no jobs are in progress or are started using the Oracle VM Manager Web Interface, the Oracle VM Manager Command Line Interface or the Oracle VM Web Services API. If a job starts while the upgrade is in progress, the upgrade might abort. In this case, you must wait for all jobs to complete and then restart the upgrade.

Note

When upgrading from Oracle VM Manager Release 3.2.10, the upgrade process deletes any existing job or event history. This step is required because the job and event models are changed in Release 3.4.x to improve performance. If your Oracle VM Manager Release 3.2.10 environment has large job and event histories, you should take this into account when planning your upgrade. It might take several day to complete an upgrade for a very large deployment that includes numerous servers and virtual machines.

5.2.4 Preparing to Upgrade Oracle VM Server

Before you upgrade Oracle VM Server, you must:

Review the README file and the Oracle VM Release Notes for any specific issues relating to the Oracle VM Server release version that you are upgrading to.
Ensure that all servers in the server pool that you plan to upgrade are at the same minor version.
Ensure that there is sufficient capacity within the server pool to perform virtual machine migrations.

A general guideline is to identify which server in the pool has the most resources available. You should then ensure that there is another server with the same configuration. If necessary, you should add another server to the pool.
Upgrade the Oracle VM Manager which manages them. See Section 5.4, “Upgrading Oracle VM Manager” for information on upgrading Oracle VM Manager.

You should also review the following important points:

Important

Oracle does not support different versions of Oracle VM Server in a server pool. However, as of Oracle VM Release 3.4.2, you can have different versions of Oracle VM Server for different server pools. This is only possible if all instances of Oracle VM Server within each server pool are at the same release version. For example, Oracle VM Manager Release 3.4.2 can manage the following server pools:
- Server Pool A: consists of instances of Oracle VM Server at Release 3.2.11
- Server Pool B: consists of instances of Oracle VM Server at Release 3.3.4
- Server Pool C: consists of instances of Oracle VM Server at Release 3.4.2
Although Oracle VM Manager supports current and previous Oracle VM Server releases, it is highly recommended that you upgrade all instances of Oracle VM Server to the latest release version to ensure that you have the latest supported operations and features. See the Oracle VM Release Notes for more information about Oracle VM Manager support for previous Oracle VM Server releases, as well as known issues and caveats that you should be aware of.
When upgrading Oracle VM Server, you can add an instance of Oracle VM Server to a server pool only if that instance is at the same version or later than the servers in that server pool. For example, if a server pool contains several servers at Release 3.3.x, you can add a server at either Release 3.3.x or at Release 3.4.x. If a server pool contains several servers at Release 3.4.x, you can add a server at Release 3.4.x only. In all cases, however, Oracle recommends that you add servers at Release 3.4.x.

5.2.4.1 Increasing Partition Sizes for Oracle VM Server

As a best practice, you should provision as much disk space as possible to Oracle VM Server. In future you will upgrade your environment between errata releases and new versions. Over time these operations consume disk space. While it is possible to remove unnecessary files and clean up disk space and resize partitions, you should plan to minimize disruption and avoid issues by allocating two or three times the minimum required disk space, where possible.

For Oracle VM Server Release 3.2.10, or later versions such as Release 3.2.11, the default disk partition sizes are 100MB for /boot and 3GB for the root partition, /. These default partition sizes are not adequate to upgrade Oracle VM Server to Release 3.4.

To upgrade Oracle VM Server from Release 3.2.10 you should increase the partition sizes to the following, at a minimum:

500MB for the /boot partition.
5GB for the root partition, /.

To upgrade Oracle VM Server from 3.3.x, you should also increase the partition sizes if you upgraded from Oracle VM Server Release 3.2.x and kept those default partition sizes.

You can do one of the following to ensure that Oracle VM Server has sufficient disk space:

Resize the partitions before upgrading Oracle VM Server, if there is disk space available.

You can use any appropriate partition editor software to resize the partitions. However, Oracle provides an Oracle VM Server disk resizing utility, which you can download with patch ID 23189880 at: https://updates.oracle.com/Orion/PatchDetails/process_form?patch_num=23189880

Note

Before upgrading, you must remove the Oracle VM Server disk resizing utility once the partitions are resized.
Reinstall Oracle VM Server with the Release 3.4 installation media, as follows:
1. Upgrade Oracle VM Manager to Release 3.4.
2. Migrate all virtual machines off the Oracle VM Server that you plan to upgrade.
3. Unpresent all repositories from the Oracle VM Server.
4. Delete the Oracle VM Server from Oracle VM Manager.
5. Reinstall the Oracle VM Server with the Release 3.4 installation media.
  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.
6. Discover the Oracle VM Server with Oracle VM Manager and add it to the appropriate server pool after the installation is complete.
7. Re-configure the Oracle VM Server environment to restore the settings for networks, storage, repositories, and so on.

5.2.4.2 Checking the Oracle VM Agent Notification Service

You should ensure that the Oracle VM Agent notification service is working on each instance of Oracle VM Server that you plan to upgrade. Do the following:

Start an ssh session to Oracle VM Server.

Search /var/log/ovs-agent.log for messages such as the following:

ERROR (notification:44) Unable to send notification: (111, 'Connection refused')

If those messages exist in the log file, the notification service is not working and the Oracle VM Agent cannot send notifications to Oracle VM Manager.

To resolve this error, you should restart the Oracle VM Agent service on Oracle VM Server. Alternatively, you can retake ownership of the Oracle VM Server from Oracle VM Manager.
```
#service ovs-agent restart
```

5.3 Downloading the Upgrade Software

Before you begin the Oracle VM upgrade, download the Oracle VM software from the Oracle Software Delivery Cloud at:

http://edelivery.oracle.com/oraclevm

More information on obtaining the software is covered in Section 1.2, “Getting Installation ISOs and Packages”.

If you have an Oracle Support contract, you can also download Oracle VM patch updates from the My Oracle Support web site at:

https://support.oracle.com

5.4 Upgrading Oracle VM Manager

This section describes procedures for upgrading Oracle VM Manager.

5.4.1 Running the Script to Upgrade Oracle VM Manager

The runInstaller.sh script included on the Oracle VM Manager installation ISO includes an option that allows you to perform an upgrade of a previous version of Oracle VM Manager.

# ./runInstaller.sh

Oracle VM Manager Release 3.4.x Installer

Oracle VM Manager Installer log file:
/tmp/ovm-manager-3-install-yyyy-mm-dd-xxxxxx.log

Please select an installation type:
   1: Install
   2: Upgrade
   3: Uninstall
   4: Help

   Select Number (1-4): 2

Verifying upgrading prerequisites ...
*** WARNING: Ensure that each Oracle VM Server for x86 has at least 200MB of available space for the /boot partition and 3GB of available space for the / partition.
Starting Upgrade ...

Reading database parameters from config ...

It is also possible to trigger the upgrade process by passing the correct installtype parameter on the command line:

# ./runInstaller.sh --installtype Upgrade

If you do not have both the zip and unzip packages installed on the system that you are upgrading, the installer exits with an error notifying you to install these packages before proceeding with the upgrade.

You are prompted to provide the passwords for each component during the upgrade procedure. You must enter the password you set for that component during the original installation, or the current password if it has been changed since installation.

A log of the upgrade is available in the /var/log/ovmm/ovm-manager-3-install-date-id.log file.

Important

After you successfully upgrade Oracle VM Manager to Release 3.4, you must not discover or interact with any instances of Oracle VM Server earlier than Release 3.2.10.

If you discover an instance of Oracle VM Server that is earlier than Release 3.2.10 with Oracle VM Manager Release 3.4, an error message is returned for the job and conflicts occur between the databases that Oracle VM Manager requires for maintaining synchronization between internal components.

To upgrade Oracle VM Manager:

Log in to the Oracle VM Manager host computer as the root user.
Oracle VM Manager must be running to perform the upgrade. If Oracle VM Manager is not running, start it. On Linux:
```
# service ovmm start
```
If Oracle VM Manager is not running when you run the installation script, an error is returned by the script and the installer exits.
Mount the Oracle VM Manager ISO file or create bootable physical media. See either Section 1.3, “Installation From Bootable Physical Media” or Section 1.4, “Loopback ISO Mounts” for more information.

Start the Oracle VM Manager installation script, for example:

# cd /mnt
# ./runInstaller.sh

The installer starts and presents you with a variety of options:

Oracle VM Manager Release 3.4.x Installer

Oracle VM Manager Installer log file:
/var/log/ovmm/ovm-manager-3-install-yyyy-mm-dd-xxxxxx.log

Please select an installation type:
   1: Install
   2: Upgrade
   3: Uninstall
   4: Help

   Select Number (1-4): 2
Verifying upgrading prerequisites ...
*** WARNING: Ensure that each Oracle VM Server for x86 has at least 200MB of available space for the /boot partition and 3GB of available space for the / partition.
Starting Upgrade ...

Reading database parameters from config ...

Enter the menu number for the Upgrade option and press Enter to continue with the upgrade. You are prompted for the password that must be used to access the current Oracle VM Manager database:

Typically the current Oracle VM Manager database password will be the same as the 
Oracle VM Manager application password.

Database Repository
==========================
Please enter current Oracle VM Manager database password for user ovs:

Enter the password that should be used to access the database for the ovs user. If you set a system-wide password during the original installation and have not changed the database password at any stage, this password should be used here. This password continues to be used for the database after the upgrade is complete. If you enter this password incorrectly and the installer is unable to access the database, the installer exits with an error message.

The installer prompts you for the current Oracle VM Manager password. This is the same password that you use to log into the Oracle VM Manager Web Interface, using the admin username.

Oracle VM Manager application
=============================
Please enter current Oracle VM Manager application password for user admin:

Enter the password. If you set a system-wide password during the original installation and have not changed the admin user password at any stage, this password should be used here. This password continues to function after the upgrade. If you intend to change it, you must do so after the upgrade is complete.

The installer prompts you to enter the Oracle WebLogic Server password.

Oracle WebLogic Server 12c
==========================
Please enter the current password for the WebLogic domain administrator:

You are prompted for the system's FQDN (fully qualified domain name) or IP address to use during the generation of the SSL certificate that should be used for HTTPS connections to Oracle VM Manager:

Please enter your fully qualified domain name, e.g. ovs123.us.oracle.com, 
(or IP address) of your management server for SSL certification 
generation 192.168.0.254 [192.168.0.254]: manager.example.com

It is important that you specify the hostname, fully qualified domain name or the IP address that is to be used when accessing the Oracle VM Manager Web Interface, so that the SSL certificate hostname matches the hostname portion of the URL entered into the web browser.

The installer completes verification checks to see if the Oracle VM Manager database passwords for the root and appfw users match the database password for the user ovs. If either of these user passwords differ, the upgrade tool displays a password verification failure message for the user and then prompts you to enter the current Oracle VM Manager database password for the required user. For example, as follows for the user root:

Password verification for the user root failed
Please enter the current Oracle VM Manager database password for the user root:

The installer then verifies that the password entered matches the current database password for the user and displays a successful password verification message. For example, as follows for the user root:

Successfully verified password for user root

The installer displays the current release number and the release number to which Oracle VM Manager is to be upgraded, and presents a final option to exit from the upgrade process:

Verifying configuration ...
Verifying 3.x.y.z meets the minimum version for upgrade ...

Upgrading from version 3.x.y.z to version 3.4.v.w

Start installing the configured components:
   1: Continue
   2: Abort

   Select Number (1-2): 1

Select the Continue option to continue with the upgrade process.

Running full database backup ...
Successfully backed up database to /u01/app/oracle/mysql/dbbackup/3.x.y_preUpgradeBackup-
yyyymmdd_xxxxxx

The upgrade process automatically ensures that the database for the current installation is fully backed up prior to starting the upgrade. This ensures that you are able to roll back to the version that you currently have installed if something fails during the upgrade process. This backup file is located in /u01/app/oracle/mysql/dbbackup/.

A pre-upgrade script runs prior to the actual upgrade process to prepare the environment for upgrade. If you are upgrading from Oracle VM Manager Release 3.2.10, this script removes any existing job history. This process can take quite some time, depending on the number of jobs in the job history. The pre-upgrade process provides output that indicates the number of jobs that must be deleted at different stages of its progress so that you can monitor its status:

Running ovm_preUpgrade script, please be patient this may take a long time ...
 

timestamp: Deleting 4163 Jobs before upgrade.
timestamp: 200 Jobs have been deleted. 3963 Jobs remaining.
timestamp: 400 Jobs have been deleted. 3763 Jobs remaining.
timestamp: 600 Jobs have been deleted. 3563 Jobs remaining.
timestamp: 800 Jobs have been deleted. 3363 Jobs remaining.
...
timestamp: 3800 Jobs have been deleted. 363 Jobs remaining.
timestamp: 4000 Jobs have been deleted. 163 Jobs remaining.
timestamp: Jobs have been deleted.

Regardless of the release that you are upgrading from, the pre-upgrade script also checks for any jobs that are still running. In the case that it discovers jobs that are running, it prints the details of these jobs to the screen and provides the option to force quit and delete these jobs, or to abort the upgrade:

timestamp ERROR: Job test1 is in the 
CONSTRUCTING state and was created on timestamp
Would you like to delete the jobs above? Saying no will cancel the upgrade:
   1: Yes
   2: No

If you press 2 here, the upgrade process aborts and exits immediately. If you press 1 here, any running jobs are quit and deleted and the following output is displayed:

timestamp ERROR: Job test1 is in the 
CONSTRUCTING state and was created on timestamp
timestamp:  1  jobs have been deleted.

The rest of the upgrade process is automated and continues as follows:

Exporting weblogic embedded LDAP users
Stopping service on Linux: ovmcli ...
Stopping service on Linux: ovmm ...
Exporting core database, please be patient this may take a long time ... 
NOTE: To monitor progress, open another terminal session and run: 
tail -f /var/log/ovmm/ovm-manager-3-install-YYYY-MM-DD-HHmmss.log 

Product component : Java in '/u01/app/oracle/java'
Java is installed ...

Removing Java installation ...

Installing Java ...

DB component : MySQL RPM package
MySQL RPM package installed by OVMM was found...
Removing MySQL RPM package installation ...

Installing Database Software...
Retrieving MySQL Database 5.6 ...
Unzipping MySQL RPM File ...
Installing MySQL 5.6 RPM package ...
Configuring MySQL Database 5.6 ...
Installing MySQL backup RPM package ...

Product component : Oracle VM Manager in '/u01/app/oracle/ovm-manager-3/'
Oracle VM Manager is installed ...
Removing Oracle VM Manager installation ...

Product component : Oracle WebLogic Server in '/u01/app/oracle/Middleware/'
Oracle WebLogic Server is installed

Removing Oracle WebLogic Server installation ...
Service ovmm is deleted.
Service ovmcli is deleted.

Retrieving Oracle WebLogic Server 12c and ADF ...
Installing Oracle WebLogic Server 12c and ADF ...
Applying patches to Weblogic ...
Applying patches to ADF ...

Installing Oracle VM Manager Core ...
Retrieving Oracle VM Manager Application ...
Extracting Oracle VM Manager Application ...

Retrieving Oracle VM Manager Upgrade tool ...
Extracting Oracle VM Manager Upgrade tool ...
Installing Oracle VM Manager Upgrade tool ...
Installing Oracle VM Manager WLST Scripts ...

Dropping the old database user 'appfw' ...
Dropping the old database 'appfw' ...
Creating new domain...
Creating new domain done.
Upgrading core database, please be patient this may take a long time ...
NOTE: To monitor progress, open another terminal session and run: 
tail -f /var/log/ovmm/ovm-manager-3-install-YYYY-MM-DD-HHmmss.log
Starting restore domain's SSL configuration and create appfw database tables.
Restore domain's SSL configuration and create appfw database tables done.
AdminServer started.
Importing weblogic embedded LDAP users

Retrieving Oracle VM Manager CLI tool ...
Extracting Oracle VM Manager CLI tool...
Installing Oracle VM Manager CLI tool ...

Configuring Https Identity and Trust...
Deploying Oracle VM Manager Core container ...
Configuring Client Cert Login...
Deploying Oracle VM Manager UI Console ...
Deploying Oracle VM Manager Help ...
Disabling HTTP access...

Retrieving Oracle VM Manager Shell & API ...
Extracting Oracle VM Manager Shell & API ...
Installing Oracle VM Manager Shell & API ...

Retrieving Oracle VM Manager Wsh tool ...
Extracting Oracle VM Manager Wsh tool ...
Installing Oracle VM Manager Wsh tool ...

Retrieving Oracle VM Manager Tools ...
Extracting Oracle VM Manager Tools ...
Installing Oracle VM Manager Tools ...
Copying Oracle VM Manager shell to '/usr/bin/ovm_shell.sh' ...
Installing ovm_admin.sh in '/u01/app/oracle/ovm-manager-3/bin' ...
Installing ovm_upgrade.sh in '/u01/app/oracle/ovm-manager-3/bin' ...

Enabling Oracle VM Manager service ...
Shutting down Oracle VM Manager instance ...
Starting Oracle VM Manager instance ...
Waiting for the application to initialize ...
Oracle VM Manager is running ...

Please wait while WebLogic configures the applications...

Installation Summary
--------------------
Database configuration:
  Database type               : MySQL
  Database host name          : localhost
  Database name               : ovs
  Database listener port      : 49501
  Database user               : ovs

Oracle WebLogic Server configuration:
  Administration username     : weblogic

Oracle VM Manager configuration:
  Username                    : admin
  Core management port        : 54321
  UUID                        : UUID


Passwords:
There are no default passwords for any users. The passwords to use for Oracle VM Manager, 
Database, and Oracle WebLogic Server have been set by you during this installation. In the 
case of a default install, all passwords are the same.

Oracle VM Manager UI:
  https://manager.example.com:7002/ovm/console
Log in with the user 'admin', and the password you set during the installation.

For more information about Oracle Virtualization, please visit:
  http://www.oracle.com/virtualization/

As of Oracle VM Release 3.4.5, the TLSv1.2 protocol is used for all connections and management of 
3.2.10/11 servers is not possible by default. TLSv1 protocol must be enabled, which is less secure.
For instructions, see the Oracle VM 3.4 Installation and Upgrade guide.

Oracle VM Manager upgrade complete.

Please remove configuration file /tmp/ovm_configxyz.

5.4.2 Removing Temporary Files After Upgrade

If you have upgraded from a release prior to 3.4, you must remove the temporary files that are created as part of the upgrade process. These files can be used by Oracle Support to help you recover your environment if something goes wrong with your upgrade and you did not take adequate steps to backup your database before the upgrade. However, they also contain information about your entire environment that should not be left in temporary file space indefinitely.

It is important that you verify that your upgrade has completed successfully and that Oracle VM Manager is fully functional before you remove these temporary files. Log into the Oracle VM Manager Web Interface and check that your environment is configured as it was prior to upgrade. Check that you are able to perform actions on your Oracle VM Servers and storage via the Oracle VM Manager Web Interface. If your environment is functional, you can proceed with the removal of the temporary files generated by the upgrade.

To remove temporary files after upgrade, do the following as the root user on the Oracle VM Manager host:

# rm -Rf /tmp/workdir_sel*
# rm -Rf /tmp/ovm*

On many systems, temporary files are deleted automatically on reboot. If you have any concern about security after an upgrade, in most cases a system reboot ensures that these files are cleaned up properly.

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

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 -r for recursive and -p for 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.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:

Download the packages from the appropriate vendors.
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/
```
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 ./

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:

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
[ `-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:

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”.
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.
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.

5.6 Upgrading Oracle VM Server for x86 from Release 3.3.`x` or Between 3.4.`x` Errata Releases

To upgrade Oracle VM Server from Release 3.3.x or from one Release 3.4.x to another Release 3.4.y, you can:

Configure a server update repository and use the Oracle VM Manager Web Interface. This upgrade method is recommended and allows you to upgrade multiple Oracle VM Servers.
Create a bootable disc from the Oracle VM Server ISO file and perform the upgrade. You should use this upgrade method only if it is not possible to perform the upgrade from Oracle VM Manager.
Reinstall Oracle VM Server.

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”.

5.6.1 Upgrading Oracle VM Server Through Oracle VM Manager

Upgrading Oracle VM Server through Oracle VM Manager requires you to set up a Yum repository that:

Mirrors the contents of the ovm34_x86_64_latest ULN channel. This ULN channel contains the packages required to upgrade Oracle VM Server to Release 3.4.

As an alternative to mirroring the ULN channel, you can make the Oracle VM Server installation media available over the network.
Can contain additional packages such as third-party Oracle VM Storage Connect plug-ins.

After you set up a Yum repository, you add it as a server update repository in Oracle VM Manager. You can then upgrade each Oracle VM Server through Oracle VM Manager.

5.6.1.1 Creating the Yum Repository

You must create the Yum repository on a system that is accessible through HTTP or HTTPS.

You must create the Yum repository either by creating a mirror of the ULN channel or by copying the content of the Oracle VM Server installation media, as follows:

Creating a mirror of the ULN channel

Set up your Yum repository to mirror the following ULN channel: ovm34_x86_64_latest

The ovm34_x86_64_latest ULN channel 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

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 -r for recursive and -p for preserve, for example:
```
# cp -rp /tmp/ovs-mount/* /var/www/repos/
```
Check that the repository is accessible. You should access the repository on a different system, such as an instance of Oracle VM Server. To ensure the repository is accessible, download a small file such as repomd.xml as follows:
```
# wget http://example.com/repos/Server/repodata/repomd.xml
```

Tip

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

# cd /var/www
# python -m SimpleHTTPServer 80

5.6.1.2 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.

Tip

If you are upgrading an Oracle VM Server that has unsigned packages installed, you should create a separate Yum repository where these packages can be hosted. When you add the repository to Oracle VM Manager as a server update repository you must ensure that the Package Signature Type option is set to None for this repository. This prevents an upgrade from failing due to unsigned packages that are not part of the base Oracle VM Server installation repository.

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

Download the packages from the appropriate vendors.
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/
```
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 ./

5.6.1.3 Adding Server Update Repositories in Oracle VM Manager

After you set up the Yum repository, you must add it in the Oracle VM Manager Web Interface.

Log in to the Oracle VM Manager Web Interface.
Either create a global server update group or a server update group for a specific server pool, as follows:
Creating a global server update group
Select the Reports and Resources tab.

Select the Server Update Groups subtab.

Expand the Server Update Groups folder and then select GlobalX86ServerUpdateConfiguration.

Expand the Server Update Groups folder, select GlobalX86ServerUpdateConfiguration, and then select Create New Server Update Repository.

Create the server update group as described in Table 5.4, “Oracle VM Server 3.4 Update Repository”.
Creating a server update group for a specific server pool
Select the Servers and VMs tab.

Expand the Server Pools folder and then select an appropriate server pool.

Edit the server pool and select the Override Global Server Update Group option and then select OK.

Select the Server Update Repositories perspective and then select Create New Server Update Repository.

Create the server update group as described Table 5.4, “Oracle VM Server 3.4 Update Repository”.

The following table describes the fields you need to specify to create a server update repository:

Table 5.4 Oracle VM Server 3.4 Update Repository

Field	Value	Notes
Name	`3.4_ovs_repo`	Specify a meaningful name for the server update configuration.
Repository Name	`3.4_ovs_repo`	Specify a meaningful name for the server update repository.
URL	`http://example.com/repos/Server`	Substitute this URL with the URL to your repository.
Enabled	Yes	This repository must be enabled.
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 more information, see the following topics in the Oracle VM Manager User's Guide:

5.6.1.4 Upgrading Servers from Oracle VM Manager

After you set up the Yum repositories with the content to upgrade Oracle VM Server to Release 3.4 and create the server update repository, you can perform the upgrade from the Oracle VM Manager Web Interface, as follows:

Log in to the Oracle VM Manager Web Interface.
Select the Servers and VMs tab.
Expand the Server Pools folder and then select an appropriate server pool.
Select the Servers perspective.

The Update Required column in the Servers perspective indicates if an update is available for each server within the server pool.
Select each instance of Oracle VM Server that you want to update and then select Update Server.
Click OK when prompted to confirm the server upgrade.

Each Oracle VM Server is placed into maintenance mode and then upgraded. Any virtual machines running on an instance of Oracle VM Server are automatically migrated to another Oracle VM Server when it is put into maintenance mode. When the update is complete the Oracle VM Server is restarted and remains in maintenance mode.

Note

In certain cases, the automatic virtual machine migration may fail when the Oracle VM Server is placed into maintenance mode. For more information on the maintenance mode, see Edit Server.
Edit each instance of Oracle VM Server to take it out of maintenance mode when the upgrade is complete.

5.6.2 Upgrading Oracle VM Server Using the ISO File

To upgrade the Oracle VM Server using the Oracle VM Server ISO file:

Burn the Oracle VM Server ISO file to a bootable disc.
Start the Oracle VM Server installer. The installer initially prompts you to test the installation media, configure the language and keyboard settings, and accept the EULA.

For more information about starting the installer and the initial installation screens, see Section 2.1.2, “Installing Oracle VM Server From a DVD-ROM”.
Proceed through the initial installation screens. When the installer detects the existing Oracle VM Server installation, the System to Upgrade screen displays.

System to Upgrade

On the System to Upgrade screen, do the following:

Select Oracle VM Server 3.x (disk) to upgrade the existing installation.

Select OK and press Enter.

Upgrade Boot Loader Configuration

On the Upgrade Boot Loader Configuration screen, do the following:

Select one of the following:
- Update boot loader configuration to update the existing boot loader.
- Skip boot loader updating to make no changes to the boot loader and maintain your current configuration settings.
  
  Note
  
  If kdump settings were manually defined in the GRUB configuration before the upgrade, selecting this option ensures that these configuration settings are maintained after the upgrade.
Select OK and press Enter.

Package Installation and Finishing the Upgrade

After you specify the options for the Oracle VM Server upgrade, the installer performs a dependency check and then begins the upgrade process. A progress bar displays the status of the package installation. The Finishing upgrade screen then displays.

When the upgrade is finished, the Complete screen displays. Do the following to complete the upgrade:

Remove the Oracle VM Server installation disc from the drive.
Select Reboot.

After Oracle VM Server reboots, the console displays.

The Oracle VM Server upgrade is complete.

A log of the install is located in /root/upgrade.log. If the upgrade is not successful, review this log file to identify any issues.

5.6.3 Reinstalling Oracle VM Server

To upgrade Oracle VM Server from Release 3.3.x to Release 3.4, you can reinstall Oracle VM Server.

Important

Reinstalling Oracle VM Server deletes all configuration settings.

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”.
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.

5.7 Finalizing Upgrades on Oracle VM Server for x86

This section describes different post-upgrade steps that may be required after an upgrade.

5.7.1 Refreshing Server Pools To Validate Oracle VM Storage Connect plug-in

After an upgrade, it is good practice to refresh your server pools to ensure that the information presented within Oracle VM Manager is up to date and synchronized with the actual state of any servers in a server pool. More importantly, if you are using any third party Oracle VM Storage Connect plug-in for your storage devices, you may be unable to refresh your storage arrays until these plug-ins have been validated. Refreshing server pools allows the servers that have been presented to the storage to validate the Oracle VM Storage Connect plug-in that they are using. Once this has been done, operations on storage arrays can resume normally.

To refresh your server pools, refer to Refresh All in the Oracle VM Manager User's Guide.

5.7.2 Editing Boot Parameters To Enable Hypervisor Features

If you have upgraded from an earlier release, it is possible that some of the hypervisor boot parameters for your server may need editing to ensure that newer features are enabled. To update these boot parameters, on each affected Oracle VM Server, open the grub configuration in an editor. If you are using UEFI boot, the grub configuration file is located at /boot/efi/EFI/redhat/grub.cfg, otherwise the grub configuration file is located at /boot/grub2/grub.cfg. Edit the line starting with multiboot2 /xen.mb.efi and append the required boot parameters.

For large servers with more than 20 physical CPUs

For Oracle VM Servers with more than 20 physical CPUs, performance can be improved by pinning virtual CPUs to dom0 and setting a maximum value for the number of virtual CPUs that can be used by dom0. On a new install where a system has more than 20 physical CPUs, this value is usually set to 20. To ensure that you get the best possible performance on an Oracle VM Server with more than 20 physical CPUs, set the Xen boot parameters dom0_vcpus_pin and dom0_max_vcpus=20. For example:

multiboot2 /xen.mb.efi dom0_mem=max:6144M  dom0_vcpus_pin \
  dom0_max_vcpus=20 placeholder ${xen_rm_opts}

Note

Some versions of the Xen 4.4.4 kernel require that you set the dom0_vcpus_pin parameter to dom0_vcpus_pin=true for the configuration to take effect. Run the following command on Oracle VM Server to find the Xen version: rpm -qa | grep xen.

If you have previously updated the Xen boot parameters on an earlier Oracle VM 3.4.x release, and then upgraded to Oracle VM Release 3.4.5 or later with Xen kernel version 4.4.4-130 or higher, either syntax for the parameter is accepted.

The standard syntax as of Oracle VM Release 3.4.5 is dom0_vcpus_pin; there is no need to append =true.

For Oracle VM Servers with fewer than 20 physical CPUs, you should ensure that the number of virtual CPUs specified is reduced accordingly and does not exceed the number of physical CPUs per socket. Assigning too many virtual CPUs can cause Non-Uniform Memory Access (NUMA) latency issues if the virtual CPUs are spread across sockets. For example, if an instance of Oracle VM Server with hyper-threading enabled has 2 sockets with 18 cores per socket and 2 CPU threads per core, this results in a total of 36 physical CPUs. In this case, it is correct to set dom0_max_vcpus to 20. However, with hyper-threading disabled, only 18 physical CPUs are on each socket and as a result, you should set the dom0_max_vcpus parameter to 18.

When you have finished modifying the grub configuration file, for example, /etc/default/grub, you must rebuild the system GRUB2 configuration that is used at boot time. This is done by running:

# grub2-mkconfig -o /boot/grub2/grub.cfg

You must also reboot the server for these settings to take effect.

For information on performance optimization goals and techniques for Oracle VM Server for x86, see Optimizing Oracle VM Server for x86 Performance, on Oracle Technology Network at: http://www.oracle.com/technetwork/server-storage/vm/ovm-performance-2995164.pdf.

5.7.3 Confirm kdump Service Settings after Upgrading

If the kdump service was enabled previously, it is recommended that you check and confirm the settings are correct after the upgrade or enable the kdump service after the upgrade if it was not enabled previously.

For more information, see Manually Configuring kdump for Oracle VM Server in the Oracle VM Administrator's Guide.

5.7.4 Handling Missing Disks, File Systems and Repositories

On a small number of systems, local physical disks may be allocated an alternate device mapper ID during the upgrade process. This only affects a few different ATA type disks. The change in device mapper ID can result in some local physical disks, their file systems and repositories as being marked as missing within Oracle VM Manager. Although the physical disk is discovered after the upgrade, it is detected as a new disk. The old entry within Oracle VM Manager, for the same disk, is retained but is marked as missing.

If you are affected by this, you may need to take some steps to reconfigure your environment for the change. This includes removing the missing disks and then refreshing the newly discovered disks, their file systems and any hosted repositories. The repository must additionally be presented to the affected Oracle VM Server again, so that it can be used.

If you have virtual machines that use local physical disks for storage, you may need to reconfigure these virtual machines to remove the missing disk and replace it with the newly discovered disk.

This section describes how to identify whether you are affected and the steps that you may need to take to return to a fully functioning environment.

Checking For Missing Disks

To see whether you are affected by this issue at all, you can use the Oracle VM Manager Web Interface to view the Physical Disks perspective for each Oracle VM Server in your environment. If a disk has been affected by the upgrade, it is displayed with a WARNING status. The event message shows "Physical disk is Offline".

In an environment with many Oracle VM Servers, it may not be practical to use the Oracle VM Manager Web Interface to check the status of the physical disks for every server. You can, however, use the Oracle VM Manager Command Line Interface in combination with the grep utility to quickly view all of the events that contain this event message. An example, where the command is run on the Oracle VM Manager host, follows:

$ ssh -l admin localhost -p 10000 "getEvents severity=WARNING" | grep -i "physical \
  disk is offline"

id:3190     createTime:timestamp     modTime:timestamp
type:storage.device.offline.     severity:Warning     summary:Physical disk is
Offline     acked:No description:OVMEVT_007005D_001 Rescan storage layer on
server [ovs237] did not return physical disk [3600605b0057feba01a0e216512d1b7aa]
for storage array [Generic Local Storage Array @ ovs237].
assocObjectId:0004fb0000180000833252939ba41cf9

Note that for these events, you must check that the event occurs for a Generic Local Storage Array. The server that is affected is displayed in the output, as is the id for the missing disk.

If this event message exists for any of the local physical disks attached to any of your Oracle VM Servers, then you are most likely affected by this issue and should continue with the rest of the steps described here.

Identifying Newly Discovered Disks and Matching Them To Missing Disks

By default, the simple names that Oracle VM Manager assigns to physical disks are based on the disk Page83 ID. If you have not renamed your physical disks, identifying newly discovered disks that map onto missing disks is simple, since the disk names can be compared to find matches. This is illustrated in the following output from the Oracle VM Manager Command Line Interface:

OVM> list physicalDisk
Command: list physicalDisk
Status: Success
Time: timestamp
Data:
 id:0004fb00001800007b2cdfbecb973c4d
 name:SATA_VBOX_HARDDISK_VBcdfe5359-5146ac3d_
 id:0004fb0000180000f9c966f19c14cc95
 name:SATA_VBOX_HARDDISK_VBcdfe5359-5146ac3d

In this output, the first physical disk listed is the original disk item, while the second disk is the newly discovered version of the same disk. The first physical disk is marked as missing in Oracle VM Manager. Since the second disk has the same name, with the exclusion of the final underscore character, it is easy to identify that these entries actually point to the same disk.

If you have changed the names for your physical disks, this process is fractionally more complicated since you must compare the Page83 ID of each disk to find the match. Obtaining the Page83 ID of a disk using the Oracle VM Manager Command Line Interface is illustrated below:

OVM> show physicaldisk id=0004fb00001800009eed86fbc36b41bc
Command: show physicaldisk id=0004fb00001800009eed86fbc36b41bc
Status: Success
Time: timestamp
Data:
  Page83 ID = 350014ee20137ee44
  Server Reserved = No
  Shareable = No
  Size (GiB) = 465.76
  State = UNKNOWN
  Thin Provision = No
  Type = LUN
  Vendor = ATA
  File System 1 = 0004fb00000500000809e28f4fab56b1  [fs on 350014ee20137ee44]
  Volume Group = 0004fb00003200004dddc710a12aa1b7  [Local Storage Volume Group]
  Id = 0004fb00001800009eed86fbc36b41bc  [Server5 ATA Disk]
  Name = Server5 ATA Disk
  Description = WDC WD5001ABYS-0
  Locked = false

Note that the Page83 ID is shown as a property of the disk. You must obtain the Page83 ID for each missing disk and then find any physical disks that have their name or Page83 ID set to the same value. These disks are the newly discovered versions of the same physical disk.

Useful Steps Before Reconfiguring Your Environment

The names of any child objects of the missing disk, such as file system names, repository names and the names of any items within the repository are all associated with the missing disk. This information is lost when you delete the missing disk from your environment. If you have named any of these objects within Oracle VM Manager, you should take note of the names of these objects before continuing. Although this is not a necessary step, since the names are only helpful within Oracle VM Manager and do not affect the running of your environment, to return your environment to the same state after you delete any missing disks you may wish to rename these objects once they are associated with the newly discovered version of the same physical disk.

Using the Oracle VM Manager Command Line Interface you can run the following commands to obtain a dump of the names of all of these objects:

OVM> list physicaldisk
OVM> list filesystem
OVM> list repository
OVM> show repository id=0004fb0000030000e0f09683cd2ac72a

Substitute 0004fb0000030000e0f09683cd2ac72a with the id for each repository in your environment, and run the same command for each repository.

The goal of this exercise is to obtain a listing of the names of any of the objects that may be affected when you remove the physical disk that they are associated with. Store the information returned by these commands in a place that you can refer to when you need to rename objects.

Steps To Deal With Affected Repositories

If you have made a record of the object names of all affected objects, it is safe to delete the missing disks, as illustrated in the following output from the Oracle VM Manager Command Line Interface:

OVM> delete physicalDisk id=0004fb00001800007b2cdfbecb973c4d
Command: delete physicalDisk id=0004fb00001800007b2cdfbecb973c4d
Status: Success
Time: timestamp
JobId: 1399409030129

These actions can also be performed in the Oracle VM Manager Web Interface, if preferred.

Once you have deleted the missing disk entry, you must perform the following actions:

Identify the newly discovered disk that corresponds to the disk that you have deleted, and refresh it as described in Refresh Physical Disk in the Oracle VM Manager User's Guide.
Now, refresh the file systems on the disk as described in Refresh File System in the Oracle VM Manager User's Guide.
Next, you must refresh the repositories that are hosted on the local physical disk, as described in Refresh Repository in the Oracle VM Manager User's Guide.
Finally, present the repository to the Oracle VM Server where the physical disk is located. See Present or Unpresent Repository in the Oracle VM Manager User's Guide for more information.

At this point, your environment is usable, although the names of various objects have been lost. For instance, any file system names, repository names, or the names of objects such as virtual machines in a repository are likely to have been reset to default values. If you kept a record of the object names affected, as recommended in the previous step, then you can manually rename objects as required.

Steps To Deal With Affected Virtual Machines

If you have any virtual machines that were configured to use a local physical disk that is marked as missing, you must remove the original disk mapping and then reconfigure the virtual machine to attach a new physical disk. When you select the new physical disk, you should select the physical disk with the same Page83 ID as the missing disk. To reconfigure these disk mappings, you must edit the virtual machine as described in Edit Virtual Machine in the Oracle VM Manager User's Guide.

5.8 Upgrading Oracle VM Agent for SPARC

Upgrade methods depend on the Oracle VM Agent for SPARC Release from which you are upgrading. For information about upgrade methods, see Section 5.1, “Upgrade Overview”.

Before you attempt to upgrade the Oracle VM Agent for SPARC, you must:

Update your system to Oracle Solaris 11.3 or Solaris 11.4.

On Oracle VM Agent for SPARC Release 3.2.10, or later versions such as Release 3.2.11, you must manually upgrade to Oracle Solaris 11.3.

As of Release 3.4.6, Oracle Solaris 11.4 is supported. If you are running Oracle VM Agent for SPARC Release 3.3.x, 3.4.1 or 3.4.2, and you plan to upgrade to Release 3.4.6, you must first upgrade to Release 3.4.5 on Oracle Solaris 11.3. From Release 3.4.5, after a reboot you can then upgrade to Release 3.4.6 with Oracle Solaris 11.4.

Note

If you are running an older version of Oracle VM Agent for SPARC, upgrading to Release 3.4.5 ensures that your system has the latest 11.3 SRU available (Oracle Solaris 11.3 SRU 23 or later), which is required before you upgrade to Release 3.4.6 with Oracle Solaris 11.4.

On Oracle VM Agent for SPARC Release 3.3.x or Release 3.4.x, you set up an IPS repository to handle both the update to Oracle Solaris 11.3 and the upgrade of Oracle VM Agent for SPARC.
Review all minimum requirements to ensure a successful upgrade. See Table 2.2, “Required Software and System Firmware for SPARC Servers”.

Note

If you have a secondary service domain configured and you have successfully updated your system to Oracle Solaris 11.3 or Solaris 11.4 on the primary domain, the secondary service domain can also be upgraded using the same Oracle Solaris IPS repository as the primary domain. To upgrade the secondary service domain, you should upgrade from the Oracle Solaris command line using the following command:

# pkg update --accept

Reboot the system after the upgrade completes, as follows:

# init 6

For detailed install and upgrade instructions for Oracle Solaris 11.3, see http://docs.oracle.com/cd/E53394_01/.

For detailed instructions on updating to Oracle Solaris 11.4, see https://docs.oracle.com/cd/E37838_01/html/E60977/gmpdi.html

5.8.1 Installing the Distributed Lock Manager (DLM) Package

The distributed lock manager (DLM) package is required to support server pool clustering. The version of the DLM package must match the version of Oracle VM Agent for SPARC.

If the DLM package is already installed on your system, download the Release 3.4 version of the DLM package and add it to the IPS repository before you attempt to upgrade.
If the DLM package is not already installed, or you are upgrading from Oracle VM Agent for SPARC Release 3.2.10, you can install it before you upgrade Oracle VM Agent. Alternatively, you can install the DLM package after the upgrade is complete.

Download the DLM package, ovs-dlm-3.4.x-bxxx.p5p, from https://edelivery.oracle.com/oraclevm. For more information about downloading software, see Section 1.2, “Getting Installation ISOs and Packages”.

To add the DLM package to an IPS repository, see Section 5.8.3.1, “Setting Up IPS Repositories”.

To install the DLM package, do the following:

Stop the ovs-config service:
```
# svcadm disable -s ovs-config
```

Install the DLM package:

# pkg install -g ovs-dlm-3.4.x-bxxx.p5p dlm

Restart the ovs-config service:
```
# svcadm enable ovs-config
```

5.8.2 Upgrading from Oracle VM Agent for SPARC Release 3.2.10

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

5.8.2.1 Placing Oracle VM Server for SPARC in Maintenance Mode

Before you begin any procedures to upgrade from Release 3.2.10, or a later version such as Release 3.2.11, you should ensure that no virtual machines are running on the server. For this reason you should place each Oracle VM Server for SPARC that you plan to upgrade in maintenance mode. After you place each Oracle VM Server for SPARC in maintenance mode, you should also check that no virtual machines are running on the servers you plan to upgrade. If any virtual machines are still running, you should stop them before attempting to upgrade Oracle VM Server for SPARC.

For instructions on editing a server and placing it in maintenance mode, see Edit Server in the Oracle VM Manager User's Guide.

5.8.2.2 Updating to Oracle Solaris 11.3 Manually

The first step to upgrade from Oracle VM Agent for SPARC Release 3.2.10, or a later version such as Release 3.2.11, is to manually update your system to Oracle Solaris 11.3 Support Repository Update (SRU) 19.

Note

Oracle VM Agent for SPARC Release 3.2.10 cannot run on Oracle Solaris 11.3. For this reason, you should disable Oracle VM Agent for SPARC before you update to Solaris 11.3.
```
# svcadm disable ovs-agent
```
Oracle VM Agent for SPARC Release 3.2.x does not allow installations higher than Oracle Solaris 11.3 SRU 19. This is due to the removal of Python 2.6 in SRU 20. Once Oracle VM Agent for SPARC Release 3.4.3 or later is installed, the Oracle Solaris system can be upgraded to a more recent version.
This procedure should be used with Oracle VM Agent for SPARC Release 3.4.5 to update to the latest Oracle 11.3 SRU before rebooting the server and using the same procedure in Oracle VM Agent for SPARC Release 3.4.6 to updates the server from Oracle Solaris 11.3 to Solaris 11.4.

If you have already set up the Oracle Solaris repository, you can update the system packages with the following command:

# pkg update --accept

Reboot the system after the upgrade completes, as follows:

# init 6

For detailed instructions on updating to Oracle Solaris 11.3, see http://docs.oracle.com/cd/E53394_01/html/E54845/toc.html.

For detailed instructions on updating to Oracle Solaris 11.4, see https://docs.oracle.com/cd/E37838_01/html/E60977/gmpdi.html

5.8.2.3 Downloading and Extracting the Oracle VM Agent for SPARC Software

Before you you can upgrade Oracle VM Agent for SPARC to Release 3.4, you must download and extract the software.

Download the Oracle VM Agent for SPARC software for Release 3.4 from https://edelivery.oracle.com/oraclevm.

For more information about downloading software, see Section 1.2, “Getting Installation ISOs and Packages”.
Extract the software, for example:
```
# tar xzf ovs-ldoms-3.4.x-bxxx.tar.gz
```

5.8.2.4 Upgrading Oracle VM Agent for SPARC

To upgrade Oracle VM Agent for SPARC from Release 3.2.10, or a later version such as Release 3.2.11, do the following:

Open a terminal connection to the system you plan to upgrade.
Change to the directory where you extracted the software: ovs-ldoms-3.4.x-bxxx
Run: ./update
From Oracle VM Manager, rediscover the server and take it out of maintenance mode, if necessary.
Complete the update by performing a server upgrade from within the Oracle VM Manager Web Interface as described in Update Server in the Oracle VM Manager User's Guide.

Example Output

# ./update 

Oracle VM Agent Release 3.4.1 Updater

- Stopping the Oracle VM Agent

- Updating Packages

Updating package cache                           1/1 
Caching catalogs ...


           Packages to install:         1
            Packages to update:         6
            Services to change:         1
     Estimated space available: 523.69 GB
Estimated space to be consumed: 748.24 MB
       Create boot environment:        No
Create backup boot environment:       Yes
          Rebuild boot archive:        No

Changed packages:
ovm
  ovm/storage-connect/plugins/oracle-zfs
    None -> 1.0.0,5.11-3.4.1.0.0.914:20150805T065013Z
  ovm/extra/urlgrabber
    3.9.1,5.11-3.2.10.0.0.759:20150924T063650Z -> 3.9.1,5.11-3.4.1.0.0.914:20150805T064943Z
  ovm/extra/vbox-img
    1.0.0,5.11-3.2.10.0.0.759:20150924T063654Z -> 1.0.0,5.11-3.4.1.0.0.1087:20151021T045254Z
  ovm/ovs-agent
    3.2.10,5.11-3.2.10.0.0.760:20150929T055226Z -> 3.4.1,5.11-3.4.1.0.0.1085:20151020T044541Z
  ovm/ovs-release
    3.2.10,5.11-3.2.10.0.0.760:20150929T055240Z -> 3.4.1,5.11-3.4.1.0.0.1087:20151021T045318Z
  ovm/storage-connect/plugin-manager
    1.2.8,5.11-3.2.10.0.0.759:20150924T063700Z -> 1.2.8,5.11-3.4.1.0.0.1033:20150928T170453Z
  ovm/storage-connect/plugins/oracle-generic
    1.1.0,5.11-3.2.10.0.0.760:20150929T055232Z -> 1.1.0,5.11-3.4.1.0.0.914:20150805T064958Z

Services:
  restart_fmri:
    svc:/system/manifest-import:default

DOWNLOAD                                PKGS         FILES    XFER (MB)   SPEED
Completed                                7/7       310/310      0.8/0.8  589k/s

PHASE                                          ITEMS
Removing old actions                             5/5
Installing new actions                       187/187
Updating modified actions                    209/209
Updating package state database                 Done 
Updating package cache                           6/6 
Updating image state                            Done 
Creating fast lookup database                   Done 
Updating package cache                           2/2 
Updating package cache                           1/1 

- Updating the OVS Agent Configuration

Network Configuration
Network Configuration OK
Storage Configuration
Storage Configuration OK
OVS Agent Configuration
OVS Agent Configuration OK
Cluster Configuration
Cluster Configuration OK
LDoms Manager Configuration
LDoms Manager Configuration OK
Virtual I/O Services Configuration
Virtual I/O Services Configuration OK
LDoms Configuration
LDoms Configuration OK
Enabling Oracle VM Agent Services

Update Completed.

5.8.3 Upgrading from Oracle VM Agent for SPARC Release 3.3.`x` or Between 3.4.`x` Errata Releases

Complete the tasks in this section to upgrade to Release 3.4 from Oracle VM Agent for SPARC Release 3.3.x or from one Release 3.4.x to another Release 3.4.y.

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 are 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."

5.8.3.1 Setting Up IPS Repositories

Upgrades for Oracle VM Servers that are running on SPARC hardware can be handled by setting up two Oracle Solaris Image Package System (IPS) repositories. Your IPS repositories can be hosted on any system, either x86 or SPARC, as long as it is running Oracle Solaris 11 or later. The system where you configure these repositories must be accessible over the network by all of the SPARC based Oracle VM Servers that you wish to upgrade.

The first repository should be set up to handle Oracle Solaris updates and should have its publisher set to solaris. This repository can be used to keep the Oracle Solaris software in your control domains up to date. It is critical that this repository contains the packages for Oracle Solaris 11.3 or higher. This repository must be enabled if you intend to upgrade from a version equal to or prior to Oracle VM Server for SPARC release 3.3.x. The Oracle Solaris system repository can also be copied locally if you are updating a set of local Oracle VM Servers running on SPARC hardware. Instructions on setting up and copying IPS repositories can be found in the book titled Creating Package Repositories in Oracle Solaris 11.4 in the Oracle Solaris 11.4 Information Library at:

https://docs.oracle.com/cd/E37838_01/html/E60982/index.html

The second IPS repository should be set up to contain the Oracle VM Agent for SPARC and associated packages. This repository can be used to ensure that the latest version of Oracle VM Agent for SPARC is available to be installed on your Oracle VM Servers. You can also use this repository to store commonly required packages such as the distributed lock manager (DLM) package required for cluster support. This repository should have its publisher set to ovm. The instructions that follow explain how to set up and configure this IPS repository.

To set up an IPS repository for Oracle VM Agent for SPARC

If you have not already created a package repository that is accessible over HTTP, you must create one by performing the following actions on the system where you intend to host your repositories:

# pkgrepo create /path/to/my-repository
# svccfg -s application/pkg/server setprop pkg/inst_root=/path/to/my-repository
# svccfg -s application/pkg/server setprop pkg/port=8888
# svcadm refresh application/pkg/server
# svcadm enable application/pkg/server

Check that the package repository server is online:

# svcs pkg/server
STATE          STIME    FMRI
online         timestamp svc:/application/pkg/server:default

Download the latest Oracle VM Agent for SPARC software from https://edelivery.oracle.com/oraclevm, as described in Section 1.2, “Getting Installation ISOs and Packages”.
Extract the software, for example:
```
# tar xzf ovs-ldoms-3.4.x-bxxx.tar.gz
```

Copy the software to the package repository, for example:

# pkgrecv -s ovs-ldoms-3.4.x-bxxx/ovs-ldoms.p5p -d /path/to/my-repository 'ovm/*'
# pkgrecv -s ovs-dlm-3.4.x-bxxx.p5p -d /path/to/my-repository 'ovm/*'

Restart the package repository server and ensure that it is online:
```
# svcadm restart application/pkg/server
# svcs pkg/server
```
If the package repository server is in maintenance status, clear the service:
```
# svcadm clear pkg/server
```

Check that the contents of the repository are available, for example:

# pkgrepo list -s /path/to/my-repository
# pkgrepo list -s http://my-repo-server:8888/

5.8.3.2 Creating Server Update Repositories in Oracle VM Manager

The IPS repositories must be set up within the Oracle VM Manager Web Interface, so that the upgrade script can identify them accurately and use them to perform the upgrade on the specified Oracle VM Servers. The repositories are called server update repositories in the Oracle VM Manager Web Interface.

Use the Oracle VM Manager Web Interface to create two server update repositories, one for each repository. Make sure you create these server update repositories in the Sparc server update group. The following tables contain the information you need to create the server update repositories using the Create Server Update Repository dialog box.

Full instructions for creating a server update repository in the Oracle VM Manager Web Interface are provided in Create New Server Update Repository in the Oracle VM Manager User's Guide.

Table 5.5 Solaris Repository

Field	Value	Notes
Name	`solaris`	You may name this repository as you prefer within Oracle VM Manager, but choose a name that makes it easy for you to understand what the repository contains.
Repository Name	`solaris`	This should be set to the same name that you used for the IPS publisher.
URL	`http://my-repo-server:8888/solaris`	Substitute this URL with the URL to your Solaris IPS repository.
Enabled	Yes	You can enable or disable this repository to control whether only the Oracle VM Agent software is updated, or whether other Solaris packages are updated as well. If the server is running a version of Solaris that is lower than 11.3, the repository must be enabled. Likewise the repository must contain the packages for Oracle Solaris 11.3 at a minimum.
Package Signature Type	None	No package signature type is required here.

Table 5.6 OVM Repository

Field	Value	Notes
Name	`ovm-agent`	You may name this repository as you prefer within Oracle VM Manager, but choose a name that makes it easy for you to understand what the repository contains.
Repository Name	`ovm`	This should be set to the same name that you used for the IPS publisher.
URL	`http://my-repo-server:8888/ovm`	Substitute this URL with the URL to your Oracle VM Agent for SPARC IPS repository.
Enabled	Yes	You can enable or disable this repository to control whether the Oracle VM Agent software is updated, or whether only Solaris packages are updated. This repository must be enabled if you intend to upgrade the Oracle VM Agent.
Package Signature Type	None	No package signature type is required here.

5.8.3.3 Upgrading Oracle VM Agent for SPARC

Note

Before you begin any procedures to upgrade from Release 3.2.10, or a later version such as Release 3.2.11, you should ensure that no virtual machines are running on the server. For this reason you should place each Oracle VM Server for SPARC that you plan to upgrade in maintenance mode. After you place each Oracle VM Server for SPARC in maintenance mode, you should also check that no virtual machines are running on the servers you plan to upgrade. If any virtual machines are still running, you should stop them before attempting to upgrade Oracle VM Server for SPARC.

For instructions on editing a server and placing it in maintenance mode, see Edit Server in the Oracle VM Manager User's Guide.

With your IPS repositories configured, you can perform server upgrades from within the Oracle VM Manager Web Interface as described in Update Server in the Oracle VM Manager User's Guide. If you have defined repositories for the Solaris operating system and for the Oracle VM Agent, then an update action is performed for both the Solaris operating system and the Oracle VM Agent. If you only want to update a particular component, either the Solaris operating system or the Oracle VM Agent, disable the repository with the component that you do not want to update within Oracle VM Manager.

5.9 Rolling Back from an Upgrade

This section describes steps that you can perform to rollback from an upgrade. Provision is made for a rollback from an upgrade of Oracle VM Manager if something goes wrong during the upgrade process. Rollback of Oracle VM Server upgrades is not catered for, and in this instance you must reinstall the version of Oracle VM Server that you wish to roll back to, and then rediscover the server in Oracle VM Manager.

The Oracle VM Manager automatically performs a full data backup of the database, if you are currently using the bundled MySQL database, when you run the installer with the upgrade option. This backup is stored in /u01/app/oracle/mysql/dbbackup. The name of the backup is printed to the screen during the upgrade process and is named similarly to 3.4.1_preUpgradeBackup-YYYYMMDD_hhmmss.

If your Oracle VM Manager was using the bundled MySQL database, you must first uninstall the Oracle VM Manager Release 3.4 software, then install the previous version of the software, and finally restore the database from this backup. The release that you are restoring from should include instructions for rolling back the database from a backup in the provided documentation. You may also refer to Restoring Oracle VM Manager in the Oracle VM Administrator's Guide.

If your Oracle VM Manager was using a remote Oracle Database, and you have left this database intact through the upgrade process, rolling back simply requires that you uninstall the Oracle VM Manager Release 3.4 software, then install the previous version of the software, taking care to provide the details for the existing Oracle Database tablespace during the installation process.

Instructions for both of these scenarios follow.

Rolling Back Oracle VM Manager to a previous release using MySQL:

Uninstall Oracle VM Manager Release 3.4 software using the instructions provided at Section 4.5, “Uninstalling Oracle VM Manager”.

Important

Do not remove the database backup directory after you have completed the uninstall process, The database backup generated during the upgrade process is required to restore your previous environment.
Install the previous Oracle VM Manager version, following the installation instructions provided in the documentation for that version.
Stop the ovmm, and ovmm_mysql services respectively.
Before you restore the database, ensure that no database files already exist on the Oracle VM Manager host:
```
# cd /u01/app/oracle/mysql/data/
# rm -rf appfw ibdata1 ib_logfile0 ib_logfile1 mysql ovs performance_schema
```
Important

Do not remove any of the following files from /u01/app/oracle/mysql/data/:
- auto.cnf
- my.cnf
- .mysqlconfig
- mysql_upgrade_info
  
  This file may only exist if there was an upgrade to the current version. It does not exist on systems where a fresh installation was performed.
Run the database restore utility with the database backup that was created during the beginning of the upgrade. If you are rolling back to a 3.3.x release, you can issue the following command:
```
# cd /u01/app/oracle/ovm-manager-3/ovm_tools/bin
# su oracle -c "sh ./RestoreDatabase.sh 3.4.1_preUpgradeBackup-YYYYMMDD_hhmmss"
```
If you are rolling back to Release 3.2.10, or a later version such as Release 3.2.11, the RestoreDatabase.sh script is located at a different path, so issue the following command instead :
```
# cd /u01/app/oracle/ovm-manager-3/ovm_shell/tools
# su oracle -c "sh ./RestoreDatabase.sh 3.4.1_preUpgradeBackup-YYYYMMDD_hhmmss"
```
Substitute 3.4.1_preUpgradeBackup-YYYYMMDD_hhmmss with the name of the backup that you wish to restore to. This is typically the name of the pre-upgrade backup that is printed in the output of the upgrade process.
Start the ovmm_mysql and ovmm services respectively.
If you are rolling back to a 3.3.x release, it is necessary to reconfigure the certificates used to authenticate components such as the Oracle VM Manager Web Interface and Oracle VM Manager Command Line Interface. This is achieved by running the following script to reconfigure the Oracle WebLogic Server:
```
# export MW_HOME=/u01/app/oracle/Middleware
# /u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh setupWebLogic
```
Once you have run this command, you must restart Oracle VM Manager and then run the client certificate configuration script:
```
# /sbin/service ovmm restart
# /u01/app/oracle/ovm-manager-3/bin/configure_client_cert_login.sh
```
The script requires that Oracle VM Manager is running, and prompts you for the administrator username and password that should be used to access Oracle VM Manager. The script makes changes that may require Oracle VM Manager to be restarted:
```
# /sbin/service ovmm restart
```
Log into the Oracle VM Manager Web Interface and check that the configuration matches what was in place prior to the upgrade process. Use the Refresh All option within the Oracle VM Manager Web Interface to refresh all of your server pools to ensure that all of your virtual machine resources are available.

Rolling Back Oracle VM Manager to a previous release using an Oracle Database:

If you have not left the Oracle Database OVM tablespace (ovs) intact since your upgrade, you must restore the data from a backup before attempting to rollback.
Uninstall the Oracle VM Manager Release 3.4 software using the instructions provided at Section 4.5, “Uninstalling Oracle VM Manager”.
Install the previous Oracle VM Manager version, following the installation instructions provided in the documentation for that version. During the installation, the installer detects the presence of the old database table space (ovs) and provides an option to use the old database table space. Select this option to restore Oracle VM Manager to the state that it was in when the database was last backed up.
Log into the Oracle VM Manager Web Interface and check that the configuration matches what was in place prior to the upgrade process.

Chapter 5 Upgrading Oracle VM

5.1 Upgrade Overview

5.2 Preparing to Upgrade Oracle VM

5.2.1 Checking Minimum System Requirements

5.2.2 Validating Oracle VM Server Version Compatibility

5.2.3 Preparing to Upgrade Oracle VM Manager

5.2.4 Preparing to Upgrade Oracle VM Server

5.2.4.1 Increasing Partition Sizes for Oracle VM Server

5.2.4.2 Checking the Oracle VM Agent Notification Service

5.2.4.3 Recommendations for Upgrading Oracle VM Server

5.3 Downloading the Upgrade Software

5.4 Upgrading Oracle VM Manager

5.4.1 Running the Script to Upgrade Oracle VM Manager

5.4.2 Removing Temporary Files After Upgrade

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

5.5.1 Upgrading Oracle VM Server from Release 3.2.10

5.5.1.1 Setting Up the Yum Repositories

Creating the Yum Repositories

Including Additional Packages

Adding Server Update Repositories in Oracle VM Manager

5.5.1.2 Running the UpgradeServers.py Script

Syntax

Options

Non-native Packages

Post-upgrade Storage Array Plug-in Reconciliation

Typical Output From the UpgradeServers.py Script

5.5.1.3 Removing the Transitional Yum Repository

5.5.2 Reinstalling Oracle VM Server

5.6 Upgrading Oracle VM Server for x86 from Release 3.3.x or Between 3.4.x Errata Releases

5.6.1 Upgrading Oracle VM Server Through Oracle VM Manager

5.6.1.1 Creating the Yum Repository

5.6.1.2 Including Additional Packages

5.6.1.3 Adding Server Update Repositories in Oracle VM Manager

5.6.1.4 Upgrading Servers from Oracle VM Manager

5.6.2 Upgrading Oracle VM Server Using the ISO File

System to Upgrade

Upgrade Boot Loader Configuration

Package Installation and Finishing the Upgrade

5.6.3 Reinstalling Oracle VM Server

5.7 Finalizing Upgrades on Oracle VM Server for x86

5.7.1 Refreshing Server Pools To Validate Oracle VM Storage Connect plug-in

5.7.2 Editing Boot Parameters To Enable Hypervisor Features

For large servers with more than 20 physical CPUs

5.7.3 Confirm kdump Service Settings after Upgrading

5.7.4 Handling Missing Disks, File Systems and Repositories

Checking For Missing Disks

Identifying Newly Discovered Disks and Matching Them To Missing Disks

Useful Steps Before Reconfiguring Your Environment

Steps To Deal With Affected Repositories

Steps To Deal With Affected Virtual Machines

5.8 Upgrading Oracle VM Agent for SPARC

5.8.1 Installing the Distributed Lock Manager (DLM) Package

5.8.2 Upgrading from Oracle VM Agent for SPARC Release 3.2.10

5.8.2.1 Placing Oracle VM Server for SPARC in Maintenance Mode

5.8.2.2 Updating to Oracle Solaris 11.3 Manually

5.8.2.3 Downloading and Extracting the Oracle VM Agent for SPARC Software

5.8.2.4 Upgrading Oracle VM Agent for SPARC

Example Output

5.8.3 Upgrading from Oracle VM Agent for SPARC Release 3.3.x or Between 3.4.x Errata Releases

5.8.3.1 Setting Up IPS Repositories

5.8.3.2 Creating Server Update Repositories in Oracle VM Manager

5.8.3.3 Upgrading Oracle VM Agent for SPARC

5.9 Rolling Back from an Upgrade

5.6 Upgrading Oracle VM Server for x86 from Release 3.3.`x` or Between 3.4.`x` Errata Releases

5.8.3 Upgrading from Oracle VM Agent for SPARC Release 3.3.`x` or Between 3.4.`x` Errata Releases