Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

Seguimos aumentando nuestro catálogo de comandos/scripts con una sencilla utilidad que encuentra la virtual machine propietaria de una IP concreta, informándonos del nombre de la VM en el inventario de nuestro vCenter Server.

C:\> get-vmaddress -ip <direcciónIP>

Código :

param(
[parameter(mandatory = $true)]
[string]$ip)
$exito = $false
$vms = get-vm
foreach($vm in $vms) {
$ipes = $vm.guest.ipaddress
foreach($ipe in $ipes) {
if($ipe -eq $ip) {
write-host “VM encontrada”
write-host $vm.name
$exito = $true
}
}
}
if($exito -eq $false){
write-host “Nombre no encontrado”
}

Observaciones :

1. Utilizamos el comando param para forzar a la entrada de la IP. Si no pusiéramos la IP nos la pediría porque está definida como mandatory.

2. $vm.guest.ipaddress crea un array de objetos con las IPv4 y las IPv6 de la VM.

3. Solo analiza las VMs arrancadas.

Os adjunto la respuesta del comando en unos ejemplos:

[vSphere PowerCLI] C:\s> .\get-vmaddress.ps1 -ip 10.10.1.230

Nombre no encontrado

[vSphere PowerCLI] C:\ s> .\get-vmaddress.ps1 -ip 10.10.1.130

VM encontrada

vsh130

Espero que este nuevo comando/script os sea útil en vuestro día a día y aumente vuestro catálogo de nuevos comandos.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

Cuando preguntas a colegas de profesión ¿Cómo hacéis un listado de la versión de vmtools instalada en las VMs? En muchas ocasiones te contestan “utilizo RVTools”, es cierto que es una gran herramienta pero también es una gran oportunidad para escribir un script en PowerCLI y aumentar nuestro catálogo de scripts.

El script tiene 3 partes:

1. Conexión a vCenter
2. Ejecución del código
3. Desconexión de vCenter

#

# Conexión a vCenter Server

#

$vc = connect-viserver 10.10.1.100

#

# Proceso sobre todas las VMs del inventario

#

get-vm | %{get-view $_.id} | select name, @{name=”versionVMtools”; expression={$_.config.tools.toolsVersion}}

#

# Desconexión

#

disconnect-viserver $vc -Confirm:$False

a continuación veremos la salida por pantalla del script:

Name                      versionVMtools

—-                      ————–

vsh130                        2147483647

vShield-FW-10.10.1.101              8192

lnx231                              8384

vsa100                        2147483647

lnx232                              8384

lnx233                              8384

lnx234                                 0

dns230                                 0

Al ver la salida por pantalla observo tres tipos de números:

Versión 8192 – Corresponde a la versión de vmtools de un ESX v.4.0.

Versión 8384 – Corresponde a la versión de vmtools de un ESX v.5.0

Versión 2147483647 – Corresponde a versiones OEM de vmtools, nosmalmente, como en mi caso, son las que vienen con algún virtual appliance.

Versión 0 – VMs sin VMtools operativas. En mi caso no están instaladas las VMtools en estas VMs.

¿Cómo se que 8192 corresponde a un ESX 4.0?

En la web de VMware obtenemos esta información, os adjunto el contenido del archivo actual:

# VMware version-mapping file.

#

# This file provides a one-to-one mapping between VMware Tools for

# ESX/ESXi version-number codes, and paths to OSP repositories suitable

# for that Tools version.

#

8481        ../unsupported/tools/esx/mn_next

8389        esx/5.0u1

8384        esx/5.0p02

8384        esx/5.0

8300        esx/4.1p05

8300        esx/4.1u2

8300        esx/4.1p04

8295        esx/4.1p03

8295        esx/4.1u1

8290        esx/4.1

8289        esx/4.1

8288        esx/4.1

8196        esx/4.0p11

8196        esx/4.0u4

8196        esx/4.0p10

8196        esx/4.0u3

8195        esx/4.0u2

8194        esx/4.0u1

8193        esx/4.0

8192        esx/4.0

7304        esx/3.5p25

7304        esx/3.5p24

7304        esx/3.5u5

7303        esx/3.5u4

7302        esx/3.5u3

Espero que os animéis a tener un catálogo de scripts BIEN documentados.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

A la hora de diseñar el networking de un host tenemos varias modos de configuración:

Virtual Switch Tagging (VST mode)

En este modo, todos los port-group tienen una VLAN definida, entre 1 y 4094. Todos los vmnic entregados a estos switches virtuales se conectan a puertos configurados como trunk 802.1q en los switches físicos.

