¿Por qué la red de virtualbox utiliza virtio lento (puente y solo host, Debian)

5

Actualmente estoy instalando un Servidor VirtualBox usando Debian para Host y Cliente. Experimento algunos problemas con respecto al rendimiento de la red y la carga de la CPU, especialmente al usar redes solo de host y no tengo idea de cómo rastrear esto más adelante.

Ni el host ni el cliente tienen una GUI disponible.

Realicé varias pruebas usando iperfpara tener una idea de lo que está yendo mal.

Host = host Virtualbox (en ejecución iperf -s), Core i7 (núcleos 4x2 @ 1,6 GHz), 16 GiB RAM

  • 192.168.0.13, eth0 (Broadcom Gigabit integrado), Gigabit Cat.6 a través del conmutador SoHo Gigabit
  • 192.168.0.20, eth1 (Broadcom Gigabit integrado), Gigabit Cat.6 a través del conmutador SoHo Gigabit
  • 192.168.14.1, vboxnet0, red solo de host VirtualBox
  • SO: Debian 7.2.0 amd64 (Wheezy), Kernel 3.2.0-4-amd64, SMP Debian 3.2.51-1 x86_64
  • VirtualBox: 4.1.18_Debianr78361

Cliente = cliente VirtualBox (en ejecución iperf -s), 2 núcleos, 2 GiB RAM

  • 192.168.0.14, eth0, puenteado a eth1 del host usando virtio
  • 192.168.14.100, eth1, vboxnet0, red solo de host VirtualBox usando virtio
  • lsmod en la máquina virtual enumera "virtio_net", "virtio_PCI", "virtio_ring" y "virtio"
  • virtualbox-guest- (dkms | utils | x11) y virtualbox-ose-guest-x11 instalados
  • SO: Debian 7.2.0 amd64 (Wheezy), Kernel 3.2.0-4-amd64, SMP Debian 3.2.51-1 x86_64

Otra máquina física (en funcionamiento iperf -s)

  • 192.168.0.2, Gigabit Cat.6 a través del conmutador SoHo Gigabit
  • SO: Servidor Ubuntu

Prueba 1 : el bucle invertido en la máquina física funciona muy bien (> 60 Gbit / s) y es atrapado por iperf-client que satura un núcleo:

  • Escenario: loopback en máquina física
  • Mando: iperf -c 127.0.0.1 -B 127.0.0.1 -i 60 -t 600
  • Ancho de banda (Mb / s): 62100 61900 61800 61900 61800 61900 61900 61900 61800 -> 61900
  • CPU: Host (iperf -s) 70%, Host (iperf -c) 100%

Prueba 2 : la conexión clásica a través de eth0 funciona como se esperaba:

  • Escenario: Host eth0 (Broadcom Gigabit integrado) -> Otra máquina físicamente cableada a través del conmutador
  • Mando: iperf -c 192.168.0.2 -B 192.168.0.13 -i 60 -t 600
  • Ancho de banda (Mb / s): 942 941 941 941 941 941 941 941 941 -> 941
  • CPU: Host (iperf -c) 3.5%

Prueba 3 : la conexión clásica a través de eth1 funciona como se esperaba:

  • Escenario: Host eth1 (Intel Gigabit Server 4xNIC PCIe) -> Otra máquina con cable físico a través del conmutador
  • Mando: iperf -c 192.168.0.2 -B 192.168.0.20 -i 60 -t 600
  • Ancho de banda (Mb / s): 942 941 941 941 941 941 941 941 941 -> 941
  • CPU: Host (iperf -c) 3.5%

Prueba 4 : el bucle invertido dentro de la máquina virtual casi satura ambos núcleos virtuales como se esperaba; alcanzar el 30% de la velocidad nativa del host:

  • Escenario: bucle invertido completamente dentro de la máquina virtual
  • Mando: iperf -c 192.168.14.1 -B 192.168.14.100 -i 60 -t 600
  • Ancho de banda (Mb / s): 19600 19500 19600 19500 19500 19600 19600 19500 19500 -> 19500
  • CPU: Host (VBoxHeadless) 200%, Cliente (iperf -s) 75%, Cliente (iperf -c) 100%

Prueba 5 : el controlador virtio en puente con el mundo exterior se desempeña al 50% (40-70%) y ocupa la CPU del host notablemente mientras el cliente está inactivo:

  • Escenario: Virtualbox eth0 virtio enlazado al host eth1 -> Otra máquina físicamente cableada a través del conmutador
  • Mando: iperf -c 192.168.0.2 -B 192.168.0.14 -i 60 -t 600
  • Ancho de banda (Mb / s): 401 458 480 367 582 720 431 388 696 553 -> 508
  • CPU: Host (VBoxHeadless) 30-60%, Cliente (iperf -c) 3%

