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.

A parte de usar Veeam Monitor 4.5 como utilidad para medir y monitorizar el rendimiento de tu entorno VMware vSphere, también es posible utilizar Veeam Monitor 4.5 para el seguimiento y resolución de problemas en tu solución de VMware vSphere.

Esta versión 4.5 incluye un notable número de características y mejoras, entre las que destaco:

• El soporte para VMware vSphere 4 y anteriores versiones de VMware ESX/ESXi
• Funciones de monitorización del almacenamiento y espacio en disco, problemas con los disco y datastores.
• Funciones de monitorización del hardware a través de CIM/SMASH
• La posibilidad de profundizar en cada sistema operativo Windows o Linux de las máquinas virtuales para controlar el rendimiento real de sus procesos desde el interior de una máquina virtual, sin tener que abrir la consola de la máquina virtual.

Pero en particular, Veeam Monitor 4.5, incluye ahora un plug-in que posibilita la integración con “Veeam Business View“, un complemento gratuito de la herramienta que permite la supervisión y la gestión de la infraestructura virtual, 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 #34, te voy a guiar a través del Veeam Monitor 4.5:

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.

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 a todos¡, soy Miguel Ángel Alonso y estoy aquí de nuevo con vosotros como cada Martes para contaros algo nuevo a cerca de la virtualización y en mi caso retomaré el tercer y último capítulo dentro de nuestro mundo MAC OSX, aunque prometo que no será el último para los amantes del mundo APPLE.

Como ya comenté en anteriores POSTs del BLOG, hoy vamos a conocer un software de Citrix llamado DAZZLE y que ya lleva con
nosotros unos 6 meses desde su aparición y que aparte de funcionar con Windows también trabajará con nuestros MAC OSX.

Dazzle es un PORTAL interactivo (Cloud Computing) que funciona como un SELF-SERVICE (Auto-servicio) para aplicaciones y escritorios virtualizados de nuestros servidores XenApp y XenDesktop.

La idea de hoy es ver como tener nuestro Cliente de vSPHERE dentro de nuestro MAC OSX como si de forma nativa se tratase. Para ello y no alargarme en demasía os explicaré un poco por encima los pasos previos necesarios para tener nuestra aplicación virtualizada y poder tirar desde DAZZLE para finalmente ejecutarla.

Lo primero que deberemos es descargarnos desde CITRIX la aplicación desde aquí y recordaros de la necesidad de tener cuenta con Citrix para poder hacerlo. (Paso muy sencillo).

Necesitaremos para el correcto funcionamiento de todo:

1. Un escritorio limpio de aplicaciones y en el cual sólo tengamos instalado Citrix Stream Profiler. Para posteriormente instalar el cliente vSphere cuando sea necesario. Recordar que trabaja de forma muy similar a VMware ThinApp.
2. Un servidor de Citrix XenApp
3. Una carpeta compartida donde alojar el PROFILE (Aplicación virtualizada).
4. Citrix Dazzle para MAC OSX

Una vez dicho todo esto comenzaremos:

Abrimos nuestro Desktop limpio de aplicaciones a excepción claro está de nuestra aplicaión Citrix Stream Profiler para virtualizar aplicaciones. Vamos hasta Stream Profiler y lo ejecutamos …

Para que empiece a reconocer nuestro entorno (Pre-escaneado antes de instalar el Cliente de vSphere), introducir para que sistemas operativos queremos que sea compatible y con qué Service Packs.

Luego instalaremos nuestro Cliente vSphere y nos hará un POST-escaneado de esta.

Y llegados al final del WIZARD (Asistente) de Stream Profiler. Le daremos una ruta de una carpeta compartida en la RED para finalmente guardar nuestro Profiler (Aplicación Virtualizada).

Aquí podemos ver una pequeña parte de mi entorno vSphere en el que podemos ver una Granja de Servidores XenApp, aunque realmente con uno de ellos nos serviría para la puesta en marcha de nuestra aplicación.

