On Tue, Oct 14, 2014 at 01:59:15PM +0300, Itamar Heim wrote:
On 10/14/2014 01:28 PM, Jan-Frode Myklebust wrote:
On Wed, Oct 08, 2014 at 09:49:35AM +0200, Jiri Denemark wrote:
Technically you are correct and even QEMU added this feature to Westmere in April 2013. However, our goal is to provide stable virtual hardware that doesn't change when, e.g., a domain is migrated to another machine (let's ignore the fact we don't currently enforce such stability for CPU models/features because of missing functionality in both QEMU and libvirt). Thus we should not really change existing CPU models. We may be able to do that in the future depending how (if ever) we solve the CPU definition probing in QEMU and how libvirt will make use of it to really enforce stable ABI for guest operating systems.
Right, I see the problem, but am having a bit trouble accepting that all our 20 RHEV-H westmere hypervisors are basicly downgraded to nehalem feature-set permanently because if this, and we probably have to live with these servers for quite some time. If you can't fix existing virtual cpu types, maybe you should add a "westmere-full-feature" cpu type, or similar? And probably also add "rdtscp" which also is missing from the virtual westmere.
if libvirt would change the definition, then a mixed cluster (old and new libvirt) would be broken. it will only work if its a new cpu model
Management apps aren't restricted to using an exact CPU model. They are free to turn on/off extra features relative to the CPU model's bultin features. So using 'rdtscp' doesn't require libvirt to provide a new CPU model - RHEV can just add <feature name='rdtscp'/> to the XML it sends to libvirt if it wants to. Of course you need to consider cross node compat when doing so still. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|