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.

Esta semana, en el blog de virtualización y cloud computing en español, te explicare los comandos mágicos de VMware PowerCLI para poder terminar la instalación y configuración de una imagen de VMware ESXi en memoria con VMware Auto Deploy Server.

Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo instalar ESXi en memoria con VMware Auto Deploy? Parte II

En este vídeo te enseñare a instalar un binario de VMware ESXi con VMware Auto Deploy Server y a personalizar dicho binario con VMware Image Builder. Debido a que la instalación y configuración de este entorno es compleja, he decidido partirlo en dos vídeo tutoriales.

En el primer vídeo tutorial te enseñe a configurar e instalar los siguientes servicios de red:

• Servidor TFTP
• Servidor DNS
• Servidor Auto Deploy
• PowerCLI GUI

Por ultimo, en este segundo episodio veremos todos los comandos necesarios en PowerCLI que hay que ejecutar para desplegar, configurar y personalizar una imagen de VMware ESXi.

Hasta el próximo martes, donde os mostraré otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.

¿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.

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.

Cada virtual switch, es una representación lógica vía software de un switch físico de capa dos. Los tres tipos de virtual switch que puedes crear en un servidor ESXi 5 son los siguientes:

1. Internal switch only. Este switch es usado únicamente para conectar, vía red, las máquinas virtuales instaladas en el mismo servidor VMware ESXi, las cuales no necesitan conexión con el mundo exterior.

2. Virtual switch con un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network (gestión) y puertos VMkernel con el mundo exterior, o dicho de otro modo, con otros servidores y máquinas virtuales de nuestro entorno virtual.

3. Virtual switch con más de un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network y puertos VMkernel con el mundo exterior con una funcionalidad adicional, como es el balanceo de carga y redundancia a fallos en los componentes de red.

Las políticas de seguridad y de traffic shaping son configuradas a nivel de port group y vSwitch. Una configuración incorrecta del traffic shaping afectaría no sólo al tráfico de las máquinas virtuales sino también al tráfico en general.

En vSphere™ ESXi 5, una tarjeta mapeada a un switch virtual puede ser configurada para trasmitir y recibir tramas “Jumbo Frame”. El MTU (Maximum Transmision Unit) de un ”Jumbo Frame” es de 9000. VMware ESXi 5 también soporta “Jumbo Frames”, tanto en los VSS como en los VDS.

Ahora, también es posible activar desde la GUI de los VSS el uso de los mismos. La configuración de “Jumbo Frames” es considerada una mejor práctica para las redes de tipo iSCSI, vMotion y Fault Tolerance. Los tres tipos de virtual switch pueden soportar hasta un total de 4088 puertos por switch virtual estándar.

Para los tres tipos de virtual switch, no existen colisiones de red en el tráfico interno. Asimismo la dirección MAC de los adaptadores de red conectados a los virtual switches no será usada en ningún momento de forma interna.

¿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.

Esta semana, en el blog de virtualización y cloud computing en español, os explicare a monitorizar un entorno VMware vSphere en busca de cuellos de botella con una herramienta espectacular de monitorizacion llamada VMturbo que ademas es gratuita. ¿Qué mas puedes pedir, eh?

Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo detectar cuellos de botella en VMware vSphere con VMTurbo?

Hasta el próximo lunes, donde os mostraré otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.

¿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 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.

Esta semana, en el blog de virtualización y cloud computing en español, os explicare a eliminar cuellos de botella y mejorar el rendimiento de red en VMware vSphere 5.

¿Alguna vez te has preguntado como puedes poner un servidor VMware vSphere ESXi en modo mantenimiento desde una tarea programada? El problema inicial es que no es posible poner un host ESX/ESXi en modo mantenimiento desde el vCenter Server con una tarea programada. No obstante, SI es posible ponerlo en modo mantenimiento desde la nueva versión de VMware vSphere Management Assistant (vMA)

Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y VMware vSphere 5: ¿Cómo poner un ESXi en modo mantenimiento con vSphere Management Assistant?

Hasta el próximo lunes, donde os mostraré otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.

¿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.