harvester · Yu-Jack · Jan 9, 2026 · Jan 12, 2026 · jillian-maroket · Jan 12, 2026
diff --git a/docs/upgrade/v1-5-x-to-v1-6-x.md b/docs/upgrade/v1-5-x-to-v1-6-x.md
@@ -254,7 +254,15 @@ Before Harvester v1.6.0, the controller patched the MAC address from the VMI int
 
 Starting from v1.6.0, to support the CPU and Memory hot-plug feature and to inform users that certain CPU and memory changes might not take effect immediately, we decided to expose the “RestartRequired” condition in the UI. That’s why this message appears after upgrading Harvester or updating the harvester-ui-extension to v1.6.x.
 
-### 7. Change in Default VLAN Behavior for Secondary Pod Interfaces
+### 7. Virtual Machine Cannot Be Live Migrated to the Target Node
+
+After upgrading Harvester to v1.6.x, KubeVirt may report that some virtual machines are pending restart. These virtual machines cannot be live migrated to a user-specified target node from the UI, until they are restarted. Once restarted, subsequent node-specific live migrations will work.
+
+The workaround is to restart the virtual machine.
+
+Related issue: [#9739](https://github.com/harvester/harvester/issues/9739)
+
+### 8. 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.
 
@@ -263,3 +271,4 @@ This behavior changed in Harvester v1.6.1, which uses v1.8.0 of the CNI bridge p
 The change affects clusters upgraded from v1.5.x to v1.6.1 if the external switch port is configured as an access port sending untagged frames. Updating the external switch configuration to use a trunk port resolves the issue. Pods with secondary interfaces that are attached to untagged networks or associated with VLAN ID 1 are not affected.
 
 Related issue: [#8816](https://github.com/harvester/harvester/issues/8816)
+
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
@@ -254,7 +254,15 @@ Before Harvester v1.6.0, the controller patched the MAC address from the VMI int
 
 Starting from v1.6.0, to support the CPU and Memory hot-plug feature and to inform users that certain CPU and memory changes might not take effect immediately, we decided to expose the “RestartRequired” condition in the UI. That’s why this message appears after upgrading Harvester or updating the harvester-ui-extension to v1.6.x.
 
-### 7.Change in default VLAN Behavior for Secondary Pod Interfaces
+### 7. Virtual Machine Cannot Be Live Migrated to the Target Node
+
+After upgrading Harvester to v1.6.x, KubeVirt may report that some virtual machines are pending restart. These virtual machines cannot be live migrated to a user-specified target node from the UI, until they are restarted. Once restarted, subsequent node-specific live migrations will work.
+
+The workaround is to restart the virtual machine.
-After upgrading Harvester to v1.6.x, KubeVirt may report that some virtual machines are pending restart. These virtual machines cannot be live migrated to a user-specified target node from the UI, until they are restarted. Once restarted, subsequent node-specific live migrations will work.
-
-The workaround is to restart the virtual machine.
+Following an upgrade to v1.6.x, some virtual machines may remain in a _pending restart_ state. These virtual machines cannot be live migrated to the specified target node until they are restarted.
+
+The workaround is to restart the virtual machines. Once restarted, subsequent node-specific live migrations will work.
-After upgrading Harvester to v1.6.x, KubeVirt may report that some virtual machines are pending restart. These virtual machines cannot be live migrated to a user-specified target node from the UI, until they are restarted. Once restarted, subsequent node-specific live migrations will work.
-
-The workaround is to restart the virtual machine.
+Following an upgrade to v1.6.x, some virtual machines may remain in a _pending restart_ state. These virtual machines cannot be live migrated to the specified target node until they are restarted.
+
+The workaround is to restart the virtual machines. Once restarted, subsequent node-specific live migrations will work.
+
+Related issue: [#9739](https://github.com/harvester/harvester/issues/9739)
+
+### 8.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/vm/live-migration.md b/versioned_docs/version-v1.6/vm/live-migration.md
@@ -133,6 +133,12 @@ The **Migrate** menu option is not available in the following situations:
 
 :::
 
+:::caution
+
+Due to a [limitation](https://kubevirt.io/user-guide/user_workloads/vm_rollout_strategies/#restartrequired-condition) in the VM rollout strategy implementation, virtual machines that are pending restart may get live-migrated to a random node, instead of a user-specified target node. The virtual machines must be restarted for all subsequent node-specific live migrations.
-Due to a [limitation](https://kubevirt.io/user-guide/user_workloads/vm_rollout_strategies/#restartrequired-condition) in the VM rollout strategy implementation, virtual machines that are pending restart may get live-migrated to a random node, instead of a user-specified target node. The virtual machines must be restarted for all subsequent node-specific live migrations.
+Due to a [limitation](https://kubevirt.io/user-guide/user_workloads/vm_rollout_strategies/#restartrequired-condition) in the VM rollout strategy implementation, virtual machines that are in a _pending restart_ state may get live-migrated to a random node, instead of the specified target node. The virtual machines must be restarted for subsequent node-specific live migrations to work.
-Due to a [limitation](https://kubevirt.io/user-guide/user_workloads/vm_rollout_strategies/#restartrequired-condition) in the VM rollout strategy implementation, virtual machines that are pending restart may get live-migrated to a random node, instead of a user-specified target node. The virtual machines must be restarted for all subsequent node-specific live migrations.
+Due to a [limitation](https://kubevirt.io/user-guide/user_workloads/vm_rollout_strategies/#restartrequired-condition) in the VM rollout strategy implementation, virtual machines that are in a _pending restart_ state may get live-migrated to a random node, instead of the specified target node. The virtual machines must be restarted for subsequent node-specific live migrations to work.
+
+:::
+
 ![](/img/v1.2/vm/migrate.png)
 
 ## Aborting a Migration

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
@@ -254,7 +254,15 @@ Before Harvester v1.6.0, the controller patched the MAC address from the VMI int
 
 Starting from v1.6.0, to support the CPU and Memory hot-plug feature and to inform users that certain CPU and memory changes might not take effect immediately, we decided to expose the “RestartRequired” condition in the UI. That’s why this message appears after upgrading Harvester or updating the harvester-ui-extension to v1.6.x.
 
-### 7. Change in Default VLAN Behavior for Secondary Pod Interfaces
+### 7. Virtual Machine Cannot Be Live Migrated to the Target Node
+
+After upgrading Harvester to v1.6.x, KubeVirt may report that some virtual machines are pending restart. These virtual machines cannot be live migrated to a user-specified target node from the UI, until they are restarted. Once restarted, subsequent node-specific live migrations will work.
+
+The workaround is to restart the virtual machine.
+
+Related issue: [#9739](https://github.com/harvester/harvester/issues/9739)
+
+### 8. 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.