Sin duda alguna la nueva versión de VMware vSphere ESXi 4.1 trae mejoras considerables.

En concreto, en esta versión se ha mejorado, y mucho, la forma y manera de activar el soporte SSH en VMware vSphere ESXi 4.1.

Esta nueva versión incluye una nueva opción en la configuración de VMware ESXi 4.1 para activar el soporte de SSH sin tener que editar, modificar, guardar y reinicializar ningún demonio de VMware ESXi, al menos, no lo tenemos que hacer nosotros manualmente.

Simplemente basta con activar la opción en el DCUI ( de las siglas en ingles Direct Console User Interface ).

En este episodio #37, te voy a mostrar como activar el soporte SSH para VMware vSphere ESXi 4.1, una mejora importante con respecto a las versiones anteriores de VMware ESXi 3.x y ESXi 4.0:

Como te decía en mi post de la semana pasada, podemos usar Veeam Monitor como utilidad para medir y monitorizar el rendimiento de tu entorno VMware vSphere, pero también es posible utilizar Veeam Monitor para darnos una idea general de cómo están ejecutándose nuestras aplicaciones en nuestro entorno de VMware vSphere.

Ahora y gracias a la incorporación en el mismo producto de un plug-in gratuito llamado “Veeam Business View” , es posible monitorizar y gestionar la infraestructura virtual de tu entorno, no sólo desde un punto de vista técnico, sino también y mas importante, desde el punto de vista de servicios de la empresa.

En este episodio #35, te voy a guiar a través de la instalación del plug-in “Veeam Business View” para enseñarte el valor añadido que dicho plug-in puede tener en tu entorno:

Hola amigos, soy Florián Murillo y en el post prevacacional de hoy vamos a responder a pequeñas dudas que nos surgen en nuestro día a día con la vMA, en concreto:

¿Que versión de vMA tenemos instalada?

[vi-admin@vma01 ~]$ cat /etc/vima-release | head -1
vMA 4.0.0 BUILD-161992

donde head nos enseña las primeras líneas del archivo (el parámetro es el número de líneas)

¿Como aumento el espacio del disco de la vMA?

Primero verificamos el estado del disco antes de hacer los cambios

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
496M 20M 452M 5% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm

[vi-admin@vma01 ~]$ sudo fdisk -l

Disk /dev/sda: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
[vi-admin@vma01 ~]$

Recordemos que /dev/sda es el disco duro y el número que le sigue es la partición.

Ahora paramos la vMA para hacer un grow del disco con:

[vi-admin@vma01 ~]$ sudo shutdown -h now

Ampliamos el disco de 5GB a 10GB desde vCenter (recuerda de borrar los snapshots para poder ampliar el disco) y levantamos la vMA

[vi-admin@vma01 ~]$ sudo fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
[vi-admin@vma01 ~]$

Observa que el tamaño del disco /dev/sda ha cambiado a 10.7GB

Ahora cramos una partición con el nuevo espacio:

[vi-admin@vma01 ~]$ sudo fdisk /dev/sda

The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n <--- Nueva partición
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 3 <--- crearemos /dev/sda3
First cylinder (653-1305, default 653):
Using default value 653
Last cylinder or +size or +sizeM or +sizeK (653-1305, default 1305):
Using default value 1305

Command (m for help): t <--- Cambiamos el tipo de partición a 8e para Linux Volume Manager
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)

Command (m for help): w <--- Grabamos los cambios realizados (importante)
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

[vi-admin@vma01 ~]$ sudo fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
/dev/sda3 653 1305 5245222+ 8e Linux LVM
[vi-admin@vma01 ~]$

Ahora reiniciamos:

[vi-admin@vma01 ~]$ sudo reboot

Tras reiniciar, preparamos la nueva partición, para ampliar /var:

Como estamos en un entorno Linux Volume Manager, nos hemos de adaptar a sus reglas:

Primero creamos el Volumen Lógico

[vi-admin@vma01 ~]$ sudo pvcreate /dev/sda3
Physical volume “/dev/sda3″ successfully created

Ahora añadimos extendemos en Volume Group VolGroup00 (que vimos en el df -h) con el Volumen Físico creado

[vi-admin@vma01 ~]$ sudo vgextend VolGroup00 /dev/sda3
/dev/hda: open failed: No medium found
Volume group “VolGroup00″ successfully extended

Verificamos que tenemos espacio libre no asignado, y que coincide, como esperabamos con el Volumen Físico añadido:

