+++ This bug was initially created as a clone of Bug #1213053 +++ Description of problem: As bug 1182650 says, Haswell and Broadwell processors are patched to disable TSX instructions according to erratum released by Intel. This introduces VM incompatibility between Haswell processors with TSX and without TSX when explicitly specified as cpumodel='Haswell'. The upstream qemu introduced new cpu models, Haswell-noTSX and Broadwell-noTSX namely to address this issue. Bug 1182650 fixes the problem in the libvirt part. This bug intends to address qemu. Here's a link to the upstream commit: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=a356850b80b3d13b2ef737dad2acb05e6da03753 I believe that the same issue affects RHEL6, which would need to keep running on TSX-less hosts for years to come.
Closing as duplicate of 1186405, which is CLOSED/WONTFIX. You can find a workaround in https://bugzilla.redhat.com/show_bug.cgi?id=1186405#c5 You requested the z-stream flag for this BZ... So if you don't agree with the WONTFIX, please ellaborate on the reasons for that. *** This bug has been marked as a duplicate of bug 1186405 ***
Vdsm can report model_Haswell-noTSX and model_Broadwell-noTSX flags on el6 if it finds "SandyBridge + extra features" on the host, so that Engine can make use of these CPUs. The logic can sit also in Engine, too.
(In reply to Dan Kenigsberg from comment #2) > Vdsm can report model_Haswell-noTSX and model_Broadwell-noTSX flags on el6 > if it finds "SandyBridge + extra features" on the host, so that Engine can > make use of these CPUs. The logic can sit also in Engine, too. if you're willing to take in this hack then it's possible, however doing this in libvirt makes much more sense to me. There they map flags to models. Would that be feasible?
considering we're getting closer to 3.6 and there are no customer reports (surprisingly, though) I'm closing the request