Skip to content

[virtualization] Virtualization Operator Upgrade Impact on Running Virtual Machines #151

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jing2uo wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[virtualization] Virtualization Operator Upgrade Impact on Running Virtual Machines #151

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions ...solutions/Virtualization_Operator_Upgrade_Impact_on_Running_Virtual_Machines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
kind:
- Information
products:
- Alauda Container Platform
ProductsVersion:
- 4.1.0,4.2.x
---
## Issue

Does upgrading the ACP Virtualization Operator, or upgrading ACP itself, shut down or pause virtual machines that are currently running? And does it put applications running inside those VMs at risk?

## Resolution

Upgrading the Virtualization Operator does not restart or pause running VMs on its own. The operator only reconciles its controllers and CRDs; existing `virt-launcher` pods — and the guest workloads inside them — keep running across the operator upgrade itself.

Cluster-wide maintenance that occurs as part of an ACP upgrade can still require VMs to leave the node being worked on. That movement is handled by KubeVirt live migration, which you opt into on the VM spec:

```yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
template:
spec:
evictionStrategy: LiveMigrate
```

With `LiveMigrate`, KubeVirt transfers the running VM to another eligible node before the source node is drained. Guest memory and CPU state are preserved, so applications inside the VM continue without disconnection provided the workload tolerates a brief CPU-quiesce window at handover time.

VMs that declare `evictionStrategy: None`, or that omit the field entirely, are held in place while their node is drained and will be cold-restarted only if you explicitly allow it.

Before upgrading the Virtualization Operator, review the release notes for the target version. Some releases document migration constraints — for example, changes in reported CPU models, storage class requirements, or network-attachment semantics — that are best addressed in advance rather than mid-upgrade.
Loading