Este modo permite que varios port-groups puedan compartir vmnic de salida, aprovechando anchos de banda no utilizados.

Es el modo habitual de configuración y, el recomendado en las Buenas Prácticas de VMware, salvo configuraciones especiales. En esos casos utilizamos los otros modos.

External Switch Tagging (EST mode)

En este modo, los port-group se configuran con VLAN0 y el adaptado vmnic se conecta a un puerto de acceso. Un puerto que no acepta tráfico 802.1q y que pertenece a una sola VLAN.

Este modo no optimiza el tráfico de la vmnic, ya que no podemos compartir adaptador entre dos port-group de diferentes VLANs.

Me he encontrado este modo en entornos virtuales pequeños y muy estáticos, posiblemente el único escenario en producción donde se puede utilizar.

Virtual Machine Guest Tagging (VGT mode)

Es el modo mas exótico, pero en ocasiones es necesario. Es el modo utilizado cuando el tráfico de las VMs sale encapsulado en 802.1q. El port-group se configura como VLAN4095 y la vmnic se conecta a un puerto de switch físico configurado como trunk 802.1q.

Solo lo he visto utilizar cuando la aplicación tiene este comportamiento con el tráfico saliente de la VM.

Estos modos se utilizan tanto en vSwitch como en dvSwitch y, lógicamente, se pueden combinar varios modos en un host.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

vSphere 5 incorpora la característica de Swap to Host Cache, que es la posibilidad de utilizar discos SSD para almacenar los ficheros de swap de las VMs. Me refiero al archivo .vswp.

Mi primera reacción fue ¿para qué voy a utilizar discos caros para archivos que sólo se utilizan si tengo contención de memoria? Pero, es una perspectiva limitada, en realidad estoy añadiendo memoria barata, no disco caro

Por tanto, aun siendo incompleto el tratamiento que vSphere 5 hace de los discos SSD, es una estrategia muy interesante y, más de un proveedor de servicios la utilizará para “ampliar RAM” con discos SSD de sus host y disminuir reservas de RAM en las VMs de los clientes. No me parece mala idea si no penaliza el SLA acordado.

¿Por qué digo que el tratamiento de los discos SSD es incompleto? Porque vSphere 5 no soporta TRIM.

TRIM se utiliza para evitar un problema que tienen los discos SSD. Con el tiempo degradan su rendimiento, por la estructura interna de las puertas lógicas NAND utilizadas.

TRIM es una orden que el SO envía a la controladora SSD para informarle que bloques se han liberado para su reutilización. Esto disminuye los procesos de borrado de puertas NAND, que se realizarían al llenarse el disco, ya que se van realizando en momentos de inactividad del disco. Este proceso evita la degradación del rendimiento y aumenta la vida del disco. TRIM requiere que tanto el SO como el disco SSD “hablen” TRIM.

Os adjunto una escala interesante de velocidades de acceso para tener conciencia del factor escala:

Además el espacio destinado a Swap to Host Cache es compartido por todas las VMs que corren en el host. Si destinamos 20 GB de disco SSD a esta función, creará 20 archivos de 1GB que serán compartidos por todas las VMs. NO crea archivos por VM, como hacemos en disco clásico.

Los discos SSD cada vez los tendremos mas presentes en nuestras infraestructuras virtuales.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

La semana pasada decíamos que la maduración pasa por la Automatización y, entre sus buenas prácticas, está la creación de procesos inversos. Es decir, scripts que deshagan lo realizado en otro script.

La semana pasada creamos un script llamado mountNFS, que montaba un recurso NFS en todos los host de un cluster.

Hoy toca realizar el anti-script, es decir, desmontar ese recurso de todos los host de un cluster.

Esto es lo que hacemos con el script siguiente llamado dismountNFS.

dismountNFS <cluster> <ds>

Donde :

<cluster> Nombre de cluster, el datastore será desmontado en todos los host de este cluster.

<ds> Nombre del datastore a desmontar.

Veamos el código del script

El escenario donde lo vamos a ejecutar lo puedes ver en la imagen de cabecera de este post:

Veamos el script en acción

PS> .\dismountNFS cluster4 nas1

Vemos en la imagen anterior que el datastore nas1 ha desaparecido y en Recent Tasks observamos que se ha desmontado en los dos host del cluster.

Espero que os sea de utilidad y, sobre todo, recordad que todo script que automatiza un proceso ha de tener el script opuesto, como el ying y el yang  Hasta el próximo viernes.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

Uno de los elementos clave en la maduración de las infraestructuras virtuales es la Automatización. Automatizar es sustituir tareas manuales que “tiran” de procedimiento para ser realizadas por scripts que realicen estas misiones.

