virsh로 생성된 KVM 게스트가 있습니다. 호스트 시스템은 Ubuntu 18.04이고 게스트 시스템은 Ubuntu 18.04입니다. 둘 다 커널을 실행하며 Linux maus 5.3.0-59-generic저는 제가 가지고 있는 Intel CPU에서 제공하는 하드웨어 가상화를 사용하고 있습니다. 최근까지 이 접근 방식은 잘 작동했습니다.
게스트의 네트워크 카드가 내 홈 네트워크와 케이블 모뎀에 연결되어 있습니다. 이는 NAT 장치 역할을 하여 로컬 컴퓨터가 케이블 모뎀을 통해 인터넷에 액세스할 수 있게 해줍니다.
tc나는 일반적으로 인터넷 연결의 전반적인 가용성을 향상시키기 위해 많은 iptables 규칙과 명령을 실행합니다 . 현재 tc이러한 기능이 비활성화되어 있으므로 fq_codel우분투 런타임에서 제공하는 기본 qdisc를 사용합니다.
머신을 NAT 게이트웨이로 사용할 때 간헐적으로 네트워크가 정지되는 현상이 발생합니다. 기본적으로 네트워크 트래픽이 일시 중지된 다음 모든 것이 따라잡습니다. 노트북을 사용하여 케이블 모뎀에 직접 연결하여 확인한 추가 문제 해결 결과 인터넷 연결이 제대로 작동하고 있는 것으로 나타났습니다.
호스트 컴퓨터에서 게스트 컴퓨터로 핑을 보낼 수 있습니다. 호스트와 게스트 사이에는 어떤 종류의 가상화된 네트워크도 없다는 점에 유의하세요. 추가 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
두 개의 CPU를 할당하기 위해 VM을 업그레이드했지만 전혀 차이가 없었습니다.
그래서 내 질문은
- 디스크 쓰기로 인해 게스트 VM이 기본적으로 플랫하게 유지되는 것처럼 보이면 무슨 일이 일어날 수 있습니까?
- 문제를 해결하려면 다음으로 어디로 가야 합니까?