Soy Jose Maria Gris y otra semana mas estoy aquí con vosotros para hablar de nuestros temas sobre VMware y su ecosistema.

Mucho hemos ido arriba y abajo con los dispositivos usb en nuestras infraestructuras ESX. Que yo prefiero tener unos dispositivos hardware que me mapean los usb a las VM, que yo lo prefiero hacer por software y ponerlo en una estación que tiene el USB.

Lo cierto es que la versión 4.1 tiene grandes cambios y entre ellos, el soporte para usb en nuestros ESX (que ya vamos a tener que ir cambiando a ESXi). Que ya lo dijimos hace tiempo, no Chema? Pues nada, muy sencillo. Revisad eso si, que estamos en Hardware 7 y que el dispositivo este en la lista de USBs a los que se dan soporte.

Primero añadimos el controller a nuestra VM con “Edit Settings” -> Add y seleccionaremos el controlador de USB.

Tras instalar nuestro dispositivo, volveremos para añadir el dispositivo de la lista que el sistema nos está reconociendo.

Como podeis ver mas abajo, podremos indicarle que incluso nuestro dispositivo funcione incluso si hacemos vMotion. También decir que es una opción que se puede hacer en caliente

Bueno, me voy a hacer las maletas para Kopenhagen que este año nos vamos al VMworld. Nos vemos allí si aparecéis.

Take care!

VMware vSphere Licensing Report Manager es una nueva funcionalidad incluida en la versión VMware ESX/ESXi 4.1.
Se instala por defecto cuando instalas vCenter Server en modo plugin. Una vez activado el plugin puedes entrar en la aplicación desde la opción home/Application and Solutions.

El beneficio real de este nuevo plugin es que te permite saber con exactitud el número de licencias, tanto para vCetner como para VMware ESX/ESXi, que tiene instalado tu entorno.

Asimismo te permite saber, en porcentaje relativo, el número de licencias que no estas usando de tu entorno, muy útil para conocer con exactitud si estas usando todas las licencias que has adquirido y licenciado.

En este episodio #42 te ensañare activar el plugin Licensing Report Manager y a usar este nuevo plugin para crear informes de uso de licencias de tu entorno:

Hola, que tal? Soy Jose Maria Gris y como cada jueves estoy aquí con vosotros para hablar del ecosistema de VMware.

Curiosamente me he encontrado con dos situaciones iguales en dos entornos distintos, lo que me ha dado a pensar en que sería bueno postearlo. Veeam Backup es muy fácil de configurar en modo network a través de vCenter. Configuraciones en modo SAN o en modo en modo “Virtual Appliance” tienen su configuración especial, pros y contras.

Estamos en un entorno Veeam Backup 4.x donde la maquina veeam tiene iniciadores iSCSI de MS i “ve” las Luns, haciendo las copias en modo “SAN”. Una de las opciones que tenemos habilitada es usar el Traking de bloques cambiados para que las copias incrementales vayan más rápidas al monitorizar los cambios de bloques.

Todo el sistema funciona bien hasta que un día nos damos cuenta que la velocidad de la copia de seguridad baja de forma considerable y a la par baja el ratio de “copia”.

Investigas que ha pasado y no ves ningún cambio importante a la vista. Nuestro Veeam Backup está funcionando perfectamente, pero da unos mensajes “Verifing changed block tracking…”.

Analizando un poco más en profundidad, justo antes de empezar a ir lentos hicimos unos cambios, entre los que había cambios de ubicación de las VMs en otro datastore con StoragevMotion. Y ahí está el problema. Las referencias de los bloques han cambiado y el sistema no puede establecer “el diferencial” porque el entorno que tiene guardado y el que “ve” no cuadran. Hay que reconciliarlos.

Nos vamos a nuestro vCenter y a cada VM que hemos movido y hemos cambiado de Lun le cambiaremos el siguiente parámetro. En Edit Settings, pestaña options, General, veremos el botón Configuration Parameters.