Una gran herramienta para automatizar es PowerCLI. Y, una tarea que fácilmente podemos necesitar, es montar un nuevo recurso NFS a nuestros ESXi.

Veamos como podemos automatizar esta tarea. La imagen de cabecera adjunta refleja nuestro escenario.

Y creamos un script llamado mountNFS para realizar esta tarea, la estructura del script es

mountNFS <cluster> <ds> <path> <servidorNFS>

donde :

<cluster> Nombre de cluster, el datastore será montado en todos los host de este cluster.

<ds> Nombre del datastore que aparecerá en el inventario.

<path> El path del recurso NFS a montar

<nfsd> Servidor NFS que entrega el recurso

Vemos el script en la imagen adjunta

Veamos como actúa el script:

PS> .\mountNFS cluster4 nas1 /nfs/nas1 10.10.1.222

Vemos como en Recent Tasks aparece la acción realizada sobre todos los host del cluster y observamos como en host 10.10.1.121 nos aparece el nuevo datastore nas1.

¿Se ha montado el datastore en ReadWrite o ReadOnly?

Es una buena pregunta porque no le hemos especificado nada al script. Por defecto, el comando new-datastore aplicado a NFS se monta en ReadWrite, si queremos montarlo en ReadOnly solo hay que añadir -ReadOnly al final del comando.

En un entorno maduro, todo script ha de tener su anti-script o lo que es lo mismo, un script que deshaga lo que hemos realizado. Pero esto será el viernes próximo.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

A mediados de marzo salió una actualización de vSphere 5, que si bien no trae mejoras destacables, si resuelve problemas de “infancia” de la versión 5.

Cuando hablamos de actualizar un host ESXi, siempre nos viene a la cabeza vCenter Update Manager (VUM). El cual nos simplifica la actualización desde su consola integrada con vCenter Server.

Pero todavía hay muchas instalaciones sin VUM. Por eso repasaremos los mecanismos de actualización “a mano”.

Disponemos de tres mecanismos de actualización “oficiales”: vCLI, PowerCLI y localmente.

Primero descargamos de VMware el archivo update-from-esxi5.0-5.0_update01.zip

vCLI (desde vMA)

1. vicfg-hostops –server host01 –username root –password pass –operation enter

2. vihostupdate –install –bundle /ruta/update-from-esxi5.0-5.0_update01.zip

1. Entramos el host en modo mantenimiento

2. Actualizamos el host

PowerCLI

El archivo descargado lo descomprimimos y el contenido lo colocamos en el directorio:

/vmfs/volumes/datastore1/update/update-from-esxi5.0-5.0_update01

A continuación procedemos a la actualización:

1. $h = “host01”

2. connect-viserver -server $h -user root -password pass

3. $o_mihost = get-vmhost -name $h

4. $r = set-vmhost -vmhost $o_mihost -state “Maintenance”

5. install-vmhostpatch –vmhost $o_mihost –hostpath /vmfs/volumes/datastore1/update/update-from-esxi5.0-5.0_update01/metadata.zip

1. Asignamos el nombre de nuestro host a la variable $h

2. Nos autenticamos en nuestro host

3. Creamos una instancia de la clase host, que utilizaremos como parámetro de entrada

4. Ponemos el host en mantenimiento y el resultado lo guardamos en $r

5. Actualizamos el host

Localmente

1. vim-cmd hostsvc/maintenance_mode_enter

2. esxcli software vib install -d /camino/update-from-esxi5.0-5.0_update01.zip

1. Entramos el host en modo mantenimiento

2. Actualizamos el host

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

En unos meses estará disponible el curso oficial vSphere 5 Optimize & Scale.

Este es el nombre que VMware le ha dado a la segunda parte del vSphere 5 ICM, un curso que empieza donde el vSphere 5 ICM finaliza.

Os describo parte de su contenido:

• Configuración de la vMA.
• Trabajando con los comandos esxcli y vicli.
• Configuración de syslog server.
• Configuración de Switches Distribuidos.
• Comandos CLI para la configuración de red.
• IPv6, SNMP, NetQueue, DirectPath I/O, PVLAN y Network I/O Control.
• Configuración de sniffers de red.
• Análisis de problemas de rendimiento en redes.
• Configuración de policy-driven storage.
• VAAI y VASA.
• Configuración Storage DRS y Storage I/O Control.
• Análisis de problemas de rendimiento en almacenamiento.
• Host Profiles y vCenter Server Linked Mode.
• Análisis de rendimiento de CPU y Memoria.
• Configuración de DPM, Auto Deploy y Image Builder.
• Introducción a PowerCLI.
• Resolución de problemas en clusters.

