virshで作成されたKVMゲストがあります。ホストシステムはUbuntu 18.04で、ゲストシステムはUbuntu 18.04です。どちらもカーネルを実行し、Linux maus 5.3.0-59-generic私は私が持っているIntel CPUが提供するハードウェア仮想化を使用しています。最近まで、このアプローチはうまくいきました。
ゲストのネットワークカードが私のホームネットワークとケーブルモデムに接続されています。これはNATデバイスとして機能し、ローカルコンピュータがケーブルモデムを介してインターネットにアクセスできるようにします。
tc私は通常、インターネット接続の全体的な可用性を向上させるために多くのiptablesルールとコマンドを実行します。現在、tcこれらの機能は無効になっているため、Ubuntufq_codelランタイムによって提供されるデフォルトのqdiscを使用します。
マシンをNATゲートウェイとして使用すると、ネットワークが断続的に停止する現象が発生します。デフォルトでは、ネットワークトラフィックは一時停止され、すべてが追いつきます。ノートブックを使用してケーブルモデムに直接接続して確認した追加のトラブルシューティングの結果、インターネット接続が正しく機能していることがわかりました。
ホストコンピュータからゲストコンピュータにpingを送信できます。ホストとゲストの間にはどのような仮想化ネットワークもないことに注意してください。追加のNICが物理マシンにインストールされ、ゲストにブリッジされます。だからこれは私のローカルスイッチを通過する必要があります。次のコマンドを実行します。ping -i 0.22 192.168.12.90ホストから。
典型的な遅延時間は1ミリ秒未満です。しかし、突然遅れて
4 bytes from 192.168.12.90: icmp_seq=340 ttl=64 time=0.710 ms
64 bytes from 192.168.12.90: icmp_seq=341 ttl=64 time=0.323 ms
64 bytes from 192.168.12.90: icmp_seq=342 ttl=64 time=0.234 ms
64 bytes from 192.168.12.90: icmp_seq=343 ttl=64 time=0.542 ms
64 bytes from 192.168.12.90: icmp_seq=344 ttl=64 time=0.382 ms
64 bytes from 192.168.12.90: icmp_seq=345 ttl=64 time=0.253 ms
64 bytes from 192.168.12.90: icmp_seq=346 ttl=64 time=0.361 ms
64 bytes from 192.168.12.90: icmp_seq=347 ttl=64 time=0.360 ms
64 bytes from 192.168.12.90: icmp_seq=348 ttl=64 time=1374 ms
64 bytes from 192.168.12.90: icmp_seq=349 ttl=64 time=1151 ms
64 bytes from 192.168.12.90: icmp_seq=350 ttl=64 time=928 ms
64 bytes from 192.168.12.90: icmp_seq=351 ttl=64 time=704 ms
64 bytes from 192.168.12.90: icmp_seq=352 ttl=64 time=480 ms
64 bytes from 192.168.12.90: icmp_seq=353 ttl=64 time=257 ms
64 bytes from 192.168.12.90: icmp_seq=354 ttl=64 time=34.8 ms
64 bytes from 192.168.12.90: icmp_seq=355 ttl=64 time=0.285 ms
64 bytes from 192.168.12.90: icmp_seq=356 ttl=64 time=0.351 ms
64 bytes from 192.168.12.90: icmp_seq=357 ttl=64 time=0.400 ms
64 bytes from 192.168.12.90: icmp_seq=358 ttl=64 time=0.341 ms
また、仮想マシンで使用しているネットワークカードに直接接続しても同じ動作を見たため、ローカルスイッチに問題があるわけではありません。
ホストマシンは、stress -c 4 -m 4できるだけ多くのCPU負荷を生成するために実行します。これは問題を改善したり悪化させたりしません。
私は最終的にjournald遅延が発生した場合、通常は単純なIOを実行することがわかりました。ゲストで次のように実行しましたdd if=/dev/zero of=./fstest bs=4096 count=25000。これにより、吃音問題が直ちに発生しました。明らかに、ゲストのディスクIOが問題を引き起こすことが確認されました。
ddホストシステムで同じコマンドを実行しても問題は発生しません。それは私を感じさせる何とかゲストの状態が悪化しました。
これは非常に単純なディスク構成の全体です。
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/corona/gateway_ii'/>
<backingStore/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</disk>
デバイスは、/dev/corona/gateway_iiホストでLVMを使用して作成されたデバイスです。
--- Logical volume ---
LV Path /dev/corona/gateway_ii
LV Name gateway_ii
VG Name corona
LV UUID xlpkI2-3qW1-7Jld-N30q-Vl05-nR9I-8jgijJ
LV Write Access read/write
LV Creation host, time maus, 2020-03-29 18:31:31 +0000
LV Status available
# open 2
LV Size 30.00 GiB
Current LE 7680
Mirrored volumes 2
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:9
2つのCPUを割り当てるためにVMをアップグレードしましたが、まったく違いはありませんでした。
だから私の質問は
- ディスクへの書き込みによってゲストVMがデフォルトでフラットに保たれるように見える場合、何が起こりますか？
- 問題を解決するには、次にどこに行くべきですか？