Skip to content

Commit 07305bb

Browse files
ousleypousleyp
committed
CNV-14816: workload updates are no longer tech preview
1 parent 290bcb1 commit 07305bb

File tree

6 files changed

+56
-86
lines changed

6 files changed

+56
-86
lines changed

‎_topic_maps/_topic_map.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2916,10 +2916,10 @@ Topics:
29162916
- Name: Uninstalling OKD Virtualization using the CLI
29172917
File: uninstalling-virt-cli
29182918
Distros: openshift-origin
2919-
- Name: Upgrading OpenShift Virtualization
2919+
- Name: Updating OpenShift Virtualization
29202920
File: upgrading-virt
29212921
Distros: openshift-enterprise
2922-
- Name: Upgrading OKD Virtualization
2922+
- Name: Updating OKD Virtualization
29232923
File: upgrading-virt
29242924
Distros: openshift-origin
29252925
- Name: Additional security privileges granted for kubevirt-controller and virt-launcher

‎modules/virt-about-upgrading-virt.adoc‎

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -2,29 +2,30 @@
22
//
33
// * virt/upgrading-virt.adoc
44

5+
:_content-type: CONCEPT
56
[id="virt-about-upgrading-virt_{context}"]
6-
= About upgrading {VirtProductName}
7+
= About updating {VirtProductName}
78

89
* 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.
910
10-
* OLM provides z-stream and minor version updates for {VirtProductName}. Minor version updates become available when you upgrade {product-title} to the next minor version. You cannot upgrade {VirtProductName} to the next minor version without first upgrading {product-title}.
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}.
1112
1213
* {VirtProductName} subscriptions use a single update channel that is named *stable*. The *stable* channel ensures that your {VirtProductName} and {product-title} versions are compatible.
1314
14-
* If your subscription's approval strategy is set to *Automatic*, the upgrade 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}.
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}.
1516
1617
** 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.
1718

1819
* The amount of time an update takes to complete depends on your network
1920
connection. Most automatic updates complete within fifteen minutes.
2021
21-
* Upgrading does not interrupt network connections.
22+
* Updating {VirtProductName} does not interrupt network connections.
2223
23-
* Data volumes and their associated persistent volume claims are preserved during upgrade.
24+
* Data volumes and their associated persistent volume claims are preserved during update.
2425
2526
[IMPORTANT]
2627
====
27-
If you have virtual machines running that use hostpath provisioner storage, they cannot be live migrated and might block an {product-title} cluster upgrade.
28+
If you have virtual machines running that use hostpath provisioner storage, they cannot be live migrated and might block an {product-title} cluster update.
2829
29-
As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster upgrade. Remove the `evictionStrategy: LiveMigrate` field and set the `runStrategy` field to `Always`.
30+
As a workaround, you can reconfigure the virtual machines so that they can be powered off automatically during a cluster update. Remove the `evictionStrategy: LiveMigrate` field and set the `runStrategy` field to `Always`.
3031
====

‎modules/virt-about-workload-updates.adoc‎

Lines changed: 37 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -2,26 +2,53 @@
22
//
33
// * virt/upgrading-virt.adoc
44

5+
:_content-type: CONCEPT
56
[id="virt-about-workload-updates_{context}"]
67
= About workload updates
78

8-
* When you upgrade {VirtProductName}, virtual machine workloads including `libvirt`, `virt-launcher`, and `qemu` update automatically if they support live migration.
9-
+
9+
When you update {VirtProductName}, virtual machine workloads, including `libvirt`, `virt-launcher`, and `qemu`, update automatically if they support live migration.
10+
1011
[NOTE]
1112
====
1213
Each virtual machine has a `virt-launcher` pod that runs the virtual machine
13-
instance. The `virt-launcher` pod runs an instance of `libvirt`, which is
14-
used to manage the virtual machine process.
14+
instance (VMI). The `virt-launcher` pod runs an instance of `libvirt`, which is
15+
used to manage the virtual machine (VM) process.
1516
====
1617

