Bug 2099324 - We cant migrate to newer target node and than return to the source node when using host-model cpu
Summary: We cant migrate to newer target node and than return to the source node when ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Virtualization
Version: 4.10.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.10.5
Assignee: Barak
QA Contact: Denys Shchedrivyi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-06-20 14:57 UTC by Barak
Modified: 2023-11-13 08:16 UTC (History)
6 users (show)

Fixed In Version: hco-bundle-registry-container-v4.10.5-6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-09-06 14:02:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt kubevirt pull 7953 0 None open [release-0.49]Fixing host model support heterogeneus cluster 2022-07-17 07:19:56 UTC
Red Hat Issue Tracker CNV-19225 0 None None None 2023-11-13 08:16:28 UTC
Red Hat Product Errata RHSA-2022:6351 0 None None None 2022-09-06 14:02:25 UTC

Description Barak 2022-06-20 14:57:25 UTC
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:

Comment 3 Denys Shchedrivyi 2022-08-27 00:04:26 UTC
Verified on CNV v4.10.5-6

Comment 10 errata-xmlrpc 2022-09-06 14:02:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Virtualization 4.10.5 Images security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:6351


Note You need to log in before you can comment on or make changes to this bug.