[vi-admin@vma01 ~]$ sudo vgdisplay | grep -i free
Free PE / Size 160 / 5.00 GB

Ampliamos Volumen Lógico /var que hay dentro del Volume Group VolGroup00 con el espacio que nos aporta /dev/sda3

[vi-admin@vma01 ~]$ sudo lvextend -L+5G /dev/VolGroup00/var
Extending logical volume var to 5.50 GB
Logical volume var successfully resized

Verificamos que hemos ampliado /var

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
496M 20M 452M 5% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm

Está igual !!!! esto es debido a que hemos ampliado el Volumen Lógico /var pero no se ha formateado para el S.O., esto lo realizamos a continuación:

[vi-admin@vma01 ~]$ sudo resize2fs -p /dev/VolGroup00/var
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/var is mounted on /var/log; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/var to 5767168 (1k) blocks.
The filesystem on /dev/VolGroup00/var is now 5767168 blocks long.

Ahora si, ya podemos seguir recolectando logs sin llenar el disco.

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
5.4G 21M 5.1G 1% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm
[vi-admin@vma01 ~]$

¿Como cambiar la dirección IP de la vMA?

Es simple:

Paso 1: Modificamos el archivo /etc/sysconfig/network-scripts/ifcfg-eth0
Paso 2: sudo /etc/init.d/network restart

ya tenemos nueva IP, verifica que en /etc/hosts aparece la nueva IP.

Bueno amigos, con este repaso de Linux me despido temporalmente, deseando que paséis unos días tranquilos (o no) y nos volvemos a encontrar en septiembre con las novedades de la versión 4.1 que tenemos disponible desde el día 13 de julio. Ser felices.

Hola amigos, soy Florián Murillo y en el post de hoy vamos a revisar la configuración de la vMA como recolector de logs de ESX y ESXi.

Para ello configuraremos un ESX y un ESXi para enviar logs a la vMA y después configuraremos el servicio vilogger para recolectar los logs.

Para configurar un ESX, nos conectamos por ssh y editamos el archivo /etc/syslog.cfg añadimos la línea:

*.* @10.1.1.1

Siendo 10.1.1.1 la IP de la vMA. A continuación hemos de permitir que el tráfico de syslog salga del ESX por lo que hemos de añadir la regla en el firewall del Service Console:

esxcfg-firewall -o 514, out, udp, trafico_syslog

y reiniciamos el servicio syslog:

service syslog restart

Para configurar un ESXi, utilizamos la propia vMA para lanzar una ejecución remota del comando vCLI que redirige el tráfico syslog hacia la vMA.

vicfg-syslog -s 10.1.1.1

Ahora solo nos falta configurar la vMA como syslog server con el servicio vilogger:

Lo primero que hacemos es cambiar la configuración del servicio syslog server en el servidor vMA para que acepte logs remotos:

sudo service syslog stop

cambiamos el archivo /etc/sysconfig/syslog, la línea SYSLOGD_OPTIONS ha de quedar como sigue:

SYSLOGD_OPTIONS=”-r -m 0”

y volvemos a levantar el servicio syslog con la nueva configuración:

sudo service syslog start

para permitir el tráfico de syslog, hemos de configurar el firewall de la vMA:

sudo iptables -I INPUT -i eth0 -p udp –dport 514 -j ACCEPT

y como queremos que este cambio sobreviva a los reinicios de vMA, también añadimos la regla de firewall (sin el comando sudo) al final del archivo /etc/rc.local

Ahora ya podemos empezar a utiliza vilogger, la utilidad que estructura los logs recogidos de los ESX/ESXi:

Primero iniciamos vi-fastpass ejecutando el comando vifpinit y a continuación facultamos a vilogger para recoger los logs de un host con:

vilogger –server esxi.dominio.local enable

No nos autenticamos en el host porque lo hace vi-fastpass por nosotros.

Cada host que activemos crea un directorio con el nombre del host en /var/log/vmware, en este directorio se almacenan los logs recogidos. SI quieres modificar el directorio por defecto de alojamiento de los logs, modifica el archivo /etc/vmware/viconfig/vilogdefault.xml

Verás algo parecido a la siguiente secuencia de comandos:

[vi-admin@localhost ~]$ vilogger list

Target Server: esxi.dominio.local
Log Status CollectionPeriod NumRotation MaxFileSize Location
(Seconds) (MegaBytes)
hostd Disabled – – – -
messages Disabled – – – -
vpxa Disabled – – – -

