Now when we have used demo 3.4.2 for some time without issues I decided to upgrade our sandbox Oracle VM setup from 3.3.3 to 3.4.2 to get experience for the actual production upgrade coming later.

We have two installations of Oracle VM. One is sandbox which has some old blade servers acting as OVS and few VM’s to play around and the other one is production Oracle VM which has all the operational production and test virtual machines.

We like to keep them on the same version so we can debug any issues if there are some and to test upgrades like this one.

Upgrade is really simple procedure:

  1. Upgrade Oracle VM Manager
  2. Upgrade all OVS machines 

Actual upgrade

For the OVM Manager I had to download the OVM Manager 3.4.2 ISO file and mount it on the OVM Manager server. After that just execute the runInstaller.sh

Once I had selected option “2: Upgrade” it proceeded on taking backup of my current OVM installation. Previously you had to do this manually so this is good addition!

For our sandbox the upgrade ran total of 30 minutes. After logging in to Oracle VM Manager I could see following warnings for all OVS machines:

Description:OVMEVT_004013D_000 Server: ovs1.uponor.local, is at a version:
3.3.3-1085, that is older than the manager version: 3.4.2.1384. 
The server must be updated.

Obviously now I had to upgrade each OVS. For that I downloaded Oracle Virtual Server 3.4.2 ISO file. Mounted it on one server, copied contents to /u01/ovs_upgrade and created http server via python -m SimpleHTTPServer on the ovs_upgrade folder.

Then I created global server update group under “Reports and Resources” which linked to above server/directory.

global_server_1

At this point I encountered my first (and only) issue. No matter what I did only one of the OVS was showing that there was update required. I tried remounting or if it would help creating server pool specific update group. Also rebooted the OVS just in case.

no_fish_global_update_group_only_one

As usual the problem was easier than it looked. I checked the ovm manager logfile under: /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/logs and noticed quickly what the issue was after seeing this line:

<OVMAPI_4010E Attempt to send command: package_list to server: ovs1.uponor.local failed. OVMAPI_4004E Sync command failed on server: 192.168.1.135. Command: package_list,Server error: org.apache.xmlrpc.XmlRpcException: <class ‘yum.Errors.RepoError’>:Cannot retrieve repository metadata (repomd.xml) for repository: OVM. Please verify its path and try again

We hadn’t configured /etc/resolv.conf for these sandbox servers apart from the one showing an update! When I tried pinging the server having the upgrade files from the OVS it couldn’t find the host. After fixing the resolv.conf  Update Required showed up to all servers.

Before I started upgrading OVS to 3.4.2 I manually migrated all VMs off from the to-be upgraded server. If you don’t do this then OVM Manager will do it for you but just to be sure I like to do it myself.

upgrade_button
Update OVS Server button comes visible when there is update available

 

 

 

After clicking the update button one final confirmation.

update_warning

Once I started the upgrade I saw from the server sharing the necessary files it downloaded them all and then worked for some time on the upgrade. For me one OVS took around 10 minutes to get upgraded.

upgrade_time

Summary

Actual upgrade is really simple and this time we didn’t face any issues with test upgrade. Earlier we have seen that the LUN names from our storage have been lost so you need to manually name them back again. If you have few hundred LUNs it might be bit annoying.

Total time depends on the amount of VM migration you need to do from one server to another. For our production we are expecting the total time will be around one day. Good thing it can be done transparently!

OVM Manager: ~30 minutes
One OVS: ~10 minutes

In the end really simple upgrade with straighforward steps.

One thought on “Upgrading Oracle VM 3.3.3 to 3.4.2”

Leave a Reply

Your email address will not be published.