También podéis ver un Citrix Secure Gateway que utilizo para la conexión a las APLICACIONES o escritorios Virtualizados desde la Red WAN, este Server no es necesario si sólo vamos a conectarnos en una Red LAN.

Ahora nos iremos a nuestro/s Servidor de XenApp y abriendo la consola principal de gestión, nos moveremos hasta nuestra GRANJA de XenApp y al apartado de Aplicaciones y desde este crearemos una nueva aplicación que será la creada anteriormente con Citrix Stream Profiler.

Le damos al asistente e introducimos el nombre representativo de nuestra aplicación virtualizada, siguente …

Aquí en este paso seleccioneremos: distribuida si es posible ,si no, de otro servidor y haremos click en SIGUIENTE …

En este paso siguiente, escribiremos la dirección UNC donde hemos alojado a nuestro archivo profile de Stream Profiler en la carpeta compartida de la RED. Como podemos ver nos aparecerá el icono de nuestra aplicación (vSphere Client). Selecciona siguiente y terminaríamos continuando el asistente y dándole los matices necesarios de pantalla, conexiones , comportamiento al abrirse, quien tiene acceso a las aplicaciones (Grupos,Usuarios) etc…. de nuestra aplicación.

Cabe reseñar que aconsejo también instalar esta aplicación dentro de XenApp (de manera STANDARD) sin necesidad de Stream profiler para darle en el apartado de ruta local a esta aplicación y así asegurarnos que la aplicación siempre arranque en caso de error de RED con nuestra ruta UNC.

Y aquí ya podemos ver varias aplicaciones que uso en STREAMING, y ¡cómo no! A nuestro querido cliente de vSphere entre ellas.

Ahora ya por fin vamos a nuestro MAC OSX donde descargamos DAZZLE desde Citrix y que podemos ver en nuestro ScreenShot de nuestro escritorio, lo seleccionamos y ejecutamos con doble click …

Y aquí tenemos una primera vista de la apertura de nuestro DAZZLE:

Y sobre el botón derecho de la parte superior haremos click en PREFERENCES para introducir la dirección URL de nuestro Servidor Web Interface de nuestro XenApp ó nuestro SecureGateway.

Y en el apartado de Dazzle Stores como ya he mencionado hace un momento introducimos la dirección URL de nuestro/s Servidor donde nuestro DAZZLE se conectará para lanzar vSphere Client vía Streaming. El formato como podeis ver es:

http:///Citrix/PNAgent/config.xml (Para clientes en una LAN)

https:///Citrix/PNAgent/config.xml (Para clientes con Secure Gateway o Acces Gateway en una RED LAN+ WAN).

Y por fin tendríamos nuestro PORTAL con las aplicaciones a las que tendríamos acceso. A la derecha de cada aplicación nos aparecería un botón ADD para añadir las aplicaciones que queremos tener en nuestro MAC OSX. En el ScreenShot aparece el botón Remove porque ya las había añadido anteriormente.

Abajo en la izquierda sobre la Carpeta DAZZLE con botón derecho seleccionaremos Show in Fider para ir a la carpeta donde se alojan nuestras aplicaciones virtualizadas en nuestro MAC OSX.

Seleccionamos vSphere Client y nos creamos un icono en nuestro escitorio del MAC.

Y aquí tenemos nuestro icono del Cliente de vSphere en nuestro escritorio como si estuviese instalado de forma nativa.

Hacemos doble click sobre el icono y la aplicación se lanza vía Streaming contra nuestros servidores XenApp. Podemos ver en el icono AZÚL del plug-in de Citrix.

Y nos aprece el cliente de vSphere, introducimos la dirección de nuestro vCenter en mi caso, usuario, contraseña ,y finalmente hacemos LOGIN …

Y por fin tendremos abierto nuestro Cliente vSphere para trabajar en nuestro MAC OSX de forma totalmente natural como si estuviese instalado en nuestros MAC.

Bueno hasta aquí por hoy, espero haberos podido aportar algo más a vuestros grandes conocimientos y os emplazo hasta la semana que viene para hablaros de algo nuevo sobre la virtualización.

