// Module included in the following assemblies:
//
// * virt/updating/upgrading-virt.adoc

:_mod-docs-content-type: CONCEPT

[id="virt-about-upgrading-virt_{context}"]
= About updating {VirtProductName}

[role="_abstract"]
When you install {VirtProductName}, you select an update channel and an approval strategy. Both settings affect supportability.

The update channel determines the version of {VirtProductName} that you use. The approval strategy determines whether updates occur automatically or require manual approval.

[id="recommended-settings_{context}"]
== Recommended settings

To keep a supportable environment, use the following settings:

* Update channel: *stable*
* Approval strategy: *Automatic*

Most {VirtProductName} installations use the *stable* release channel and the *Automatic* approval strategy. Use other settings only if you understand the risks.

With these settings, the update process starts automatically when a new Operator version is available in the *stable* channel. This keeps {VirtProductName} and {product-title} versions compatible and ensures that {VirtProductName} is suitable for production environments.

[NOTE]
====
Each minor version of {VirtProductName} is supported only with the corresponding {product-title} version. For example, you must run {VirtProductName} {VirtVersion} on {product-title} {VirtVersion}.
====

[id="what-to-expect_{context}"]
== What to expect

You can expect consistent update behavior in {VirtProductName}, including duration, automation, and data preservation.

* The time required to complete an update depends on your network connection. Most automatic updates complete within fifteen minutes.

* Updating {VirtProductName} does not interrupt network connections.

* An update preserves data volumes and their associated persistent volume claims.

ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
[IMPORTANT]
====
If virtual machines use hostpath provisioner storage, they cannot be live migrated and might block an {product-title} cluster update.

As a workaround, reconfigure the virtual machines so they can power off automatically during a cluster update. Set the `evictionStrategy` field to `None` and the `runStrategy` field to `Always`.
====
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
ifdef::openshift-rosa,openshift-rosa-hcp[]
[IMPORTANT]
====
If virtual machines use AWS Elastic Block Store (EBS) storage, they cannot be live migrated and might block an {product-title} cluster update.

As a workaround, reconfigure the virtual machines so they can power off automatically during a cluster update. Set the `evictionStrategy` field to `None` and the `runStrategy` field to `Always`.
====
endif::openshift-rosa,openshift-rosa-hcp[]

[id="how-updates-work_{context}"]
== How updates work

Learn how Operator Lifecycle Manager (OLM) updates the {VirtProductName} Operator and how update channels and approval strategies affect upgrade behavior.

* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, deployed during {product-title} installation, makes external Operators available to your cluster.

* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you update {product-title} to the next minor version. You cannot update {VirtProductName} to the next minor version without first updating {product-title}.