Prueba 6 : la CPU de los clientes bloquea el controlador virtio en puente al host, ¡y solo alcanza el 12% de la velocidad nativa del host!

  • Escenario: Virtualbox eth0 virtio puenteado al host eth1 -> host's eth1
  • Mando: iperf -c 192.168.0.20 -B 192.168.0.14 -i 60 -t 600
  • Ancho de banda (Mb / s): 7420 7660 7310 7620 7690 7580 7570 7580 7700 7710 -> 7580
  • CPU: Host (VBoxHeadless) 160%, Host (iperf -s) 11%, Cliente (iperf -c) 100%

Prueba 7 : la red de los clientes que usa virtio se ve obstaculizada por la CPU de los clientes, ¡solo alcanza el 8% de la velocidad nativa del host!

  • Escenario: Virtualbox vboxnet0 host-only virtio
  • Mando: iperf -c 192.168.14.1 -B 192.168.14.100 -i 60 -t 600
  • Ancho de banda (Mb / s): 4760 4740 4980 5300 4890 4560 5270 4850 5450 5070 -> 4990
  • CPU: Host (VBoxHeadless) 170%, Host (iperf -s) 13%, Cliente (iperf -c) 100%

Agregué algunas pruebas más que me llevaron a resultados aún más confusos: algo definitivamente está roto.

Prueba 8 = Prueba 6 con Intel 82545EM es más lenta que virtio

  • Escenario: Virtualbox eth0 Intel 82545EM conectado al host eth1 -> host's eth1
  • Comando: iperf -c 192.168.0.20 -B 192.168.0.14 -i 60 -t 600
  • Ancho de banda (Mb / s): 3250 3300 3270 3290 3320 3380 3330 3330 3300 3300 -> 3310
  • CPU: Host (VBoxHeadless) 110%, Host (iperf -s) 5%, Cliente (iperf -c) 100%

Prueba 9 = ¡La prueba 6 con Intel 82543GC es muy lenta!

  • Escenario: Virtualbox eth0 Intel 82543GC puenteado al host eth1 -> host's eth1
  • Comando: iperf -c 192.168.0.20 -B 192.168.0.14 -i 60 -t 600
  • Ancho de banda (Mb / s): 667 627 717 743 633 653 621 677 701 623 -> 666
  • CPU: Host (VBoxHeadless) 35 - 117%, Host (iperf -s) 5 - 17%, Cliente (iperf -c) 50 - 100%

Prueba 10 = Prueba 5 con Intel 82545EM -> no puede establecer la conexión

  • Escenario: Virtualbox eth0 Intel 82545EM conectado en puente al host eth1 -> Otra máquina físicamente cableada a través del conmutador
  • Comando: iperf -c 192.168.0.2 -B 192.168.0.14 -i 60 -t 600
  • Ancho de banda (Mb / s):
  • CPU: Host (VBoxHeadless) 30-60%, Cliente (iperf -c) 3%

¿Prueba 11 = Prueba 5 usando Intel 82543GC, comienza bien, luego disminuye a una fracción?

  • Escenario: Virtualbox eth0 Intel 82543GC conectado al host eth1 -> Otra máquina con cable físico a través del conmutador
  • Comando: iperf -c 192.168.0.2 -B 192.168.0.14 -i 60 -t 600
  • Ancho de banda (Mb / s): 935941 909 936 941 940 941 339 219 216 -> 732
  • CPU: Host (VBoxHeadless) 100%, Cliente (iperf -c) 60%

P1: ¿Por qué la prueba de bucle invertido (4) dentro de la máquina virtual es tres veces más lenta que la misma prueba en el host? ¿No debería estar cerca de la velocidad nativa?

P2: ¿Por qué una red puenteada común que usa virtio causa tanta carga en el lado del host y no alcanza 1 Gbps? Prueba (5)

P3: ¿Por qué la prueba de puente (6) dentro de la máquina virtual es ocho veces más lenta que la prueba de loopback en el host (tres veces más lenta que la loopback en la máquina virtual)?

P4: ¿Por qué la prueba de solo host (7) dentro de la máquina virtual es doce veces más lenta que la prueba de loopback en el host (cuatro veces más lenta que la loopback en la máquina virtual)?

Espero que algunos aspectos de virtualización afecten Q1-Q4. virtio parece causar Q2-Q4, pero no tengo idea de dónde investigar o modificar.

Todo eso no suena tan mal. Pero el problema se originó al usar la red de solo host para iSCSI. Resultó en transferencias de HDD tan bajas como 10 MB / sy un alto uso de CPU: los HDD son capaces de 147 MB ​​/ s. Algo definitivamente está mal ...

debian  virtualbox  virtio 
3
¿Por qué esperas un alto rendimiento? Es VirtualBox, después de todo; no es que vayas a hacer nada importante con eso.
— Michael Hampton
2
Lo que insinúa @MichaelHampton es que VBox es una solución de virtualización de escritorio , similar a VMware Workstation. No deberías estar ejecutando nada importante en él. Existen muchas otras opciones de alto rendimiento que deberían usarse en lugar de Virtualbox. VMware, Hyper-V, XenServer, KVM, etc.
— EEAA
1
Es solo para uso doméstico y no esperaba que 1 Gbps sea "alto rendimiento". KVM es el siguiente en mi lista, si todo falla.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.