Un saludo, y hasta la semana que viene

En este post voy hablaros de una nueva herramienta llamada VMware vSphere Host Update Utility.

Con esta herramienta serás capaz de actualizar y parchear un host ESX/ESXi sin VUM (vSphere Udapte Manager).

Una característica interesante de la herramienta vSphere Host Update Utility es la opción para actualizar servidores VMware ESXi existentes.

En este episodio #30 te voy a guiar a través del proceso de actualización de un host ESXi. Veremos como escanear un servidor ESXi y como actualizar este con nuevos parches:

La mejor manera de determinar si tu entorno VMware vSphere 4.x está experimentando problemas de latencia en disco, es monitorizando los contadores de latencia de tus discos (FC, iSCSI, NFS).

Para poder analizar esta latencia en las LUNs de tu entorno, has de usar la opción Advanced de la utilidad de Performance que se incluye con VMware vCenter Server.

En particular, deberías verificar los dos contadores siguientes:

Kernel disk command latency: Este contador mide el tiempo medio empleado por el VMkernel para procesar un comando SCSI. Un número alto en este contador – de entre 2 a 3 milisegundos – puede significar dos cosas: que tu cabina tenga un exceso de trabajo o que sea tu servidor ESX/ESXi el que tenga un exceso de trabajo.

Physical device command latency: Este contador mide el tiempo medio que el dispositivo físico (disco) necesita para completar un comando SCSI. Un número alto en este contador – depende de tu cabina pero en general este valor está entre 15 y 20 milisegundos – puede significar dos cosas: que tu cabina va muy lenta o que tu cabina tiene un exceso de trabajo

En este episodio #29 te enseñare analizar los contadores de latencia de disco anteriormente mencionados con el Performace Chart incluido en vCenter:

Que tal? Como estáis? Soy Jose Maria Gris y como cada jueves estamos aquí para comentar algo nuevo sobre este ecosistema de VMware.

Hace algun tiempo, en este mismo blog, nuestro amigo Chema nos hablaba de lo útil que es usar “Host Profiles”.
Bien, guardas un profile “baseline” para que todos tus host tengan los mismos vswich, configuraciones de Firewall, estructura de IP’s parecidas, todo más uniforme y más fácil de gestionar.

Un día te llega un host que cuando le instalas ESX ves que el orden de las tarjetas físicas no te gusta. La vmnic0 siempre la tengo en placa madre, o bien, sencillamente, las otras máquinas están de forma distinta. También te puede pasar que falte alguna vmnic y el host profile no aplique correctamente, “vmnic0 not found”.

Entramos en la service console y editamos el fichero/etc/vmware/esx.conf . Verás que es un fichero de texto plano, como son habitualmente los ficheros de parametrización y en el tercer o cuarto bloque vienen las definiciones de la vmnic. Editándolas e intercambiando sus nombres podrás hacer que la vmnic0 sea la de la Motheboard como querías, por ejemplo.

Hasta la semana que viene. Take Care

VMware vSphere update1 incluye ahora una herramienta independiente de comprobación antes de actualización de los servidores ESX/ESXi y que está disponible como parte del binario de instalación de vCenter Server.

Esta utilidad, de forma pro-activa, analiza los servidores VMware vSphere ESX/ESXi para encontrar posibles problemas que puedan surgir mientras se actualizan los agentes de vCenter, el cual es parte del proceso de actualización de vCenter Server.

Es posible ejecutar esta herramienta de forma independiente antes de actualizar una instancia existente de vCenter Server. La herramienta puede ayudarte a identificar cualquier problema con la configuración, conexión en red, espacio en disco u otros asuntos relacionados con los servidores VMware vSphere ESX/ESXi los cuales podrían prevenir que algun hosts ESX/ESXi pueda ser gestionado por vCenter Server después de haber hecho una actualización vCenter Server.

En este episidio #28 te mostrare como ejecutar la herramienta de VMware Upgrade Pre-Check y como lanzar un escano customizado en busca de posible problemas con nuestros servidores ESX/ESXi:

