Oracle VM: Changing the o2cb Heartbeat Timeout without a Reboot when using NFS Repositories (Doc ID 2217229.1)

Last updated on APRIL 04, 2024

Applies to:

Private Cloud Appliance - Version 2.2.2 to 2.2.2 [Release 2.0]
Oracle VM - Version 3.2.9 to 3.2.9 [Release OVM32]
Oracle Cloud Infrastructure - Version N/A and later
Linux x86-64
Contributors: Andy Herm, Ashish Samant, Greg King, Srini Eeda
Technical Review: Conor Wentz, Simon Coter, Saar Maoz

Goal

Summary

The procedure in this document describes a method for applying an O2CB_HEARTBEAT_THRESHOLD change to an active, NFS based production pool without a service outage.

Background

Oracle VM is sometimes deployed into production environments where the default o2cb timeout is not compatible with normal delays encountered with networking and storage components during upgrades and failovers. In these cases, it can be useful to increase the timeout value to reduce the risk of unnecessary eviction reboots and resulting service outages.

On OCFS2 based repositories, making this change requires an unmount and service outage because the file locking mechanism resides on the pool nodes and is implemented using a Distributed Lock Manager (DLM). With NFS repositories, the file locking mechanism resides on the file server, so unmounting the repositories (and a service outage) is not required to make this change. In either case, lock management across the pool nodes is still needed by the Oracle VM application because a mutual exclusion mechanism is required to prevent the same VM from being started more then once.

Please note that newer UEK kernels provide a mechanism for extending the heartbeat timeout if all the nodes report a simultaneous loss of connectivity to storage. When a kernel with this feature is deployed across the entire pool, extending the o2cb timeout using this procedure may not be necessary. At this time, the kernel versions (uek2) V2.6.39-400.288.1 and (uek4) V4.1.12-41 contain this patch and should be considered for new installations or where a rolling reboot of an existing deployment is possible.