$ vilogger –server esxi.dominio.local enable

Target Server: esx1.dominio.local
hostd … Enabled
messages … Enabled
vpxa … Enabled

$ vilogger list

Target Server: esxi.dominio.local
Log Status Collec NumRot MaxFilSize Location
(Seconds) (MB)
hostd Enabled 10 5 5 /var/log/vmware/esxi.dominio.local/hostd.log
messages Enabled 10 5 5 /var/log/vmware/esxi.dominio.local/messages.log
vpxa Enabled 10 5 5 /var/log/vmware/esxi.dominio.local/vpxa.log

Con vilogger list verás el estado de todos los equipos registrados en vi-fastpass, es decir, vilogger utiliza vi-fastpass.

Con vilogger updatepolicy podemos modificar el intervalo entre recogidas de logs, el número de archivos a guardar o el tamaño de estos archivos, incluso podemos tener políticas diferentes por archivo de log.

Con vilogger –logname NOMBRE podemos desactivar la recolección de un log en concreto.

Como curiosidad, si entras en /var/log/vmware/esxi.dominio.local verás que los archivo de log anteriores al actual no los comprime como hace cuando se almacenan en el ESX/ESXi.

La semana próxima (la última antes de las vacaciones) seguiremos mejorando la configuración del vMA.

Ser felices.

¿Que tal, como estáis? Soy Jose Maria Gris y estoy aquí de nuevo, para hablarte del ecosistema de virtualización.

A veces estás instalando algo y asumes que el entorno en el que estás es el habitual. Presumes que todo el mundo siempre tiene UPS, red eléctrica estable…. e Internet on line.

Bueno, alguna vez he tenido que instalar sistemas donde Internet no estaba disponible ni física ni lógicamente por razones de seguridad. Bien

Alguna vez os puede ocurrir que vayáis a instalar el vSphere Client en vuestro ordenador y no podáis, sencillamente os dará el error 1603 de .NET.

Estará mal montado el .NET? El Firewall, el Antivirus?????….. Me huelo que vamos a aprender algo nuevo…..
Si revisas los logs verás que en un momento dado, .NET busca Internet porque busca componentes opcionales. Ahí está el punto, no está todo instalado.

Solución: o bien instalas la maquina cliente con una conexión temporal a Internet o te bajas el .NET completo.

Saludos a mis colegas de l’Ajuntament de Terrasa donde estamos haciendo un curso de Virtualización.

Take care.

VMkernel System Information es un software propietario de VMware que almacéna información y configuración del service console y del vmkernel.

VSI ( VMkernel System Information) pueden ser consultado usando el shell interactivo vsish, una herramienta excelente la cual puede ser muy útil para la resolución de problemas en nuestro entorno VMware vSphere ESXi.

Este shell interectaivo es acesible solo y unicamente desde la consola directa del servidor ESXi y en modo soporte (support mode), o desde un cliente SSH siempre y cuando hayamos activado el servicio de SSH en VMware ESXi.

En este episodio #33, te voy a guiar a través del VMkernel System Information shell en VMware vSphere ESXi:

¿Hola que tal, como estáis? Soy Jose Maria Gris y como cada Jueves estoy aquí con vosotros para compartir información sobre trucos, experiencias, productos del ecosistema VMware.

Hoy hablaremos de NFS. Como ya sabéis, podemos usar recursos NFS siempre que sean exportados con permiso de acceso para root.

Dejando aparte trabajos nativos como hace Nettapp, estamos centrándonos sobre NFS que hemos exportado desde un NAS o appliance de bajo rendimiento. Estos recursos nos van de perlas para mantener plantillas, ISOs, etc. ya que el coste de la Tb es
menor, en general, que el TB de SAN.

Algunas veces, tras perder el enlace entre el ESX y el NFS, nos muestra el acceso como inaccesible, en gris tenue. Intentamos hacer un Browse del datastore y no vemos nada, sudor frío…. Intentamos acceder al mismo, no hay forma. Intentamos hacer delete, no podemos.

Más aún, intentamos “remontar” nuestro NFS, ip del servidor, recurso, nombre del datastore y cual es nuestra sorpresa cuando nos dice vCenter (Vicente para los amigos) que “ya esta en uso”. ¿Cómo?????

Pues ahí estamos, ni arriba ni abajo. Y ahora que hacer….

