Hola a todos, soy Florián Murillo y hoy hablaré del Virtual Machine Communication Interface (VCMI).
Es un mecanismo poco conocido de comunicación entre VM que cohabitan en el mismo host (ESX o ESXi). Utiliza como transporte ethernet L2 (ya estoy de nuevo hablando de redes) pero sustituye TCP y UDP por otros protocolos ligeros que mejoran el rendimiento de las transferencias de datos entre un 200% y un 300% como veremos mas adelante.
Algunos pensareis que si comparten el host es fácil mejorar el rendimiento respecto a tener que atravesar la red física para comunicarse y tenéis razón, pero incluso compartiendo host, tenemos una limitación en el protocolo TCP, ya que tiene una carga de controles para garantizar que la trama se entregue y que ralentizan su rendimiento a cambio de garantías de entrega.
En nuestro caso no tenemos tanto riesgo en la entrega de la trama porque controlamos el medio, de extremo a extremo, bueno, lo controla el host no nosotros 
El “truco” consiste en sustituir el mecanismo de sockets basados en TCP por un mecanismo de sockets basado en VMCI.
Dicho de otra manera, en nuestros programas en lenguaje C, cambiaremos el :
#include “sockets.h”
… por el …
#include “vmci_sockets.h”
¿Que ganamos con esto?
La gráfica de la cabecera (fuente VMware) muestra la diferencia entre las velocidades de transferencia entre dos VM con Red Hat, con vmxnet3 y con diferentes tamaños de mensaje a transmitir (eje de las X) y con diferentes tamaños de buffer del socket (ver leyenda) tanto de VMCI (vSockets) como sockets TCP/IP. Esta gráfica corresponde a 5 VM transfiriendo simultáneamente el mensaje.
Como podemos ver, en muchos casos VMCI tiene TRES veces mas rendimiento que TCP/IP, lo cual no está nada mal.
En la gráfica siguiente vemos el mismo escenario y las mismas condiciones con VM con Microsoft Windows 2003, donde podemos llegar a tener DOBLE rendimiento con VMCI.
¿Tiene inconvenientes?
Como no existe el yin sin el yang, esta tecnología tiene sus riesgos, si una VM no va a utilizar VMCI para comunicarse con otra, hemos de asegurarnos que está desactivado (restricted) en sus settings para evitar un camino no controlado de comunicación entre VM, además es un camino bastante silencioso, ya que como no lo esperamos, no tendremos, seguramente, herramientas que registren este tipo de tramas, desapareciendo este flujo de nuestro control. Esto puede ser muy peligroso, desde una perspectiva de seguridad (ya vuelvo a hablar de seguridad).
Como vemos en la imagen siguiente, el valor por defecto es desactivado (restricted).
¿Como detectar si VMCI está activado desde PowerCLI?
En el archivo .vmx de la VM tenemos una entrada que controla la VMCI, es la clave vmci0.unrestricted
En una VM por defecto, no existe esta clave y VMCI está desactivado, cuando activamos VMCI esta clave se pone a true en el .vmx
Por tanto, preguntando por ella en un pequeño script, sabremos su estado real, os adjunto un ejemplo, creado para la ocasión, en este ejemplo interrogamos a la VM llamada fs01:
$vm = get-view (Get-VM “fs01″).id
$seguro = $true
for ($i=0; $i -le ($vm.config.extraconfig.length – 1); $i++) {
if ($vm.config.extraconfig[$i].key -eq “vmci0.unrestricted”) {
$seguro = $vm.config.extraconfig[$i].value
}
}
if ($seguro) {
write-host (“La VM ” + $vm.name + ” es SEGURA”)
} else {
write-host (“La VM ” + $vm.name + ” es INSEGURA”)
}
Esto ha sido todo por hoy amigos, hasta la semana que viene.