17-
** There are two available workload update methods: `LiveMigrate` and `Evict`. By default, only `LiveMigrate` is enabled, which means that:
18+
You can configure how workloads are updated by editing the `spec.workloadUpdateStrategy` stanza of the `HyperConverged` custom resource (CR). There are two available workload update methods: `LiveMigrate` and `Evict`.
19+
20+
Because the `Evict` method shuts down VMI pods, only the `LiveMigrate` update strategy is enabled by default.
21+
22+
When `LiveMigrate` is the only update strategy enabled:
23+
24+
* VMIs that support live migration are migrated during the update process. The VM guest moves into a new pod with the updated components enabled.
25+
26+
* VMIs that do not support live migration are not disrupted or updated.
27+
28+
** If a VMI has the `LiveMigrate` eviction strategy but does not support live migration, it is not updated.
29+
30+
If you enable both `LiveMigrate` and `Evict`:
31+
32+
* VMIs that support live migration use the `LiveMigrate` update strategy.
1833
19-
*** Virtual machine instances (VMIs) that support live migration are migrated during the upgrade process.
34+
* VMIs that do not support live migration use the `Evict` update strategy. If a VMI is controlled by a `VirtualMachine` object that has a `runStrategy` value of `always`, a new VMI is created in a new pod with updated components.
2035
21-
*** VMIs are not updated at all if the following conditions are both true:
36+
[discrete]
37+
[id="migration-attempts-timeouts_{context}"]
38+
== Migration attempts and timeouts
39+
40+
When updating workloads, live migration fails if a pod is in the `Pending` state for the following periods:
41+
42+
5 minutes:: If the pod is pending because it is `Unschedulable`.
43+
44+
15 minutes:: If the pod is stuck in the pending state for any reason.
45+
46+
When a VMI fails to migrate, the `virt-controller` tries to migrate it again. It repeats this process until all migratable VMIs are running on new `virt-launcher` pods. If a VMI is improperly configured, however, these attempts can repeat indefinitely.
47+
48+
[NOTE]
49+
====
50+
Each attempt corresponds to a migration object. Only the five most recent attempts are held in a buffer. This prevents migration objects from accumulating on the system while retaining information for debugging.
51+
====
2252

23-
**** The VMI does not support live migration.
2453

25-
**** The VMI is configured to use the `LiveMigrate` eviction strategy.
2654

27-
** You can configure how workloads are updated by editing the `spec.workloadUpdateStrategy` stanza of the `HyperConverged` custom resource (CR).

‎modules/virt-configuring-workload-update-methods.adoc‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@
22
//
33
// * virt/upgrading-virt.adoc
44

5+
:_content-type: PROCEDURE
56
[id="virt-configuring-workload-update-methods_{context}"]
67
= Configuring workload update methods
78

‎modules/virt-opting-out-workload-updates.adoc‎

Lines changed: 0 additions & 42 deletions
This file was deleted.

‎virt/upgrading-virt.adoc‎

Lines changed: 8 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
[id="upgrading-virt"]
33
include::modules/virt-document-attributes.adoc[]
44
include::modules/common-attributes.adoc[]
5-
= Upgrading {VirtProductName}
5+
= Updating {VirtProductName}
66
:context: upgrading-virt
77

88
toc::[]
@@ -14,43 +14,26 @@ include::modules/virt-about-upgrading-virt.adoc[leveloffset=+1]
1414
[id="configuring-workload-updates_upgrading-virt"]
1515
== Configuring automatic workload updates
1616

17-
// Uncomment this in 4.10 and replace prefix
18-
//[NOTE]
19-
//====
20-
//Automatic workload updates are enabled by default in {VirtProductName} {VirtVersion}. You can opt out by following a ../virt/upgrading-virt.adoc#virt-opting-out-workload-updates_upgrading-virt[workaround to disable this feature] before you upgrade to {VirtVersion}.
21-
//====
22-
23-
// Remove TP module in 4.10
24-
ifdef::openshift-enterprise[]
25-
:FeatureName: Automatically updating workloads
26-
include::snippets/technology-preview.adoc[leveloffset=+2]
27-
endif::[]
28-
29-
// Uncomment this in 4.10 if it is still relevant (describes default behavior)
30-
//include::modules/virt-about-workload-updates.adoc[leveloffset=+2]
17+
include::modules/virt-about-workload-updates.adoc[leveloffset=+2]
3118

3219
include::modules/virt-configuring-workload-update-methods.adoc[leveloffset=+2]
3320

34-
// Uncomment and/or change this procedure in 4.10
35-
//include::modules/virt-opting-out-workload-updates.adoc[leveloffset=+2]
36-
3721
[id="approving-operator-upgrades_upgrading-virt"]
38-
== Approving pending Operator upgrades
22+
== Approving pending Operator updates
3923

4024
include::modules/olm-approving-pending-upgrade.adoc[leveloffset=+2]
4125

4226
[id="monitoring-upgrade-status_upgrading-virt"]
43-
== Monitoring upgrade status
27+
== Monitoring update status
4428

4529
include::modules/virt-monitoring-upgrade-status.adoc[leveloffset=+2]
4630

4731
include::modules/virt-viewing-outdated-workloads.adoc[leveloffset=+2]
4832

49-
// Uncomment this in 4.10
50-
//[NOTE]
51-
//====
52-
//xref:../virt/upgrading-virt.adoc#configuring-workload-updates_upgrading-virt[Configure workload updates] to ensure that VMIs update automatically.
53-
//====
33+
[NOTE]
34+
====
35+
xref:../virt/upgrading-virt.adoc#configuring-workload-updates_upgrading-virt[Configure workload updates] to ensure that VMIs update automatically.
36+
====
5437

5538
[id="additional-resources_upgrading-virt"]
5639
== Additional resources

0 commit comments

Comments
 (0)