El fichero swap de la máquina virtual se crea cuando se enciende la máquina virtual y se borra cuando esta se apaga.

En VMware vSphere hay cuatro alternativas en cuando a donde dejar el fichero swap:

1. En un disco compartido junto con los ficheros de la máquina virtual
2. En un disco local del servidor ESX/ESXi y la máquina virtual en un disco compartido
3. En un disco dedicado compartido, diferente del disco compartido donde se guarda la máquina virtual
4. En un disco local del servidor ESX/ESXi junto con los ficheros de la máquina virtual

La elección en la localización de este fichero swap de la máquina virtual va a depender de si estas intentado optimizar funcionalidades como VMware vMotion y VMware Site Recovery Manager.

En este episodio #27 te mostrare como cambiar la localización de los ficheros swap de las máquinas virtuales en un disco local en los servidores ESX/ESXi y su impacto:

Hola que tal?

Soy José Mª Gris y como cada semana vengo a comentaros alguna cosa sobre el ecosistema de Virtualización con VMware.

Días atrás, nuestro amigo jnavapal nos preguntaba lo siguiente:

“Te explico mi actual situación he configurado mis servidores para poder realizar vmotion y drs pero me he encontrado con al sorpresa que no me deja uno de ello por problemas con la mascara “eax” me gustaría, si pudieras, q me explicaras un poco como solucionar ese problema y que implicaciones tiene”

Como comenté en su día, no está soportado por VMware, pero lo he visto funcionar y evidentemente lo desaconsejo para producción. Quede claro que lo que aquí comento es a efectos formativos y no significa para nada ninguna recomendación.

Dicho esto, esto ocurre cuando tenemos procesadores distintos con niveles distintos. Es importante que tengamos a mano la herramienta de run virtual VMware CPU Host Info. Nos la descargamos y la ejecutamos desde un entorno windows que tenga acceso a nuestro vCenter (Vicente para los amigos) y a nuestros hosts.

Lo ejecutamos con la opción debug (importante) para que nos muestre los binary directamente.

La primera pantalla nos mostrará nuestros ESX, cuantas CPU tienen, si soportan FT, VT, etc., información interesante. Para el caso
que nos ocupa, mal vamos, las CPUs parecen iguales.

Pero lo que nos interesa de verdad viene en la ventana de atrás …

Aquí vemos los registros EAX, EBX, etc de nuestas CPUs. Pues sí son iguales, podremos hacer vmotion sin problemas.

Pero esto no es lo que nos preguntan. Si no falla Vmotion por este concepto, nos aparecerá un mensaje que nos dirá algo como “Hay un problema con el registro EAX”. Bien, entonces tendremos que hacerlos iguales.

Imaginemos una máscara y la “distinta”

0000 1110 0000 0000 0000 0000 0000 1000

0000 0000 0000 0000 0000 0000 0000 1011

Nos vamos a una VM, “Edit Setting”, “Options”, “CPUID Mask” y ahí en “Advanced”, nos aparecen nuestros registros de las CPUs y si hacemos click sobre uno veremos las máscaras (ya llegamos…. ). Las máscaras que nos interesan son las X (Unused), 1 (enable feature), 0 (Hide feature) y la H (Allow Guest software to see actual feature value.) Con ello si tenemos

XXXX HHHH XXXX XXXX XXXX XXXX XXXX HHHH

Querrá decir que el segundo y el cuarto cuarteto son los que “permiten”, con ello lo que deberíamos modificar es lo siguiente

—- 000- —- —- —- —- —- 0-00

y quedaría como final mask:

XXXX 000H XXXX XXXX XXXX XXXX XXXX 0H00

Y esto hacerlo a las VM que queremos hacer vMotion. Reitero, no lo uséis en producción.

