☰

100% CPU 使用率と virsh 移行後に中断

tag-icon • tag-icon kvm zfs migration drbd
100% CPU 使用率と virsh 移行後に中断

ganeti私はZFS + DRBD +ライブマイグレーションを試みてきました（再利用する前に、独自の自動化スクリプトを作成してopenstackを書くのに十分なことを理解したいcinder）。共有ストレージにZFS + DRBD（デュアルマスターモード）があります。

しかし、リアルタイムの移行は物語全体の一部に過ぎません。

libvirt と drbd 構成が同じ 2 つのホストがあり、同じ VM ZVOL プライベート「ボリューム」プール (両方とも 2x1TB ミラーリング プール - 古いバックアップ プールの一部の古いディスクを再利用) と同じ VM 構成 (「d-テスト」)

  • 「indra」は、ASUS Sabertooth 990FX m/bで駆動される16GB RAMを搭載したAMD FX-8150です。

    • CPU ロゴ:fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

  • 「surya」は8GBのRAMを搭載したAMD Phenom II X4 940で、ASUS M3A79-T DELUXE m/bで駆動されます。

    • CPU ロゴfpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save

libvirt* 2.0.0-1:amd64どちらもdebian sidを実行し、パッケージのバージョン（および含む）がまったく同じでqemu-system-x86 1:2.6+dfsg-3、Liquorixカーネルも同じです。

Linux indra 4.6-2.dmz.2-liquorix-amd64 #1 ZEN SMP PREEMPT Debian 4.6-3 (2016-06-19) x86_64 GNU/Linux
Linux surya 4.6-2.dmz.2-liquorix-amd64 #1 ZEN SMP PREEMPT Debian 4.6-3 (2016-06-19) x86_64 GNU/Linux

VM自体はデフォルトのdebian 4.6.0-1カーネルでdebian sidを実行しています。

Linux dtest 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64 GNU/Linux

どのホストでも仮想マシンを起動でき、正常に動作します。

何の問題もなく、仮想マシンをスリーヤからインドラに移行できます。 indraからsuryaに仮想マシンを移行しようとすると、移行は正常に完了したように見えますが、仮想マシンは100％CPU使用率（割り当てられた単一コアの場合）で中断されます。

VM が Indra から起動してからスリヤに移行したか（停止する場所）、スリヤで起動してインドラに移行した後（今までは大丈夫）、再びスリヤに移動したか（停止位置）に違いはありません。 。

VMがハングした場合、私ができる唯一のことはvirsh destroy（強制終了）またはvirsh reset（強制再起動）だけです。

以下を使用してkvm_steal_timeを無効にしようとしました。

 <qemu:commandline>
   <qemu:arg value='-cpu'/>
   <qemu:arg value='qemu64,-kvm_steal_time'/>
 </qemu:commandline>

しかし、それは問題を解決しません。

何もログインしていないか、仮想マシン自体からは出ません。私が受けた唯一の問題の兆候は、/var/log/libvirt/qemu/dtest.logスリヤの次のメッセージです。

2016-07-18T12:56:55.766929Z qemu-system-x86_64: warning: TSC frequency mismatch between VM and host, and TSC scaling unavailable

これはtsc_scaleCPU機能によるものです。 8150 CPU（indra）にはありますが、x4 940（surya）にはありません。

何が問題なのかご存知ですか？それともどうすれば解決できますか？それともデバッグ提案がありますか？

修正できますか、それとも複数世代のPhenom II x4 940のCPUバグですか？

ベストアンサー1

解決策が見つかりました。

私が疑ったように、問題の原因はtsc_scaleスリヤのCPUに機能フラグがありませんでした。

tsc_scaleVMを持たないホストからVMを持つホストにVMを移動できますが、VMがあるホストで実行されているVMはtsc_scale移動できます。ただこれと共に他のホストに移行します。

これでバグレポートを送信する時間です。

今回は、suryaとネットワーク（私のメインサーバー）の他のシステムの間にZFS ZVOLに基づいて別のDRBDを作成しましたganesh。

  • ganeshは、ASUS Sabertooth 990FX m/bで駆動される32GB RAMを搭載したAMD Phenom II 1090Tです。
    • CPUフラグ：fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter

問題なくスリーヤとガーネッシュ間でVMを前後に移行し、スリーヤまたはガーネッシュからインドラにVMを移行できます。しかし、IndraからSuryaまたはganeshに仮想マシンを移行することはできません。。

今これで買えます。新しいAMD Zen CPUがリリースされると、ganeshがアップグレードされ、suryaはganeshの現在のマザーボードとRAMを持ちます。同時に、新しいFX-6300またはFX-8320を購入する予定なので、すべてのマシンにその機能が適用されますtsc_scale。

FX-8320 CPU（該当する機能もあります）があるネットワークに別のコンピュータ（kali）がありますtsc_scale。 ganeshのメインzpoolをアップグレードし（4x1TB RAIDZから2x4TBミラーへ）、indraとkaliを切り替えることができるように、より古いディスクを入手したらすぐにZVOL + DRBD +リアルタイム移行実験に追加します。または、suryaとganeshの間で仮想マシンを前後に移行します。

仮想マシンのラップ計画の次のステップは、ZVOLでDBRDを使用するように仮想マシンを設定し、ホスト間で仮想マシンを移行するプロセスを完全に自動化するスクリプトを作成することです。

うまくいけば、それを破棄し、私が書こうとしていたことをすでに実行している（しかしより完全でより良い）ganetiを使い始めます。

最終的にこれに飽きたら、OpenStackに切り替えてボリューム管理にシンダーを使用します。 ganetiをスキップしてすぐにopenstackに行きたい誘惑がありますが、ganetiは素晴らしいスキルで、しばらく遊びたいです...何年も使用していません。

おすすめ記事