1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 21:46:22 +01:00
Files
openshift-docs/modules/virt-runbook-outdatedvirtualmachineinstanceworkloads.adoc
Avital Pinnick 8040dfd796 Update YAML ellipses
Signed-off-by: Avital Pinnick <apinnick@redhat.com>
2023-05-08 11:17:14 +00:00

136 lines
3.6 KiB
Plaintext

// Do not edit this module. It is generated with a script.
// Do not reuse this module. The anchor IDs do not contain a context statement.
// Module included in the following assemblies:
//
// * virt/support/virt-runbooks.adoc
:_content-type: REFERENCE
[id="virt-runbook-OutdatedVirtualMachineInstanceWorkloads"]
= OutdatedVirtualMachineInstanceWorkloads
[discrete]
[id="meaning-outdatedvirtualmachineinstanceworkloads"]
== Meaning
This alert fires when running virtual machine instances (VMIs) in
outdated `virt-launcher` pods are detected 24 hours after the OpenShift
Virtualization control plane has been updated.
[discrete]
[id="impact-outdatedvirtualmachineinstanceworkloads"]
== Impact
Outdated VMIs might not have access to new {VirtProductName}
features.
Outdated VMIs will not receive the security fixes associated with
the `virt-launcher` pod update.
[discrete]
[id="diagnosis-outdatedvirtualmachineinstanceworkloads"]
== Diagnosis
. Identify the outdated VMIs:
+
[source,terminal]
----
$ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces
----
. Check the `KubeVirt` custom resource (CR) to determine whether
`workloadUpdateMethods` is configured in the `workloadUpdateStrategy`
stanza:
+
[source,terminal]
----
$ oc get kubevirt kubevirt --all-namespaces -o yaml
----
. Check each outdated VMI to determine whether it is live-migratable:
+
[source,terminal]
----
$ oc get vmi <vmi> -o yaml
----
+
.Example output
+
[source,yaml]
----
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
# ...
status:
conditions:
- lastProbeTime: null
lastTransitionTime: null
message: cannot migrate VMI which does not use masquerade
to connect to the pod network
reason: InterfaceNotLiveMigratable
status: "False"
type: LiveMigratable
----
[discrete]
[id="mitigation-outdatedvirtualmachineinstanceworkloads"]
== Mitigation
[discrete]
[id="configuring-automated-workload-updates-outdatedvirtualmachineinstanceworkloads"]
=== Configuring automated workload updates
Update the `HyperConverged` CR to enable automatic workload updates.
[discrete]
[id="stopping-a-vm-associated-with-a-non-live-migratable-vmi-outdatedvirtualmachineinstanceworkloads"]
=== Stopping a VM associated with a non-live-migratable VMI
* If a VMI is not live-migratable and if `runStrategy: always` is
set in the corresponding `VirtualMachine` object, you can update the
VMI by manually stopping the virtual machine (VM):
+
[source,terminal]
----
$ virctl stop --namespace <namespace> <vm>
----
A new VMI spins up immediately in an updated `virt-launcher` pod to
replace the stopped VMI. This is the equivalent of a restart action.
NOTE: Manually stopping a _live-migratable_ VM is destructive and
not recommended because it interrupts the workload.
[discrete]
[id="migrating-a-live-migratable-vmi-outdatedvirtualmachineinstanceworkloads"]
=== Migrating a live-migratable VMI
If a VMI is live-migratable, you can update it by creating a `VirtualMachineInstanceMigration`
object that targets a specific running VMI. The VMI is migrated into
an updated `virt-launcher` pod.
. Create a `VirtualMachineInstanceMigration` manifest and save it
as `migration.yaml`:
+
[source,yaml]
----
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
name: <migration_name>
namespace: <namespace>
spec:
vmiName: <vmi_name>
----
. Create a `VirtualMachineInstanceMigration` object to trigger the
migration:
+
[source,terminal]
----
$ oc create -f migration.yaml
----
If you cannot resolve the issue, log in to the
link:https://access.redhat.com[Customer Portal] and open a support case,
attaching the artifacts gathered during the diagnosis procedure.