-
Bug
-
Resolution: Done-Errata
-
Major
-
None
-
False
-
-
False
-
CLOSED
-
---
-
---
-
High
-
No
Description of problem:
- We cant migrate to newer target node and than return to the source node when using host-model cpu.
- vmi with host-model can't migrate even when it should
Version-Release number of selected component (if applicable):
How reproducible:
for instance:
(1) if vmi start with hosmodel-cpu in node01 that doesn't have AES feature and than migrate to node02 that has AES we won't be able to migrate back to node01.
also
(2) vmi with host-model can't migrate if the target node does't have the same host model even if the target node support the host-model of the source node and
has all the required features.
Steps to Reproduce (1):
1. Deploy kubevirt in heterogeneous Cluster that has a Node with unique feature
(after deploying kubevirt you can use the following command to know which
features exist in the node: `kubectl get node <node_name> oyaml | grep host
model-required-features ` )
2. Start a vm with host-model cpu in a node without any unique feature
3. migrate to a node with unique feature
4. try to migrate back to the inital node
Actual results:
the migration in step 4 will fail because of a node selector in virt-launcher that shouldn't be there.
Steps to Reproduce (2):
1. Deploy kubevirt in heterogeneous Cluster with at least two nodes with diffrent host-model cpuModel.
(after deploying kubevirt you can use the following command to know which host-model a node has:
`kubectl get node <node_name> -oyaml | grep host-model-cpu.node ` )
2. start a vm with host-model cpu in a node
3. try to migrate it to node that support the source node's host-model cpuModel but with different host-model
Actual results:
the migration will fail because of a node selector in virt-launcher.
Expected results:
The migration should Succeed
Additional info: