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, que tal, como estáis? Soy Jose Mª Gris y como cada jueves(hoy miercoles) estoy aquí con vosotros para hablar de tema relacionados con el ecosistema de VMware.

Los requerimientos para una máquina virtualizada para vCenter Server son: 2 Procesadores y 3 Gb de RAM.
Pues bien, muchas veces, por aquello que pasa, que con “tanto” ya funciona y pasa lo que pasa.

Oye, ¿Por qué el servicio de vCenter Server siempre falla al arrancar?. Si miras el error, verás que ha intentado arrancar antes que el SQL, la máquina no tenía suficientes recursos para todo.

Como lo solventamos?
Primero. Poniendo suficientes recursos. Segundo. En Windows 2003 podemos configurar que un servicio dependa de otro, que vCenter dependa de SQL. Editamos la clave de registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd\DependOnService

Le añadimos MSSQL$SQLEXP_VIM

Con ello aseguraremos que nuestro vCenter arranque cuando deba.

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

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.

Hola amigos, soy Florián Murillo y hoy hablaremos del futuro nuevamente, hablaremos del futuro que le depara a nuestro inestimable amigo Service Console, la estrategia de futuro de VMware es apostar por ESXi, animando a sus clientes a migrar de ESX a ESXi, los administradores de seguridad están contentos ya que tienen un dominio de gestión menos (el Service Console), pero los administradores de sistemas no tanto, por la experiencia acumulada durante años, con el CLI del Service Console.

De todas maneras, hay que decir que no parece una mala idea, y que simplemente nos hemos de acostumbrar a nuevas herramientas para gestionar nuestros ESXs, perdón, quería decir ESXi

El objetivo es doble, ya que estas herramientas las utilizaremos, no solo para hacer la explotación de nuestra infraestructura virtual, sino que también para construir los scripts que permitirán automatizar el aprovisionamiento, la eficiencia energética, la escalabilidad, la disponibilidad, el rendimiento y la seguridad de nuestro datacenter.

¿Que herramientas pone a nuestra disposición VMware para facilitar el transito? en realidad no son nuevas, llevan con nosotros un tiempo, se llaman vCLI, PowerCLI y vMA.

vSphere CLI, también conocido como vCLI, funciona sobre Windows o Linux y es lo mas “parecido” a Service Console, son scripts hechos en lenguaje Perl, el lenguaje lo instala junto los scripts, adjunto un ejemplo :

Desde service console :

[root@esx72 ~]# esxcli nmp psp list
Name Description
VMW_PSP_MRU Most Recently Used Path Selection
VMW_PSP_RR Round Robin Path Selection
VMW_PSP_FIXED Fixed Path Selection

[root@esx72 ~]# vicfg-vswitch -l
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 32 5 32 1500 vmnic0

PortGroup Name VLAN ID Used Ports Uplinks
VM Network 0 2 vmnic0
Service Console 0 1 vmnic0

Desde vCLI :

C:\Archivos de programa\VMware\VMware vSphere CLI\bin>esxcli –server=”ESX1″ –username=”root” –password=”X” nmp psp list

Name Description
—- ———–
VMW_PSP_MRU Most Recently Used Path Selection
VMW_PSP_RR Round Robin Path Selection
VMW_PSP_FIXED Fixed Path Selection

C:\Archivos de programa\VMware\VMware vSphere CLI\bin>vicfg-vswitch.pl –server=”ESX1″ –username=”root” –password=”X” –vihost=”VCENTER” -l

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 64 4 64 1500 vmnic1,vmnic0

PortGroup Name VLAN ID Used Ports Uplinks
Nexus Packet Network 0 0 vmnic1,vmnic0
Nexus Mgmt Network 0 0 vmnic1,vmnic0
Nexus Control Network 0 0 vmnic1,vmnic0
Management Network 0 1 vmnic0,vmnic1

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch1 64 7 64 1500 vmnic5,vmnic3,vmnic2

PortGroup Name VLAN ID Used Ports Uplinks
Virtual Machine Network 0 3 vmnic5,vmnic3,vmnic2

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch2 64 3 64 1500 vmnic4