Tendrá una duración de 5 días completos, como vSphere 5 ICM, con un 50% del tiempo de teoría y un 50% del tiempo de laboratorios.

Este curso prepara para la obtención de la certificación VCAP5-DCA.

El nombre definitivo del curso aún puede cambiar, pero el contenido está definido.

¿Qué diferencia existe entre el ICM, el FastTrack y este nuevo curso?

En una escala de contenidos del 0 al 10, podríamos reflejar el contenido de cada curso como:

¿Qué os parece? ¿Os lo vais a perder? Tanto ICM como FastTrack empiezan de 0, y Optimize & Scale empiezan donde acaba ICM.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

La semana pasada, Cisco presentó novedades en su arquitectura de Datacenter, concretamente en los servidores Cisco UCS. Parece raro hablar de servidores y Cisco en la misma frase pero, en los últimos años, la visión global de Cisco les ha permitido hacerse un hueco en este mercado tan competitivo, donde tenían una experiencia y cultura nula, pero con una visión global muy clara y recursos para llevarla adelante.

Las novedades son de amplio espectro. Van desde la integración de los Cisco UCS formato rack (clase C) con los Cisco UCS formato blade (clase B), hasta nuevos Cisco Nexus 3000 con latencias de microsegundos.

Pero de todas las novedades, algunas marcarán una tendencia a seguir por la competencia, son las siguientes:

Cisco UCS VIC 1280

Es un módulo de red para Cisco UCS clase B que proporciona una conectividad de 2x40Gbps. Posiblemente la primera solución de esta velocidad para este tipo de productos, aunque se esperan novedades de otros fabricantes para dentro de muy pocos días.

Cisco UCS 2204XP

Módulo de red para los chasis de blades de Cisco UCS con 4x40Gbps. Es una necesidad si utilizamos el Cisco UCS VIC 1280. Con este módulo tenemos un ancho de banda por chasis de 160Gbps !!!

Cisco UCS B200 M3

Servidor blade con los recién presentados procesadores Intel E5-2600 con 2 sockets, 8 cores/socket y con hyperthreading.

En definitiva potencia, potencia y potencia. Quien pensaba que Cisco, al desconocer el mercado de servidores, no podría seguir el ritmo de la competencia, se equivocaban… yo el primero.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.

La virtualización de servidores es la culpable de necesitar cada vez más capacidad de computación en, cada vez, menos sitio. Los fabricantes lo saben y no dejan de aumentar la potencia de los servidores: con mas sockets, mas cores, más memoria RAM… y cuantas sutilezas varias se les ocurra.

Pero este fenómeno tiene una consecuencia adicional: cada vez necesitamos más I/O, lo que supone un reto a los “fabrics” y las redes Ethernet.

Los fabricantes de I/O también son infatigables en la incorporación de nuevas tecnologías a sus equipos, aunque la mayoría llaman menos la atención que la potencia de computación en bruto.

Hoy hablaremos de Virtual Port Channel (vPC), una característica que proporciona ancho de banda y escalabilidad SIN spanning-tree. Definitivamente, las nuevas tendencias de Networking para Datacenter prescinden del viejo amigo spanning-tree. Ahora, no podemos aceptar en una topología de red que un camino caído produzca un recálculo de la topología y unos segundos de desconexión. La verdad es que estoy de acuerdo.

Hasta ahora, puedo crear un port-channel utilizando IP hash como algoritmo de balanceo en el Switch virtual y, agregando varios interfaces para proporcionar escalabilidad y alta disponibilidad. La limitación es que necesito que los puertos del switch físico donde acaban estos cables sean del mismo switch.

Ahora con vPC puedo hacer lo mismo utilizando interfaces de diferentes  switches físicos, lo cual, simplifica mucho el diseño, sobretodo si tengo pocos interfaces de mucho ancho de banda, como ocurre con diseños con interfaces de 10Gb.

En la imagen de la cabecera se observa un ejemplo de aplicación de vPC. Un host ESXi se conecta mediante dos interfaces de 10Gbps a dos switches distintos, creamos un vPC y disponemos de un troncal de 20Gbps que repartiremos como nos convenga.

A partir de este ejemplo ya nos podemos imaginar la escalabilidad añadiendo un par de interfaces más y teniendo un ancho de banda más que aceptable.

Luego nuestro problemas serán otros: si de cada host salen más de 20Gbps de tráfico, de un rack puedo necesitar transmitir un ancho de banda de muchos Gbps, trasladando el reto a las capas de distribución y core de nuestra estructura de red… Y esto, no está al alcance de muchas PYMES, por ahora …

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.