libvirt cpu-mode = 'Host-model'は、CPUモデルのマッピング中に混乱しますか？
CPUモデル「Intel（R）Xeon（R）CPU E5-2670 v3 @ 2.30GHz」を搭載した物理ホストがあり、CPUインフォに「avx2」フラグがあります。ホストにはkvm/qemuハイパーバイザーとlibvirtが構成されています。ドメインXMLのホストモデルとしてCPUモードを設定しました。ゲストVMはホスト上に作成できます。ゲストVMのCPUモデルを確認すると、「SandyBridge」と表示され、cpuinfoに「avx2」フラグもあります。ただし、「SandyBridge」は「avx2」フラグをサポートしていませんが、「Haswell」モデルはサポートしています。これはホストモデルモードが原因で、libvirtは「Intel（R）Xeon（R）CPU E5-2670 v3 @ 2.30GHz」に最も近いCPUモデルを「SandyBridge」として検索しますが、代わりに「Haswell」と表示されます。それはlibvirtにバグがあることを意味しますか、それともこのシナリオで有効な表現ですか？ libvirtバージョン1.2.2を使用しています
ここで起こっていると思うのは、古いバージョンのlibvirtは、IntelがマイクロコードアップデートでHaswellチップで [〜＃〜] tsx [〜＃〜] を無効にしたという事実を認識していないということです。プロセッサはほぼ確実に今までに受け取っています。 Libvirtは、バージョン 1.2.14 のHaswell-noTSX CPUモデルを認識し、アドバタイズしただけです。 CPUでlibvirtがCPUタイプの検出に使用するいくつかの機能が無効になっているため、誤ってSandyBridgeであると見なします。 libvirtの現在のバージョンでは、Haswell-noTSXとして正しく検出されるはずです。
実際には、VMがHaswellで導入されSandyBridgeに存在しない他の 機能 を使用できないことを除いて、これは実際にはまったく影響しませんが、 手動でこれらを追加 = to your VM定義XML（libvirtをアップグレードできず、本当に必要な場合）。おそらくqemuもアップグレードする必要があることに注意してください。その時点で、おそらくより最新のハイパーバイザー。現在実行しているものはすべて、実行しているハードウェアよりも古いため、常に疑わしい考えです...
Libvirtをアップグレードする必要のない別の回避策を見つけました。 libvirt（/usr/share/libvirt/cpu_map.xml）で使用されるcpuマッピングxmlファイルのHaswellの定義からhleフラグとrtmフラグを削除しました。そして、libvirtプロセスを再起動しました。次に、VMを再起動すると、Haswellとして正しいモデル名が表示されました。