El sistema es un poco curioso, pero he recuperado volúmenes con este procedimiento.

Nos dirigiremos a los ESX con nuestro Service Console y editaremos el fichero hosts, insertando un nombre FQDN a la ip del servidor NFS. A continuación nos iremos a “Add storage”, seleccionaremos NFS y en lugar de la IP del servidor, pondremos el FQDN, el recurso compartido y daremos un nombre “falso”, distinto al datastore que teníamos. Si teníamos ISOS pondremos ISOS2 por ejemplo.

El sistema nos dará fallo, diciéndonos que ya existe el recurso. Aceptamos y en segundos vemos como aparece el recurso “desaparecido”.

Take care

Queridos lectores,

Hace algunas semanas os detallé como poder exportar máquinas virtuales. Para ello es comenté que si lo hacíais desde CLI necesitabais algún tipo de almacenamiento NFS o CIFs para poder volcar el fichero de exportación.

En el post de hoy os explicaré como copiar una máquina virtual desde línea de comandos. Esta vez podréis copiarla sobre el mismo repositorio de almacenamiento SR donde está alojada la máquina virtual que queremos copiar. Por supuesto, también podréis copiarla sobre un repositorio SR alternativo, por ejemplo, hacer una copia del respositorio SR local de XenServer a un respositorio iSCSI.

El proceso de copia son tres pasos bien sencillos. Debéis aseguraros que la máquina virtual está apagada.

1.- Listar para encontrar la máquina virtual que queréis copiar:

# xe vm-list

2.- Listar los repositorios de almacenamiento. Si queréis copiar de un repositorio a otro, apuntaros cual será origen y cual será destino.

# xe sr-list

3.- Copiar la máquina virtual

# xe vm-copy vm=”Nombre de la Máquina Virtual que queréis copiar” sr-uuid=”Respositorio de almacenamiento destino” new-name-label=”Nuevo nombre para la Máquina virtual” new-name-description=”Nueva descripción para la máquina virtual”

Para acabar comentaros que esta operación también podréis hacerla desde XenCenter. En el proceso de configuración de la copia aparece alguna opción añadida como borrar la máquina virtual original después de la copia. Opción que desaconsejo totalmente por posibles problemas que puedan surgir durante el proceso de la misma. Nunca se sabe… Primero hacer la copia y una vez realizada si estáis bien seguros de eliminar la original podréis dar la orden sin problemas.

Como siempre espero que os sea de utilidad.

VMware vSphere puede reclamar hasta un 65% de la memoria de la máquina virtual durante el proceso de ballooning por defecto.

Sin embargo si has reservado memoria en la máquina virtual, el mecanismo de ballooning no podrá acceder a la memoria reservada de esta máquina virtual, a no ser que dicha máquina virtual no este usando su memoria reservada.

Es posible cambiar el porcentaje máximo de memoria que por defecto el mecanismo de ballooning puede reclar. La opcion avanzada del VMkernel es Mem.CtlMaxPercent.

Una de la mejores configuraciones de este setting es no configurar las reservas de memoria demasiado bajas, ya que de ser asi, el VMkernel, y durante periodos de alta activada, podría forzar hacer swapping a disco lo cual relantizaria enormemente el rendimiento de tu servidor VMware ESX/ESXi.

En este episodio #28 te mostrare una mejor practica sobre como configurar las reservas de memoria de las máquinas virtuales para evitar swapping del VMkernel:

Hola amigos,

En el post de hoy os explicaré como redimensionar la unidad del sistema de nuestra máquina virtual Windows 2003 Server. Es una práctica bastante común debido a que cuando creamos una VM solemos ajustar bastante el tamaño de los discos virtuales para no gastar recursos tontamente.

Lo primero que debemos hacer es parar la máquina virtual. Esto lo podemos hacer de diferentes maneras, bien sea accediendo por Terminal Server a nuestro Windows y apagarlo. O Desde la misma consola de XenCenter, dándole a “Shut Down” sobre la máquina virtual.

Una vez apagada y con la máquina virtual seleccionada, buscamos la pestaña “storage“. Seleccionamos la unidad y pulsamos sobre propiedades, nos vamos donde dice “Size and Location” y redimensionamos la unidad al tamaño que queramos.

Arrancamos nuestra máquina virtual Windows y desde el administrador de discos veremos el espacio adicional vacío sobre nuestro volumen.

