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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list