PortGroup Name VLAN ID Used Ports Uplinks
iSCSI 0 1 vmnic4

Aquí vemos una tónica general, la sustitución del prefijo esxcfg de los comandos del CLI del service console, por el prefijo vicfg habitual en vCLI. Muchos comandos esxcli se mantienen por compatibilidad, con la sencilla técnica de tener un comando vicfg-vswitch.pl y un duplicado del anterior con el nombre esxcli-vswitch.pl, pero desaparecerán tarde o temprano.

Si queremos automatizar con scripts hechos en Perl, es la herramienta adecuada, además funciona en Windows y Linux y combinandolo con vSphere SDK for Perl tenemos la herramienta para hacer cualquier cosa.

vSphere PowerCLI es un conjunto de más de 160 cmdlets escritos para ser utilizados desde Microsoft PowerShell, el lenguaje de scripting de Microsoft, es mas completo que los casi 30 scripts perl del vCLI, además incorpora vSphere SDK for .NET, interesante para ampliar posibilidades. No lo he dicho pero solo funciona sobre un SO Windows

Podemos realizar tareas tan interesantes como automatizar el desmonte de CDs en las VM para facilitar vMotion, o buscar VM que no estén registradas en el vCenter.

vSphere Management Assistant (vMA) es un virtual appliances con CentOS 5.2, vCLI, vSphere SDK for Perl, CIM, Java JRE y vSphere SDK for Java. Es una buena opción para aquello que quieran trabajar en Perl o Java.

Resumiendo, podemos configurar vía CLI nuestros ESX/ESXi con vCLI (lo mas parecido a configurar desde el service console) o PowerCLI, dependiendo de nuestros gustos y necesidades y si necesitamos scripts mas complejos tenemos la posibilidad de desarrollarlos en Perl o PowerShell.

Hablando con nuestro amigo José María González, apuntábamos la idea de crear “El rincón del script” o algo parecido, con explicaciones detalladas de los mismos, y lógicamente, todo en perfecto español, como es habitual en nuestro querido blog.

¿Que opinais? ¿Creeis que puede ser interesante?

La posibilidad de crear instantáneas – snapshots – de máquinas virtuales es una funcionalidad incluida en vCenter Server la cual permite conservar el estado de una o más máquinas virtuales para que puedas volver al mismo estado cuando sea necesario, es decir, como dicen por Irlanda, al estado de when the shit hits the fan.

Esta funcionalidad de poder crear instantáneas de las máquinas virtuales es muy útil, sobretodo, cuando se necesita volver a un estado posterior de una máquina virtual sin necesidad de tener múltiples máquinas virtuales.

Una instantánea captura el estado completo de la máquina virtual en el preciso instante cuando hacemos la instantánea. Esta instantánea incluye el estado de la memoria en ese preciso instante, la configuración de la máquina virtual y el estado del disco o discos virtuales de dicha máquina virtual.

En este episodio #21, te enseñare a crear y modificar una instantánea así como a volver a una copia anterior (go to) y a borrar una instantánea (delete) en caliente, es decir, mientras la máquina virtual sigue ejecutandose:

Nota: Las instantáneas de máquinas virtuales con discos RDM (Raw Device Mappings) en modo compatibilidad física NO están soportados.

En un servidor VMware vSphere ESX 4, si así lo estimas necesario, puedes cambiar el tamaño de la memoria destinada al Service Console.

Este cambio necesita un reinicio del servidor vSphere ESX 4 para que los cambios surjan efecto.

El cambio del tamaño de la memoria del Service Console afectara al fichero swap del Service Console. VMware recomienda asignar el doble del tamaño de la configuración de memoria del Servico Console para su partición swap.

El tamaño máximo del Service Console es de 800MB, por consiguiente la partición máxima para el swap del Service Console no pueden ser mayor de 1.600MB.

En este vídeo te enseñare como cambiar la configuración de memoria del Service Console y porque a veces es necesario hacer dicho cambio:

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.