Ahora hay que buscar la manera de poder extender ese volumen del sistema para poder hacer uso del espacio adicional. Hay software de terceros que pueden hacer esta tarea pero windows 2k3 tiene una utilidad llamada diskpart, en linea de comandos, que es bastante fácil de usar.

Nos encontramos con el problema que “dispart” no puede extender un volumen en el cual está el archivo de paginación y el sistema sobre el cual está funcionando nuestra máquina virtual. Entonces recurriremos al siguiente truco.

1.- Apagamos la máquina virtual.

2.- Desatachamos la unidad de nuestra máquina virtual. Lo encontraremos en las opciones de la pestaña Storage.

3.- Desde las opciones de otra máquina virtual Windows atachamos la unidad anterior. Por lo que esta segunda máquina virtual tendrá dos unidades, la primera donde está alojado su propio sistema y una segunda que es la unidad de la primera máquina virtual que queremos extender.

4.- Arrancamos la segunda máquina virtual Windows.

5.- Abrimos un terminal de msdos.

6.- tecleamos “diskpart” y pulsamos intro.

7.- tecleamos “list volume” para que nos muestre los dos volúmenes.

8.- tecleamos “select volume n” donde n es el numero de volumen que queremos extender

9.- tecleamos “extend”

10.- Con ello extenderemos la partición a la máxima capacidad del volumen.

11.- Ahora toca devolver la unidad a su verdadera máquina. Apagamos la máquina virtual

12.- Desatachamos la unidad y la atachamos sobre su verdadera máquina virtual.

13. Arrancamos la máquina virtual y comprobamos que ya tenemos todo el espacio disponible.

Como veis es un proceso bastante sencillo, sólo hay que tener en cuenta que no se puede redimensionar el volumen del sistema Windows debido a que sobre ella está el sistema de arranque y el archivo de paginación. Por ello hacemos uso de una segunda máquina virtual para poder hacer este proceso.

No os olvidéis de hacer un backup antes de hacer todo este proceso porque, en principio no debe de haber ningún problema, pero en el caso de que lo haya estaréis preparados.

Nada más, espero que os sea de utilidad. Queridos lectores, me despido hasta la próxima semana.

Tanto en la versión anterior de VMware, VMware ESX 3.x, como en la ultima versión, VMware vSphere ESX 4.x, el servidor web Access está apagado por defecto.

El servidor vCenter y VMware vSphere ESX 4.x incluyen un servidor Web (Web Access) – en concreto es una versión “rebajada” de servidor web Apache Tomcat. Sin embargo, la versión thin del hypervisor de VMware, VMware ESXi, no incluye esta funcionalidad.

Si recibes el error “503 Service Unavailable” cuando intentas conectarte al servidor Web, tanto del servidor vCenter como del servidor VMware ESX, es porque el servicio Web Access no está arrancado (por defecto).

Tip: Para arrancar el servicio Web Access en el servidor VMware vSphere ESX 4.x, bájate al Service Console y ejecuta el siguiente comando: service vmware-webAccess start.

Para arrancar el servicio Web Access en el servidor de vCenter, arranca el servicio correspondiente en la pestaña services de tu servidor Windows.

Es un placer para mi presentaros mis nuevos videos de formación VMware vSphere online sobre la tecnología de Virtualización con VMware vSphere. Después de recibir “toneladas” de emails con feedback de muchos de mis lectores pidiéndome que creara mas videos tutoriales sobre VMware vSphere, no me ha quedado mas remedio que hacerles caso.

En la actualidad ya tengo “liberados” online y gratuitamente, más de 10 episodios sobre la tecnología de virtualización de VMware vSphere.

Para ver los videos tutoriales de VMware vSphere, puedes acceder a la página general donde están todos los videos disponibles haciendo clic en el menú “Videos Tutoriales“ y seleccionando “Videos vSphere“. También puedes acceder a los videos tutoriales de VMware vSphere haciendo clic en este enlace directo.

http://www.josemariagonzalez.es/video-tutoriales/videos-formacion-vsphere

Como me pediste en tu feedback, cada Lunes liberaré un episodio que tratara sobre un tema en concreto en VMware vSphere. Espero que durante los próximos meses te diviertas viendo y siguiendo este curso de formación VMware vSphere online de la misma forma que yo me estoy divirtiendo creándolo para ti.

Estos son algunos de los videos tutoriales de VMware vSphere que ya están a disposición del público en general y que ya han visto más de 2.300 usuarios hasta la fecha.