Aprovecho para indicar las opciones “Hide the NX flag from Guest” (Con lo que podemos ganar compatibilidad en vMotion pero podemos perder algúna feature de seguridad de nuestra CPU. “Expose the NX flag to guest” Mantendrá todas las features de seguridad activas.

Implicaciones. Cuidado con usar la máscara porque podemos estar deshabilitando alguna feature importante y podemos tener problemas. hay que mirar las documentaciones de los procesadores y perdonad si soy pesado, nunca en producción. Con vSphere puedes hacer Baselines de procesadores para vMotion o junta maquinas entre iguales para hacer vMotion entre iguales.

Hasta la semana que viene. Cuidaros.

Por favor, si te ha gustado este post dame tu puntuacion: [ratings]

La sincronización de la hora de las máquinas virtuales con sus respectivos servidores VMware ESX/ESXi debería, cuando menos, estar siempre bien configurado por tres razones fundamentales:

1. Te proporciona un registro de entrada en los logs con el tiempo adecuado
2. Te proporciona el registro de entrada exacto en los gráficos y contadores de rendimiento de vSphere
3. Te proporciona el adecuado funcionamiento de las aplicaciones de la máquina virtual. Por ejemplo, en aplicaciones multitiered, la sincronización es fundamental para garantizar que las transacciones de base de datos se procesan correctamente.

Actualmente la mejor practica recomendada por VMWare en cuanto a sincronizar el reloj de las máquinas virtuales, es deshabilitar la sincronización via VMware Tools y usar un cliente NTP o el servicio de Windows w32time.

En este episodio #26, te enseñare esta mejor práctica que ha cambiado con el tiempo y que ahora VMware recomienda usar las herramientas nativas de Windows en lugar de las VMware Tools:

Hola amigos, soy Florián Murillo y voy a hablaros de VMware Capacity Planner, que como muchos sabéis, es la herramienta de VMware para la estimación y el análisis de las necesidades de equipamiento para grandes proyectos de virtualización, lo que llamamos habitualmente consolidación, o como he oído en algún ambiente, sublimación (suena poético).

VMware Capacity Planner es una herramienta que ayuda al integrador a dimensionar la infraestructura de hardware que vamos a necesitar para consolidar nuestros servidores físicos en ESXs y os detallo los 10 puntos claves de la herramienta, a mi modo de ver :

1. Es un servicio cloud (http://optimize.vmware.com) al que reportan colectores de datos instalados en la red a consolidar, por tanto no hay que mantener ninguna infraestructura para ofrecer el servicio.
2. Es extremadamente útil en proyectos de VDI donde nos ayudará a estandarizar aplicaciones y dimensionar la VM que entregaremos al usuario, porque no todos los usuarios necesitan VM del mismo tamaño, ni con las mismas aplicaciones.
3. Nos “fuerza” a utilizar una metodología ya probada en muchos clientes y que ha demostrado que funciona bien, con lo que casi es una “best practice” de como se ha de hacer una consultoría de consolidación.
4. Detecta equipos antiguos, perdón “legacy” y equipos no virtualizables por consumo, ya que nosotros definimos los umbrales de recursos que han de quedar disponibles en los ESXs.
5. Permite modelar con diferentes equipos de forma rápida, ¿Que ROI es mejor? utilizando sistemas con 2 sockets y 4 cores, 2 sockets y 6 cores o 4 sockets y 4 cores.
6. Podemos de forma simple hacer cambios en los escenarios y volver a calcular, con lo que podemos plantear todos los escenarios que necesitemos en muy poco tiempo.
7. Nos proporciona información de nuestros consumos actuales en Kwh y disipación térmica en BTU/h, lo cual se traduce directamente en dinero y los valores que quedarán al final.
8. Indica los racks que quedarán al final, con el consiguiente ahorro de espacio.
9. Realiza un informe de progreso (para que el cliente siga de cerca la evolución de la consultoría), realiza un Resumen ejecutivo en formato presentación y un análisis técnico con los datos recogidos y los cálculos realizados, todos en “perfecto” ingles y con el logo de VMware).
10. Es gratis.

Como os podéis imaginar, para que necesitemos esta herramienta hacen falta proyectos e consolidación de más de 100-200 servidores, en el caso de proyectos VDI esas cifras son más fáciles de alcanzar.

Y está a nuestro alcance con solo hacer un curso presencial de 1 día o on-line desde el VMware Partner Central, y pasar el correspondiente examen on-line de 15 preguntitas, y después podemos utilizarla sin costes adicionales con el usuario que nos proporciona Vmware.

Existen otras herramientas en el mercado, pero si queréis utilizarlas, os recomiendo pasar primero por esta y podréis valorar en su justa medida si lo que pagáis por otras merece la pena.

Por favor, si te ha gustado este post dame tu puntuacion: [ratings]

Hola, que tal, como estais? Soy Jose Mª Gris y como cada jueves estoy aquí con vosotros para hablar de tema relacionados con el ecosistema de VMware.

Hoy vamos a ver una de esas historias que no sabes porque, pero al final acabas haciendo funcionar.

Situación: Tenemos una máquina VM con SO Guest XP. Esta máquina fue creada en su momento de forma un tanto “ a la ligera” y no se configuró el HD como SCSI, sino como IDE.

De acuerdo con la KB de VMware, editas el .vmx y cambias ddb.adapterType = “ide” por ddb.adapterType = “lsilogic” o en su caso ddb.adapterType = “buslogic”. Nada más queda que quitar este disco con “edit settings” de la VM (teniendo en cuenta de no hacer “Remove from disk” y seguidamente volvemos a añadirlo con Add, Hard Disk, Use existing Disk, seleccionando el mismo disco. El scsi ID debe leer SCSI 0:0. Sin más.

Pues bien, alguna veces me funciona y algunas veces no, dándome unos bsod de las narices.

Como lo solvento? Pues cuando tengo la VM antes de empezar me voy a la web de LSI e instalo en el SO Guest la WHQL 1.20.18.00 e instalo el driver sobre el HD IDE. Cuando este IDE “resucita” como LSIlogic encuentra el driver perfectamente y no me asusta con la bsod.

Si alguien conoce porque a veces va y a veces no, adelante. Cuidaros.

Por favor, si te ha gustado este post dame tu puntuacion: [ratings]

Hola, ¿Qué tal? Soy Jose Mª Gris y hoy vamos a ver como solventar algún problema que nos puede aparecer al crear datastores locales en nuestro vSphere.

Tenemos nuestro ESX y además del disco en que bota nuestro vSphere tenemos otros discos donde queremos crear datastores locales. Cogemos nuestro vCenter, “Add storage”, “Disk”, vemos y seleccionamos el recurso, y cuando vamos a añadirlo y formatearlo nos da error. Por mucho que probamos, no podemos añadirlo.

Esto ocurre cuando queremos crear un volumen VMFS y partición que está en la misma controladora que el storage local, este volumen está continuamente bloqueado por la Service Console. Lo mismo nos puede ocurrir quitando un recurso local en las mismas circunstancias.

Si usas la línea de comandos, este estado no esta tomado en cuenta, por lo que podrás añadir o quitar estos recursos. En nuestra Service Console, identificaremos el disk que deseamos añadir http://kb.vmware.com/kb/1014953

Ejecutaremos el comando fdisk –u , donde el identificador lo substituiremos por el identificador que hemos obtenido en el paso anterior.
n para nueva partición
p para primaria
1
Indicaremos el primer cilindro (o default)
Ultimo cilindro (o default)
t para cambiar el tipo de volumen
1 para seleccionar la primera partición
fb (valor hexadecimal para vmfs)
x para expert mode
b para inicio proceso de cambio de block de inicio
1 de primera partición
128 para establecer el starting block
w para guardar la información

Guardamos y rebotamos el ESX para que tome en consideración los cambios.

Ejecutamos vmkfstools:

vmkfstools -C vmfs3 -b “block size” -S “nombre de datastore” “identificador”:”partición”

Cuidado. Si la nueva partición está en el mismo disco que la service console, el I/O funcionando y con una controladora PERC, vmkfstools puede no funcionar correctamente, habrá que hacer otro procedimiento.

Hasta la semana que viene.