En VMware ESX y ESXi hay más similitudes que diferencias, aunque quizá el beneficio más importante de ESXi sobre ESX es que ESXi aumenta la seguridad y la fiabilidad de nuestro hipervisor.
VMware ESXi 5 tiene mucho menos código (76MB de footprint) que parchear y, por lo tanto, tiene una superficie de ataque mucho menor. La versión ESX ha desaparecido como tal con el lanzamiento de la versión de VMware vSphere™ 5.
La versión VMware vSphere™ ESXi 5 como la versión ESX comparten el mismo VMkernel y VMM – de las siglas en inglés Virtual Machine Manager -, aunque hay algunas connotaciones muy importantes a destacar:
1. Extensiones VMkernel: Mientras que en la versión clásica de VMware ESX podías instalar agentes y drivers de empresas de terceras partes, en ESXi solo se permite instalar extensiones en el VMkernel que hayan sido previamente firmados digitalmente por VMware. Esta restricción ayuda mucho a asegurar el entorno y mantener el código seguro en el VMkernel.
2. Muchos de los agentes y deamons que se ejecutaban en el Service Console (COS) en la versión clásica del ESX, han sido convertidos y embebidos para que se ejecuten directamente en el VMkernel del ESXi.
3. La imagen del sistema en ESXi – system image – es una imagen bootable que es cargada directamente en memoria física. El propio “installer” usa esa misma imagen de sistema para copiar los ficheros en un disco local para futuros arranques.
Debido a que la imagen del sistema es cargada en memoria, la versión ESXi no necesita obligatoriamente de un disco local cuando este se está ejecutando. Esto significa que el disco local podría fallar pero, sin embargo, nuestro VMkernel continuaría ejecutándose.
4. La partición scratch. Es una partición de 4GB virtual y de tipo FAT (VFAT) la cual es creada por defecto en el primer disco local del servidor ESXi ¡si tu servidor tiene discos locales, claro! Si el servidor no tiene ningún disco local, esta partición no existirá pero se “rediccionará” el directorio scratch a una partición de tipo ramdisk llamada /tmp. Esto significa que el contenido de esta partición scratch no “sobrevivirá” a un reinicio del servidor ESXi.
Por consiguiente, el servidor ESXi puede necesitar hasta 4GB de memoria RAM para almacenar esta partición scratch.
5. Y por último, pero no por ello menos importante, tenemos la partición bootbank. Esta partición contiene la imagen del sistema sobre un sistema de archivos. Si hay un disco local al cual ESXi pueda escribir, este almacena dos copias del bootbank. Pero ojo, solo una es montada en la estructura del sistema de archivos del ESXi en el directorio /bootbank. La segunda copia se usa únicamente durante las actualizaciones para mantener una segunda copia como backup en caso de problemas durante actualizaciones del sistema.
Por otro lado, en VMware vSphere™ ESXi 5 es posible hacer una instalación de la imagen directamente en la memoria del servidor físico usando una nueva funcionalidad llamada vSphere™ Auto Deploy ESXi Installation Option.
Con VMware vSphere™ Auto Deploy podrás acceder al fichero de instalación desatendido (answer file) vía CIFS, SFTP o HTTP.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.
Hola de nuevo, soy Miguel Angel Alonso y aquí estoy afortunadamente una vez más con vosotros para mostraros un nuevo artículo que espero que os guste y os pueda ayudar en vuestras inquietudes diarias de nuestro mundo de la virtualización.
Hoy le ha tocado el turno a cómo crear Multipathing desde la consola ESXCLI.
En el artículo de Chad Sakac y otros como(Netapp, EMC, Dell, HP, VMware) podremos tener acceso al nuevo método de Multipathing iSCSI para la nueva versión de ESX(vSphere).
Por fin en esta versión el iniciador ISCSI estará habilitado para múltiples conexiones ISCSI. (Multipathing mediante múltiples conexiones TCP)
Estoy encantado realmente con dicha función y lo fácil de configurarala que es. Necesitarás varias pautas a seguir para su correcto funcionamiento. Necesitaremos asignar 2 NICs a un VMkernel (o más) y sólo una NIC áctiva. Las demás NICs las moveremos hacia abajo (DOWN) en la sección “Unused Adapters”.
Después de haber creado tus VMkernels y unirlos (Bound) a una NIC específica, necesitarás añadirlos a tu Software iniciador ISCSI:
esxcli swiscsi nic add -n vmk0 -d vmhba35
esxcli swiscsi nic add -n vmk1 -d vmhba35
esxcli swiscsi nic list -d vmhba35
Si chequeas tu cliente vSphere te darás cuenta que habremos conseguido 2 PATHS en tu ISCSI Target, aquí os dejo un ejemplo:
Y en el ESXTOP, puedes ver los 2 VMKernel Ports con su tráfico:
Esta es una de las muchas cosas que se pueden conseguir mediante la consola de comandos ESXCLI.
Por supuesto en el Screenshot de arriba podemos ver que nuestra opción de Multipathing está en FIXED, pero como ya sabemos podremos elegir también entre MOST RECENT USED (MRU) o ROUND ROBIN (RR).
Bueno por fin un artículo un poquito más corto de lo que es habitual en mí pero creo que no por ello menos interesante. Aprovecho de nuevo para saludaros y daros siempre las gracias por estar ahí y como no, una y cuantas veces hagan falta a Jose María Gonzalez y todos mis compañeros del Blog que son increíbles.
A petición de muchos de los seguidores de El Blog de Virtualización en Español he creado un video sobre la administración de VMware ESX vía Service Console OS (COS) y como configurar alguna de las funcionalidades de red en VMware VI3.
En el video muestro algunos de los comandos más importantes en la administración de VMWare ESX via el Service Console.
Estos son algunos de los comandos que menciono en el video; esxcfg-vswitch, esxcfg-vnics, vmkping, esxcfg-firewall.
Esta semana VMware saco un nuevo appliance, VMware Infrastructure Management Assistant (VIMA), la cual permite que los administradores y desarrolladores puedan ejecutar secuencias de comandos e instalar agentes para la gestión y motorización de sistemas VMware ESX & ESXi.
VIMA es una máquina virtual que incluye software pre-instalado y componentes de autentificación y logon para servidores VMware ESX & ESXi.
A día de hoy, VIMA pude utilizarse para llevar a cabo la mayoría de las tareas de gestión y monitorización que comúnmente se hacen vía el servicio de consola de ESX (COS)
Puede que en un futuro no muy lejano VIMA sustituya el conocido Serive Console OS de VMware ESX.
Descubre y domina la nueva versión de VMware vSphere™ 5 y aprovéchate de hasta un
20% de descuento al comprarlo online.
Regístrate y
recibe un capitulo de nuestro nuevo libro totalmente gratuito
Nuevo Site Recovery Manager 4 en español Consigue una copia gratuita del eBook