Episodio #1: Como configurar Cisco Discovery Protocol en vSphere.

Episodio #2: Cisco Nexus 1000v Virtual Switch y Cisco Discovery Protocol.

Episodio #3: Configurando el Firewall del Service Console en vSphere.

Episodio #4: Calculando el tamaño de la base de datos en vSphere.

Episodio #5: Integrando VMware vSphere ESX 4.0 con Microsoft AD.

Episodio #6: Desmontando un DataStore NFS en vSphere 4.0.

Episodio #7: Creando un Host Profle en VMware vsphere 4.0.

Episodio #8: Creciendo un Datastore VMFS online.

Episodio #9: Configurando VMware vSphere ESXi directamente desde la consola.

Episodio #10: El backup de la configuración de VMware ESXi.

Episodio #11: Cambiando la configuración de la memoria del Service Console en VMware vSphere.

Episodio #12: Configurando Jumbo Frames en VMware vSphere.

Es posible definir resource pools a nivel de servidor VMware ESX/ESXi o a nivel de clúster VMware DRS. Sin embargo, si a la hora de crear un clúster no seleccionas la opción Enable VMware DRS, la opción de New Resource Pool estará deshabilitada.

Para poder crear un New Resource Pool en un Clúster VMware DRS, asegúrate de habilitar la opción Enable VMware DRS durante la creación de tu clúster VMware o, en su defecto, puedes habilitar dicha opción después de la creación del clúster, seleccionando el clúster con el botón derecho del ratón y seleccionando Edit Settings. Después, haz clic en Enable VMware DRS.

Los resource pools creados a nivel VMware ESX/ESXi pueden ser heredados ( grafted ) e incluidos en un clúster vSphere VMware DRS, cuando incluyes un servidor ESX/ESXi con resource pools ya creados a nivel de host, a un clúster VMware DRS.

Sin embargo, la opción por defecto cuando añades un servidor ESX/ESXi a un cluster DRS es “Put all of this host´s virtual machines in the cluster´s root resource pool. Resource pools currently present on the host will be deleted”.

Para heredar los resources de tu servidor host ESX/ESXi a tu clúster DRS, asegúrate de seleccionar “Create a new resource pool for this host’s virtual machines and resource pools. This preserves the host’s current resource pool hierarchy”.

Los resource pools heredaros serán nombrados Grafted from + nombre del servidor VMware ESX/ESXi. Si posteriormente eliminas el servidor host ESX/ESXi de tu cluster DRS, los resource pools serán “retenidos”.

No obstante, si decides desactivar la opción DRS de tu cluster, perderás todos los resource pools de dicho cluster, previo aviso eso si, y tendrias que re-crearlos de nuevo.

Esto ha sido todo, hasta la próxima semana con un nuevo tip.

El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.

Una máquina virtual no puede ser migrada en caliente cuando:

• La MV tiene una conexión activa a un virtual switch de uso interno.
• La MV tiene una conexión activa a un CD o disquete.
• La MV tiene configurada una afinidad a una CPU.
• La MV forma parte de un clúster Microsoft.

El wizard de migración en caliente, VMware VMotion, produce un warning cuando:

• La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
• La MV tiene una conexión a un CD o disquete pero no está conectado.
• La MV tiene uno o más snapshots.
• El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).

El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.

Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:

• Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
• Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
• Acceso a la misma red Ethernet física.
• El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
• CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino

Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.

VMware proporciona una utilidad llamada VMware CPU bootable Utility, la cual puedes descargar desde la propia web de VMware.

Una vez que arranques tu servidor ESX/ESXi desde CDROM con dicha utilidad, podrás comprobar si tu servidor VMware ESX/ESXI soporta las funcionalidades SSE, SSE2, NX/ED, Hyperthreading, Intel VT (Virtual Technology), AMD-V

VMware VMotion no tiene en cuenta la diferencia en la velocidad del reloj de la CPU de tus servidores ESX/ESXi, ni la diferencia en la memoria de la cache L1, L2, ni la diferencia en el numero de cores o sockets.

Asimismo VMware VMotion no tiene en cuenta las diferencias de memoria RAM entre los servidores ESX/ESXI involucrados en la migración en caliente.

La única pega que le veo a esta utilidad es que has de apagar tu servidor ESX/ESXi para comprobar que opciones y funcionalidades tiene soportado tu servidor VMware ESX/ESXi.