From c70980be194f3730a0d4df0723004f84c0f65837 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Wed, 21 Jan 2026 14:36:23 +0800 Subject: [PATCH 1/7] docs: add known ipred-ctrl issue for speicfic cpu model Signed-off-by: Jack Yu --- docs/upgrade/v1-5-x-to-v1-6-x.md | 22 ++++++++++++++++++- .../version-v1.6/upgrade/v1-5-x-to-v1-6-x.md | 22 ++++++++++++++++++- .../version-v1.7/upgrade/v1-5-x-to-v1-6-x.md | 22 ++++++++++++++++++- 3 files changed, 63 insertions(+), 3 deletions(-) diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md index 16289773ee..19807bfc5b 100644 --- a/docs/upgrade/v1-5-x-to-v1-6-x.md +++ b/docs/upgrade/v1-5-x-to-v1-6-x.md @@ -262,7 +262,27 @@ The workaround is to restart the virtual machines. Once restarted, subsequent no Related issue: [#9739](https://github.com/harvester/harvester/issues/9739) -### 8. Change in Default VLAN Behavior for Secondary Pod Interfaces +### 8. `cpu-feature.node.kubevirt.io/ipred-ctrl=true` CPU Feature Appears During Upgrade + +When upgrading from v1.5.x to v1.6.x, Harvester live migrates virtual machines to another node to complete the node upgrade. During this process, if your CPU model is in the following list, the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature temporarily appears until the upgrade is complete. + +- Intel(R) Xeon(R) Gold 5418Y +- Intel(R) Xeon(R) Silver 4509Y + +Because the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature is no longer available after the upgrade, these virtual machines cannot be live migrated because of the mismatched node selector. + +To resolve this issue, use one of the following options: + +**Before the upgrade:** + +- **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). + +**After the upgrade:** + +- Reboot the virtual machines. + +### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces In v1.6.0 and earlier versions, pods with secondary network interfaces (such as VM networks and storage networks) were automatically assigned to VLAN ID 1 and the VLAN ID configured in the VLAN network. This dual-VLAN ID configuration allowed the Harvester network bridge to forward untagged traffic to the veth interfaces of these pods. diff --git a/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md b/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md index e60ad887de..ef7470db2c 100644 --- a/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md +++ b/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md @@ -262,7 +262,27 @@ The workaround is to restart the virtual machines. Once restarted, subsequent no Related issue: [#9739](https://github.com/harvester/harvester/issues/9739) -### 8.Change in default VLAN Behavior for Secondary Pod Interfaces +### 8. `cpu-feature.node.kubevirt.io/ipred-ctrl=true` CPU Feature Appears During Upgrade + +When upgrading from v1.5.x to v1.6.x, Harvester live migrates virtual machines to another node to complete the node upgrade. During this process, if your CPU model is in the following list, the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature temporarily appears until the upgrade is complete. + +- Intel(R) Xeon(R) Gold 5418Y +- Intel(R) Xeon(R) Silver 4509Y + +Because the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature is no longer available after the upgrade, these virtual machines cannot be live migrated because of the mismatched node selector. + +To resolve this issue, use one of the following options: + +**Before the upgrade:** + +- **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). + +**After the upgrade:** + +- Reboot the virtual machines. + +### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces In v1.6.0 and earlier versions, pods with secondary network interfaces (such as VM networks and storage networks) were automatically assigned to VLAN ID 1 and the VLAN ID configured in the VLAN network. This dual-VLAN ID configuration allowed the Harvester network bridge to forward untagged traffic to the veth interfaces of these pods. diff --git a/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md b/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md index 412de61f3b..4ecaeb6978 100644 --- a/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md +++ b/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md @@ -262,7 +262,27 @@ The workaround is to restart the virtual machines. Once restarted, subsequent no Related issue: [#9739](https://github.com/harvester/harvester/issues/9739) -### 8. Change in Default VLAN Behavior for Secondary Pod Interfaces +### 8. `cpu-feature.node.kubevirt.io/ipred-ctrl=true` CPU Feature Appears During Upgrade + +When upgrading from v1.5.x to v1.6.x, Harvester live migrates virtual machines to another node to complete the node upgrade. During this process, if your CPU model is in the following list, the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature temporarily appears until the upgrade is complete. + +- Intel(R) Xeon(R) Gold 5418Y +- Intel(R) Xeon(R) Silver 4509Y + +Because the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature is no longer available after the upgrade, these virtual machines cannot be live migrated because of the mismatched node selector. + +To resolve this issue, use one of the following options: + +**Before the upgrade:** + +- **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). + +**After the upgrade:** + +- Reboot the virtual machines. + +### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces In v1.6.0 and earlier versions, pods with secondary network interfaces (such as VM networks and storage networks) were automatically assigned to VLAN ID 1 and the VLAN ID configured in the VLAN network. This dual-VLAN ID configuration allowed the Harvester network bridge to forward untagged traffic to the veth interfaces of these pods. From 36a2a383e3773b1e72a7a84974a86adaadd781a4 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Thu, 22 Jan 2026 09:45:40 +0800 Subject: [PATCH 2/7] Update docs/upgrade/v1-5-x-to-v1-6-x.md Co-authored-by: Gaurav Mehta Signed-off-by: Jack Yu --- docs/upgrade/v1-5-x-to-v1-6-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md index 19807bfc5b..68b3a3e165 100644 --- a/docs/upgrade/v1-5-x-to-v1-6-x.md +++ b/docs/upgrade/v1-5-x-to-v1-6-x.md @@ -276,7 +276,7 @@ To resolve this issue, use one of the following options: **Before the upgrade:** - **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). -- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex but useful if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). **After the upgrade:** From ea0eb910d6a6f589633c5554a7d5f72f67ddc8cb Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Thu, 22 Jan 2026 09:57:47 +0800 Subject: [PATCH 3/7] docs: remove the reboot way because it does not happen Signed-off-by: Jack Yu --- docs/upgrade/v1-5-x-to-v1-6-x.md | 4 ---- versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md | 4 ---- versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md | 4 ---- 3 files changed, 12 deletions(-) diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md index 68b3a3e165..09d0b0a890 100644 --- a/docs/upgrade/v1-5-x-to-v1-6-x.md +++ b/docs/upgrade/v1-5-x-to-v1-6-x.md @@ -278,10 +278,6 @@ To resolve this issue, use one of the following options: - **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). - **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex but useful if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). -**After the upgrade:** - -- Reboot the virtual machines. - ### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces In v1.6.0 and earlier versions, pods with secondary network interfaces (such as VM networks and storage networks) were automatically assigned to VLAN ID 1 and the VLAN ID configured in the VLAN network. This dual-VLAN ID configuration allowed the Harvester network bridge to forward untagged traffic to the veth interfaces of these pods. diff --git a/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md b/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md index ef7470db2c..a5506af69b 100644 --- a/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md +++ b/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md @@ -278,10 +278,6 @@ To resolve this issue, use one of the following options: - **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). - **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). -**After the upgrade:** - -- Reboot the virtual machines. - ### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces In v1.6.0 and earlier versions, pods with secondary network interfaces (such as VM networks and storage networks) were automatically assigned to VLAN ID 1 and the VLAN ID configured in the VLAN network. This dual-VLAN ID configuration allowed the Harvester network bridge to forward untagged traffic to the veth interfaces of these pods. diff --git a/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md b/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md index 4ecaeb6978..a6f56d5122 100644 --- a/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md +++ b/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md @@ -278,10 +278,6 @@ To resolve this issue, use one of the following options: - **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). - **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). -**After the upgrade:** - -- Reboot the virtual machines. - ### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces In v1.6.0 and earlier versions, pods with secondary network interfaces (such as VM networks and storage networks) were automatically assigned to VLAN ID 1 and the VLAN ID configured in the VLAN network. This dual-VLAN ID configuration allowed the Harvester network bridge to forward untagged traffic to the veth interfaces of these pods. From a289814bf0a3f25f39108e01efc18fcde97a5d7e Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Fri, 23 Jan 2026 10:58:56 +0800 Subject: [PATCH 4/7] Update docs/upgrade/v1-5-x-to-v1-6-x.md Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Jack Yu --- docs/upgrade/v1-5-x-to-v1-6-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md index 09d0b0a890..7c612886a4 100644 --- a/docs/upgrade/v1-5-x-to-v1-6-x.md +++ b/docs/upgrade/v1-5-x-to-v1-6-x.md @@ -264,7 +264,7 @@ Related issue: [#9739](https://github.com/harvester/harvester/issues/9739) ### 8. `cpu-feature.node.kubevirt.io/ipred-ctrl=true` CPU Feature Appears During Upgrade -When upgrading from v1.5.x to v1.6.x, Harvester live migrates virtual machines to another node to complete the node upgrade. During this process, if your CPU model is in the following list, the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature temporarily appears until the upgrade is complete. +Harvester live migrates virtual machines to ensure zero downtime during node upgrades. If your cluster uses any of the following CPU models, you may notice a temporary feature flag (`cpu-feature.node.kubevirt.io/ipred-ctrl=true`) appear while the upgrade is in progress. - Intel(R) Xeon(R) Gold 5418Y - Intel(R) Xeon(R) Silver 4509Y From 98563c83ff8bdbdb42a8de70c971bd0f0139400d Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Fri, 23 Jan 2026 10:59:05 +0800 Subject: [PATCH 5/7] Update docs/upgrade/v1-5-x-to-v1-6-x.md Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Jack Yu --- docs/upgrade/v1-5-x-to-v1-6-x.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md index 7c612886a4..bf3e1298d4 100644 --- a/docs/upgrade/v1-5-x-to-v1-6-x.md +++ b/docs/upgrade/v1-5-x-to-v1-6-x.md @@ -269,7 +269,7 @@ Harvester live migrates virtual machines to ensure zero downtime during node upg - Intel(R) Xeon(R) Gold 5418Y - Intel(R) Xeon(R) Silver 4509Y -Because the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature is no longer available after the upgrade, these virtual machines cannot be live migrated because of the mismatched node selector. +While this feature flag is automatically removed from nodes after the upgrade, the corresponding node selector is retained in the virtual machine configuration. This mismatch between the virtual machine's requirements and the node's labels causes subsequent live migrations to fail. To resolve this issue, use one of the following options: From 0b01dfd905ed2e5f86b27a08d3e859371b72d195 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Fri, 23 Jan 2026 10:59:13 +0800 Subject: [PATCH 6/7] Update docs/upgrade/v1-5-x-to-v1-6-x.md Co-authored-by: Jillian Maroket <67180770+jillian-maroket@users.noreply.github.com> Signed-off-by: Jack Yu --- docs/upgrade/v1-5-x-to-v1-6-x.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md index bf3e1298d4..d60be27244 100644 --- a/docs/upgrade/v1-5-x-to-v1-6-x.md +++ b/docs/upgrade/v1-5-x-to-v1-6-x.md @@ -271,12 +271,11 @@ Harvester live migrates virtual machines to ensure zero downtime during node upg While this feature flag is automatically removed from nodes after the upgrade, the corresponding node selector is retained in the virtual machine configuration. This mismatch between the virtual machine's requirements and the node's labels causes subsequent live migrations to fail. -To resolve this issue, use one of the following options: +To resolve this issue, perform either of the following actions _before starting the upgrade_: -**Before the upgrade:** +- **Option 1:** [Configure a common CPU model](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration) for the virtual machines. -- **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). -- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex but useful if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade. While more complex, this option is useful if the virtual machines cannot be rebooted. For more information, see [Troubleshooting VM Live Migration Issues Caused by Node Selectors](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). ### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces From 24a36c80c685784c873ae3edcab7d23784752602 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Fri, 23 Jan 2026 11:02:50 +0800 Subject: [PATCH 7/7] docs: sync to v1.6 and v1.7 Signed-off-by: Jack Yu --- .../version-v1.6/upgrade/v1-5-x-to-v1-6-x.md | 11 +++++------ .../version-v1.7/upgrade/v1-5-x-to-v1-6-x.md | 11 +++++------ 2 files changed, 10 insertions(+), 12 deletions(-) diff --git a/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md b/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md index a5506af69b..98e8178a74 100644 --- a/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md +++ b/versioned_docs/version-v1.6/upgrade/v1-5-x-to-v1-6-x.md @@ -264,19 +264,18 @@ Related issue: [#9739](https://github.com/harvester/harvester/issues/9739) ### 8. `cpu-feature.node.kubevirt.io/ipred-ctrl=true` CPU Feature Appears During Upgrade -When upgrading from v1.5.x to v1.6.x, Harvester live migrates virtual machines to another node to complete the node upgrade. During this process, if your CPU model is in the following list, the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature temporarily appears until the upgrade is complete. +Harvester live migrates virtual machines to ensure zero downtime during node upgrades. If your cluster uses any of the following CPU models, you may notice a temporary feature flag (`cpu-feature.node.kubevirt.io/ipred-ctrl=true`) appear while the upgrade is in progress. - Intel(R) Xeon(R) Gold 5418Y - Intel(R) Xeon(R) Silver 4509Y -Because the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature is no longer available after the upgrade, these virtual machines cannot be live migrated because of the mismatched node selector. +While this feature flag is automatically removed from nodes after the upgrade, the corresponding node selector is retained in the virtual machine configuration. This mismatch between the virtual machine's requirements and the node's labels causes subsequent live migrations to fail. -To resolve this issue, use one of the following options: +To resolve this issue, perform either of the following actions _before starting the upgrade_: -**Before the upgrade:** +- **Option 1:** [Configure a common CPU model](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration) for the virtual machines. -- **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). -- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade. While more complex, this option is useful if the virtual machines cannot be rebooted. For more information, see [Troubleshooting VM Live Migration Issues Caused by Node Selectors](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). ### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces diff --git a/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md b/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md index a6f56d5122..25e16ecf64 100644 --- a/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md +++ b/versioned_docs/version-v1.7/upgrade/v1-5-x-to-v1-6-x.md @@ -264,19 +264,18 @@ Related issue: [#9739](https://github.com/harvester/harvester/issues/9739) ### 8. `cpu-feature.node.kubevirt.io/ipred-ctrl=true` CPU Feature Appears During Upgrade -When upgrading from v1.5.x to v1.6.x, Harvester live migrates virtual machines to another node to complete the node upgrade. During this process, if your CPU model is in the following list, the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature temporarily appears until the upgrade is complete. +Harvester live migrates virtual machines to ensure zero downtime during node upgrades. If your cluster uses any of the following CPU models, you may notice a temporary feature flag (`cpu-feature.node.kubevirt.io/ipred-ctrl=true`) appear while the upgrade is in progress. - Intel(R) Xeon(R) Gold 5418Y - Intel(R) Xeon(R) Silver 4509Y -Because the `cpu-feature.node.kubevirt.io/ipred-ctrl=true` feature is no longer available after the upgrade, these virtual machines cannot be live migrated because of the mismatched node selector. +While this feature flag is automatically removed from nodes after the upgrade, the corresponding node selector is retained in the virtual machine configuration. This mismatch between the virtual machine's requirements and the node's labels causes subsequent live migrations to fail. -To resolve this issue, use one of the following options: +To resolve this issue, perform either of the following actions _before starting the upgrade_: -**Before the upgrade:** +- **Option 1:** [Configure a common CPU model](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration) for the virtual machines. -- **Option 1:** Configure a CPU model for the virtual machines using [this guideline](https://harvesterhci.io/kb/setup_common_cpu_model_for_vm_live_migration). -- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade completes. This option is more complex if the virtual machines cannot be rebooted. For more information, see the [knowledge base article](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). +- **Option 2:** Stop the KubeVirt labeller by [adding the `node-labeller.kubevirt.io/skip-node` annotation to the nodes](https://kubevirt.io/user-guide/compute/virtual_hardware/#labeling-nodes-with-cpu-models-cpu-features-and-machine-types), and then remove the annotation after the upgrade. While more complex, this option is useful if the virtual machines cannot be rebooted. For more information, see [Troubleshooting VM Live Migration Issues Caused by Node Selectors](https://harvesterhci.io/kb/troubleshooting_vm_scheduling_issues_nodeselector). ### 9. Change in Default VLAN Behavior for Secondary Pod Interfaces