You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every even-numbered minor version of {product-title}, including 4.10 and 4.12, is an Extended Update Support (EUS) version. However, because Kubernetes design mandates serial minor version updates, you cannot directly update from one EUS version to the next.
10
10
@@ -14,8 +14,8 @@ When the {product-title} update succeeds, the corresponding update for {VirtProd
14
14
15
15
For more information about EUS versions, see the link:https://access.redhat.com/support/policy/updates/openshift[Red Hat OpenShift Container Platform Life Cycle Policy].
16
16
17
-
[id="preparing-to-update_{context}"]
18
-
== Preparing to update
17
+
[id="prerequisites_{context}"]
18
+
== Prerequisites
19
19
20
20
Before beginning a Control Plane Only update, you must:
Copy file name to clipboardExpand all lines: modules/virt-about-upgrading-virt.adoc
+23-6Lines changed: 23 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -6,22 +6,32 @@
6
6
[id="virt-about-upgrading-virt_{context}"]
7
7
= About updating {VirtProductName}
8
8
9
-
* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, which is deployed during {product-title} installation, makes external Operators available to your cluster.
9
+
When you install {VirtProductName}, you select an update channel and an approval strategy. The update channel determines the versions that {VirtProductName} will be updated to. The approval strategy setting determines whether updates occur automatically or require manual approval. Both settings can impact supportability.
10
+
11
+
[id="recommended-settings_{context}"]
12
+
== Recommended settings
13
+
14
+
To maintain a supportable environment, use the following settings:
10
15
11
-
* 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}.
16
+
* Update channel: *stable*
17
+
* Approval strategy: *Automatic*
12
18
13
-
* {VirtProductName} subscriptions use a single update channel that is named *stable*. The*stable* channelensures that your {VirtProductName} and {product-title} versions are compatible.
19
+
With these settings, the update process automatically starts when a new version of the Operator is available in the *stable* channel. This ensures that your {VirtProductName} and {product-title} versions remain compatible, and that your version of {VirtProductName} is suitable for production environments.
14
20
15
-
* If your subscription's approval strategy is set to *Automatic*, the update process starts as soon as a new version of the Operator is available in the *stable* channel. It is highly recommended to use the *Automatic* approval strategy to maintain a supportable environment. Each minor version of {VirtProductName} is only supported if you run the corresponding {product-title} version. For example, you must run {VirtProductName}{VirtVersion} on {product-title}{VirtVersion}.
21
+
[NOTE]
22
+
====
23
+
Each minor version of {VirtProductName} is supported only if you run the corresponding {product-title} version. For example, you must run {VirtProductName} {VirtVersion} on {product-title} {VirtVersion}.
24
+
====
16
25
17
-
** Though it is possible to select the *Manual* approval strategy, this is not recommended because it risks the supportability and functionality of your cluster. With the *Manual* approval strategy, you must manually approve every pending update. If {product-title} and {VirtProductName} updates are out of sync, your cluster becomes unsupported.
26
+
[id="what-to-expect_{context}"]
27
+
== What to expect
18
28
19
29
* The amount of time an update takes to complete depends on your network
20
30
connection. Most automatic updates complete within fifteen minutes.
21
31
22
32
* Updating {VirtProductName} does not interrupt network connections.
23
33
24
-
* Data volumes and their associated persistent volume claims are preserved during update.
34
+
* Data volumes and their associated persistent volume claims are preserved during an update.
25
35
26
36
ifndef::openshift-rosa,openshift-dedicated[]
27
37
[IMPORTANT]
@@ -39,3 +49,10 @@ If you have virtual machines running that use AWS Elastic Block Store (EBS) stor
39
49
As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster update. Set the `evictionStrategy` field to `None` and the `runStrategy` field to `Always`.
40
50
====
41
51
endif::openshift-rosa,openshift-dedicated[]
52
+
53
+
[id="how-updates-work_{context}"]
54
+
== How updates work
55
+
56
+
* Operator Lifecycle Manager (OLM) manages the lifecycle of the {VirtProductName} Operator. The Marketplace Operator, which is deployed during {product-title} installation, makes external Operators available to your cluster.
57
+
58
+
* 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}.
Copy file name to clipboardExpand all lines: modules/virt-about-workload-updates.adoc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
:_mod-docs-content-type: CONCEPT
6
6
[id="virt-about-workload-updates_{context}"]
7
-
= About workload updates
7
+
= VM workload updates
8
8
9
9
When you update {VirtProductName}, virtual machine workloads, including `libvirt`, `virt-launcher`, and `qemu`, update automatically if they support live migration.
You can change the update channel and approval strategy for your {VirtProductName} Operator subscription by using the web console.
10
+
11
+
.Prerequisites
12
+
13
+
* You have installed the {VirtProductName} Operator.
14
+
* You have administrator permissions.
15
+
16
+
.Procedure
17
+
18
+
. Click *Operators*->*Installed Operators*.
19
+
20
+
. Select *{VirtProductName}* from the list.
21
+
22
+
. Click the *Subscription* tab.
23
+
24
+
. In the *Subscription details* section, click the setting that you want to change. For example, to change the approval strategy from *Manual* to *Automatic*, click *Manual*.
25
+
26
+
. In the window that opens, select the new update channel or approval strategy.
If you use the *Manual* approval strategy, you must manually approve every pending update. If {product-title} and {VirtProductName} updates are out of sync, your cluster becomes unsupported. To avoid risking the supportability and functionality of your cluster, use the *Automatic* approval strategy.
10
+
11
+
If you must use the *Manual* approval strategy, maintain a supportable cluster by approving pending Operator updates as soon as they become available.
Copy file name to clipboardExpand all lines: modules/virt-monitoring-upgrade-status.adoc
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -4,9 +4,9 @@
4
4
5
5
:_mod-docs-content-type: PROCEDURE
6
6
[id="virt-monitoring-upgrade-status_{context}"]
7
-
= Monitoring {VirtProductName} upgrade status
7
+
= Monitoring update status
8
8
9
-
To monitor the status of a {VirtProductName} Operator upgrade, watch the cluster service version (CSV) `PHASE`. You can also monitor the CSV conditions in the web console or by running the command provided here.
9
+
To monitor the status of a {VirtProductName} Operator update, watch the cluster service version (CSV) `PHASE`. You can also monitor the CSV conditions in the web console or by running the command provided here.
Copy file name to clipboardExpand all lines: modules/virt-rhel-9.adoc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
:_mod-docs-content-type: CONCEPT
6
6
[id="virt-rhel-9_{context}"]
7
-
= {VirtProductName} on {op-system-base} 9
7
+
= {op-system-base} 9 compatibility
8
8
9
9
{VirtProductName}{VirtVersion} is based on {op-system-base-full} 9. You can update to {VirtProductName}{VirtVersion} from a version that was based on {op-system-base} 8 by following the standard {VirtProductName} update procedure. No additional steps are required.
Learn more about xref:../../updating/updating_a_cluster/control-plane-only-update.adoc#control-plane-only-update[Performing a Control Plane Only update].
The *stable* release channel and the *Automatic* approval strategy are recommended for most {VirtProductName} installations. Use other settings only if you understand the risks.
0 commit comments