Bug 1054935 - cpu host-model should permanently encode the CPU definition on first define
Summary: cpu host-model should permanently encode the CPU definition on first define
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-17 19:02 UTC by Cole Robinson
Modified: 2018-10-09 14:54 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-09 14:54:49 UTC
Embargoed:


Attachments (Terms of Use)

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


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