Get the latest scoop on products, strategy, events, news, and more, from Oracle's virtualization experts

Deploying Oracle VM 2.2 and Upgrading Oracle VM from 2.1.5 to 2.2

Oracle VM 2.2 was announced last week, bringing customers more benefits by providing better performance, scalability and security. In the next series of blogs, I'd like to cover some new features of Oracle VM 2.2. But first, how can I get started with Oracle VM 2.2 or upgrade the existing Oracle VM 2.1.5 environment to 2.2?

If you read my previous blog - Basics of Oracle VM, you use Oracle VM Manager to manage many Oracle VM servers. Multiple Oracle VM Servers are grouped into Server Pools in which every server in a given pool has access to shared storage, which can be NFS, SAN (Fibre Channel) or iSCSI storage. This allows VMs associated with the pool to start and run on any physical server within the pool that is available and has the most resources free. Given the uniform access to shared storage, VMs may also be securely Live Migrated or automatically (re-)started across any servers in the pool. Each Oracle VM server or Manager installation just takes a few minutes. You can refer to the Oracle VM 2.2 documentation for details.

In Oracle VM 2.2, it's much easier to configure the shared storage repositories. We provide an improved shared storage configuration and cluster configuration script (/opt/ovs-agent-2.3/utils/repos.py). This new script replaces the previous scripts, ovs-makerepo and ovs-offlinerepo in the /usr/lib/ovs/ directory, and the /etc/init.d/ovsrepositories script. The goal is to reduce storage repositories set up complexity. In addition, the /OVS directory is the cluster root and is a symbolic link mounted to the /var/ovs/mount/uuid directory. You can refer to the "Creating Shared Storage and Cluster" and "Managing Storage Repositories" chapter of the Oracle VM 2.2 Server User Guide.

If you upgrade your Oracle VM 2.1.5 server pool to Oracle VM 2.2, you should plan properly and ensure a smooth upgrade. There are some important factors to consider. You can not mixed Oracle VM 2.1 and 2.2 servers in the same server pool, so there would be planned down time during the upgrade; however, the stored VMs in the repositories remain intact. It only took several minutes minutes to upgrade the Manager, and each server node upgrade would just take a few minutes. So the entire upgrade process should not be long depending on the size of your server pool.

Before you start the upgrade, you want to make sure that your existing server pool has been configured properly:

The hostname in /etc/hosts must be associated with the public IP address instead of 127.0.0.1

You have all the server entries in your DNS server; If DNS is not used, make sure the correct setting in /etc/hosts for all the servers in the pool. If you plan to use DNS for all servers, but DNS was not specified during the server installation, please update /etc/resolv.conf file and add your domain name in it.

All the servers in the same pool must have the consistent name resolution, either by DNS or by file (/etc/hosts). You should not have mixed name services for the servers in the same server pool. For example, some have DNS, while others use /etc/hosts to resolve host names.

2) Upgrade non-master Servers, make sure that VMs have been shutdown before the upgrade; After the upgrade, no need to reboot the server at this time if you want to enable sparse file support for OCFS2 cluster in the next step.

Option 2: if connected with ULN, you can read the instructions to upgrade the server via ULN.

3) The server pool master should be the last one to perform upgrade. Reboot the server after you complete the upgrade.
If you want to turn on the new OCFS2 1.4 feature support, such as sparse files and unwritten extents, you can enable the feature now: (the device must be unmounted from all nodes before performing the tunefs.ocfs2 command)
# umount <device>
# tunefs.ocfs2 --fs-features=sparse,unwritten <device>

Also, if the user encounters the following error, it means that the volume is still mounted on one or more nodes.
# tunefs.ocfs2 --fs-features=sparse,unwritten <device>
tunefs.ocfs2: Trylock failed while opening device "<device>"

4) Reboot the rest of the servers in the pool, the server pool master agent will communicate with the other nodes in the pool, populate the changes of the cluster and storage repository configurations.

5) If the server pool is HA-enabled and you want the server pool master fail-over feature, be sure to add the virtual IP address for the server pool from the Oracle VM Manager.