Bug 1727122

Summary: [libvirt] Safe mechanism for updating CPU models
Product: Red Hat Enterprise Linux 9 Reporter: Eduardo Habkost <ehabkost>
Component: libvirtAssignee: Tim Wiederhake <twiederh>
libvirt sub component: General QA Contact: Luyao Huang <lhuang>
Status: CLOSED DEFERRED Docs Contact:
Severity: unspecified    
Priority: unspecified CC: ailan, chayang, chhu, danken, dyuan, jdenemar, jsuchane, kchamart, knoel, lmen, mvanderw, nanliu, virt-maint, xiaohli, xuzhang, yalzhang
Version: 9.1Keywords: FutureFeature, Reopened, Triaged
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1731918 (view as bug list) Environment:
Last Closed: 2023-07-12 09:47:44 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1697663    
Bug Blocks: 1731918, 1834714, 1942282, 1974560    

Description Eduardo Habkost 2019-07-04 14:05:24 UTC
This bug was initially created as a copy of Bug #1697663

I am copying this bug because: 
Now that versioned CPU models are available in QEMU, we need libvirt APIs that will translate unversioned CPU model names (e.g. "Westmere", "Cascadelake-Server") to versioned names (e.g. "Westmere-v1", "Cascadelake-Server-v2").


Today, we have two limitations in the CPU model system in QEMU and libvirt:

* Updates to CPU models need to be coupled to machine-types, making CPU security updates more risky because they may bring unexpected ABI changes to VMs.

* New features may require updates to host hardware or software (e.g. CPU microcode updates and/or KVM module updates) and can't be added unconditionally to existing CPU models (otherwise existing VM configurations that are runnable may become not runnable).

We need management software to update CPU model configuration in VMs in a convenient way without the limitations above.

Comment 7 RHEL Program Management 2021-08-15 07:26:50 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 8 Jaroslav Suchanek 2021-08-16 09:19:34 UTC
Reopening, since this is very needed feature which depends on qemu-kvm bug 1697663.

Comment 10 John Ferlan 2021-09-09 15:27:27 UTC
Bulk update: Move RHEL-AV bugs to RHEL8.

Added RHV as dependent product, no clone create. If resolution needs to be tested on RHEL9 in the future, then a clone should be created.

Comment 12 RHEL Program Management 2022-02-16 07:31:27 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 22 Jaroslav Suchanek 2023-07-12 09:47:44 UTC
Lets close this one correspondingly to qemu-kvm counterpart (bug 1697663). We will create new set of feature requests, once we get better understanding of what is actually the desired goal and how to implement it through the stack. Thanks.