Dentro de las opciones buscaremos el string ctkEnabled y cambiaremos su status a “False”.
Ello permitirá a Veeam volver a reconstruir el entorno de bloques y volver a nuestra velocidad que estábamos obteniendo hasta és momento.

Es importante tener el tema en cuenta porque lo que parece un cambio banal puede significar perder la ventana de backup ya que un job puede alcanzar a otro, dependiendo de cómo lo tengamos organizado. Otro día hablaremos de la configuración “Virtual Appliance” que es muy curiosa.
Saludos, take care.

Queridos lectores,

Igual que en los pcs de sobremesa, en una máquina virtual dentro de XenServer puede sernos útil tener varios dispositivos DVDs.

XenServer por defecto soporta de 0 a 7 unidades de disco virtuales y los numera en ese orden.

Pasos a seguir para añadir una segunda unidad de DVD:

1.- Listamos las máquinas virtuales para encontrar el uuid de la que nos interesa

xe vm-list

2.- Comprobamos que no pasemos el número máximo de discos virtuales permitidos

xe vm-disk-list uuid=”uuid de la VM”

3.- Buscamos la .iso que queramos asignar al nuevo dispositivo en XenServer y añadimos la nueva unidad

xe vm-cd–add vm=”uuid de la VM” device=”numero de la unidad del 0 al 7 que quede libre” cd-name=”imagen.iso”.

4.- Ya podemos ir a XenCenter y desplegar los diferentes DVDs asignados a una máquina virtual.

Como veis con 4 sencillos pasos que podréis hacer siempre que se presente la necesidad de tener varios DVDs en la máquina virtual.

Para determinar con precisión si la CPU de tu servidor VMWare vSphere ESX/ESXi se está comportando con normalidad, debes de revisar la información específica disponible sobre dicha CPU con las herramientas de monitorizacion incluidas en VMware vSphere.

La semana pasada, en la primera parte del video, vimos los conceptos de CPU used y CPU Ready y lo que significa cuando estos dos contadores aumentan durante un perido de tiempo prolongado.

En este episodio #42 te monstrare a extrapolar los datos de los dos contadores a porcentajes relativos y a identificar si realmente existe un cuello de botella a nivel CPU en tu entorno virtual.

Un saludo de nuevo a nuestros colegas y simpatizantes de este Blog. Soy Jose María Gris y como siempre vamos a ver hoy alguna nueva utilidad, truco, configuración del ecosistema VMware.

Sois de los que os gusta la documentación de consulta? Odiáis tener montones de papeles por vuestro estudio? No sabéis donde esta el pdf de las narices que me hace falta ahora? Os ha pasado estar en una instalación en un lugar recóndito y no tener acceso por Internet por avería y no poder consultar una documentación.

Bueno, de nuevo xtravirt nos sorprende con una herramienta free, sencilla y potente a la vez. VMware Documentation Downloader y podéis obtenerlo aquí – requiere logon.

Su manejo es muy sencillo:

Instalamos los 4 ficheros que nos facilitan y ejecutamos GetVMwareDocs.bat. En primer lugar, si ha sido ejecutado anteriormente nos preguntará si deseamos hacer update de la información o no (si es la primera vez no preguntara). Si hemos pedido hacer update nos pedirá información del Proy si tenemos.

El sistema comparará la estructura especifica de la web de soporte de VMware y la comparará con el fichero log y efectuará los download pertinentes.

Para facilitarnos la vida, al final del proceso nos copiará en local la pagina web de soporte de VMware a nuestro ordenador, con los apuntadores en local, con lo que podremos “navegar” por la información que reside en nuestro ordenador local teniendo los pdfs y/o documentaciones de los distintos productos y versiones.

Importante. El .bat GetVMwareDocs.bat busca la información de las versiones existentes en el momento, es decir, con la nueva aparición de versiones o productos deberemos bajarnos la version actualizada del fichero .bat porque sino, no “verá” la nueva información disponible en la web de soporte.

Probarlo, veréis que práctico es.

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.