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:
- Upgrade Oracle VM Manager
- Upgrade all OVS machines
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: 18.104.22.1684. 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.
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.
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.
After clicking the update button one final confirmation.
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.
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.