Bug 1054935

Summary: cpu host-model should permanently encode the CPU definition on first define
Product: [Community] Virtualization Tools Reporter: Cole Robinson <crobinso>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DEFERRED QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecified   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-09 14:54:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Cole Robinson 2014-01-17 19:02:52 UTC 
I'm thinking of what it will take to make host-model the default cpu mode for VMs in virt-manager. Right now there are still other issues with host-model, like it incorrectly modeling the host CPU, but this is another piece that I think is missing.

The host-model values are filled in every time the VM is run. This could potentially cause a problem on libvirt upgrade, if libvirt changed the logic for generating host-model, or a new CPU feature was added, or similar: the CPU definition would change across reboots, which could cause windows reactivation.

Possible solution is to do the host-model lookup only on the first VM run, and keep it forever. But not sure how that would work exactly.

Maybe this isn't an issue in practice or there's a better alternative...
Comment 1 Cole Robinson 2016-04-10 17:35:15 UTC 
Still an issue with latest code
Comment 2 Cole Robinson 2018-10-09 14:54:49 UTC 
This hasn't really turned out to be an issue any cares about in practice, so i don't think it needs explicit libvirt support. If apps care, they can grab the host-model CPU block from domcapabilities and define it into the XML themselves, which will accomplish the same goal