Ansible + VMware. Crea y customiza VMs.

Ok, pues me subí al tren y decidí probar Ansible. Me sorprendió lo fácil de usar y lo poderosa que es como herramienta de automatización. Quise hacer un script, que en Ansible se llaman “playbooks”, para crear máquinas virtuales en vSphere y de paso customizar el sistema operativo, llendo mas allá de lo que se puede hacer con los perfiles de customización de vmware, al instalar Apache y mandar una notificación a Slack al momento de hacer el deploy. Pretty cool si me preguntan.

Lo primero fue hacer un template de un Ubuntu 14.04, lo único que le instalé fueron las VMware Tools, openssh-server y copié la llave SSH del host Ansible al archivo /root/.ssh/authorized_keys del Ubuntu, esto con el fin de poder administrar la nueva máquina virtual remotamente vía SSH desde el servidor de Ansible.

Otros pre-requisitos de la configuración del servidor Ansible:
– Tener instalado PySphere ( ~$ pip install -U pysphere )
– Configurar Fact Caching (http://docs.ansible.com/ansible/playbooks_variables.html#fact-caching)

Ok ok, este es el playbook …

_

Web_Client-ansible

Al terminar el script nos llega esta notificación a Slack 🙂

ansible-01

Aunque se hizo algo bastante simple como instalar Apache y cambiar el hostname, me queda claro que las posibilidades de automatizar un centro de datos con Ansible son casi infinitas, prácticamente limitado solo por la imaginación del admin. Basta revisar la documentación para ver lo que es capaz de hacer: http://docs.ansible.com/ansible/intro.html.

Espera sirva y si alguien gusta echarlo a volar, déjenme un comentario.

¡Suerte!

spotify:track:6MVXdWtPSNMlpn7BuGtCWD

KB2115997 – Otra de Snapshots

VMware publicó a principios de Julio el KB2115997 donde describe que una VM puede “congelarse” al momento de intentar crear un snapshot. Esto sucede con las siguientes versiones de VMware Tools y cuando el SO es Windows.

8.6.15
9.0.15
9.4.11
9.10.0
9.4.12

Hice un pequeño script de Powershell para ver las versiones de VMware Tools instalada en las VMs y determinar si hay alguna que corre riesgo.

Al momento no hay una solución para este problema en las versiones 5.x, aunque ya hay un parche para 6.0.

Liga al KB: http://kb.vmware.com/kb/2115997

¡Suerte!

spotify:track:186hvCTyrni4KT9nwIQ7zS

Reporte de discos virtuales. Tipo, tamaño, formato y ruta.

Aproveché que me pidieron ayuda en una migración de storage para hacer un script que me arrojara la información de la configuración y ubicación de todos los discos virtuales.

Algo importante que hay que tener presente en cuanto a la configuración de los discos virtuales (VMDKs), y que podemos observar con este reporte, es que a los discos independiente no le podemos tomar snapshot, por lo tanto no pueden ser respaldados por ninguna herramienta que utilice los VMware Storage APIs for Data Protection (VADP). Y en general siempre deberíamos de saber como y donde están creados los discos de los servidores.

En el script va el nombre de la máquina virtual, nombre del disco, capacidad provisionada, información sobre el formato, si es de tipo RDM, datastore en que se encuentra y carpeta. Creo podría ser buena idea si queremos documentar el inventario o vamos a comenzar a trabajar en el datacenter.

Va…

$MyVMs = Get-VM
foreach($VM in $MyVMs){
Get-VM $VM |Get-HardDisk |
Format-Table @{Name="VM";Expression={$_.Parent};a="left"},
@{Name="Disco";Expression={$_.name};a="left"},
@{Name="Capacidad GB";Expression={"{0:N1}" -f $_.CapacityGB};a="right"},
@{Name="Formato";Expression={if ($_.StorageFormat -eq 'Thin') { "Thin" } else { "Thick" }};a="center"},
@{Name="RDM";Expression={if ($_.ExtensionData.backing.LunUuid -ne $null) { "Si" } else { "No" }};a="center"},
@{Name="Independiente";Expression={if ($_.Persistence -eq 'Persistent') { "No" } else { "Si" }};a="center"},
@{Name="Persistente";Expression={if ($_.Persistence -eq 'IndependentPersistent' -or 'Persistent') { "Si" } else { "No" }};a="center"},
@{Name="Datastore";Expression={$_.FileName.Split(']')[0].TrimStart('[')};a="center"},
@{Name="Folder/VMDK";Expression={$_.filename.Split(']')[1]};a="left"} -a
}

Y debemos de tener algo así por cada una de las VMs que queramos revisar…

Captura de pantalla 2015-02-20 a las 23.15.19

Espero les sea de utilidad…

spotify:track:2PMFI32xNoSXExAfFklKbb

¿Que VMs no se están respaldando? | Veeam + PowerCLI

Con este Script de PowerShell podemos crear una lista de las máquinas virtuales las cuales no se encuentran en ningún Job de respaldo o replicación, por lo tanto en riesgo de perder información en caso de corromperse el sistema operativo o eliminar accidentalmente información, algo mas común que fallas a nivel de hardware.

El primer paso es generar una tabla con la lista de las VMs efectivamente protegidas. Posteriormente generamos una tabla con las máquinas virtuales que nos interesa proteger, que pueden ser de todo nuestro Datacenter, un Cluster, un grupo de hosts, VMs con cierto TAG, etc, etc… A esta lista la comparamos contra la lista de VMs que efectivamente se están respaldando/replicando y obtenemos las cuales no se encuentran en ningún Job.

Va el script…

## Variables de columna "Estado" ##
$on = "Encendida"
$off = "Apagada"

## Genera una lista de VM en todos los Jobs de respaldo (backup) ##
$jobs = get-vbrjob | where {$_.jobtargettype -eq "backup"}
$protected = $jobs.getobjectsinjob()
$vmresp = $protected.name

## Crea la tabla con las VMs que no aparecen en la lista de VMs protegidas en alguno de los Jobs ##
Get-VM $MyVMs | where{$_.name -notin $vmresp} |
Format-Table @{Name="VM";E={$_.name}},
@{Name="Nombre DNS";E={$_.guest.hostname};a="center"},
@{Name="IP";E={$_.guest.ipaddress[0]};a="center"},
@{Name="Estado";E={ if ($_.guest.state -eq $running) { $on } else { $off }};a="center"} -a 

En este script agregé un poco mas de info a la tabla con la intención de contar con suficiente información que me permita identificar al servidor virtual rápidamente, le incluí el hostname de la VM, su IP (requiere tener instaladas las VMware Tools) y su power state, pero le puedes agregar todos estos campos…

Captura de pantalla 2015-02-18 a las 23.23.57

La salida con la lista de las VMs sin protección es algo así…

Captura de pantalla 2015-02-18 a las 23.36.46

Espero les sea de utilidad.

spotify:track:40PZjzPaevtxWSReEG6RQ1

Identificar status de VMware Tools con PowerCLI

Instalar las VMware Tools en las máquinas virtuales es de la mayor importancia, instala drivers y scripts dentro de los sistemas operativos que permiten la utilización de harware virtual y realizar ciertas tareas administrativas remotamente, como apagar la VM como si se hiciera desde el sistema operativo.

Algo de documentación de VMware Tools:
https://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.vm_admin.doc/GUID-151025AE-6641-428B-9818-5E06916543F3.html

Este script de PowerCLI permite generar un reporte que ayuda a identificar si las máquinas virtuales de nuestro vCenter/Datacenter/Cluster/Folder/Pool tienen instaladas las Tools, están desactualizadas o nunca se han instalado.

Va el script:

## Variables para "traducir" los valores de Status de los Tools que arroja PowerCLI ##
$current = "guestToolsCurrent"
$unmanaged = "guestToolsUnmanaged"
$needsupgrade = "guestToolsNeedUpgrade"
$ok = "Ok"
$noact = "No Actualizado"
$noinstall = "No Instalado"

Get-VM | Where {$_.PowerState -eq "PoweredOn"} | 
FT @{Name="VM Name";Expression={$_.name};a="left"},
@{Name="VMware Tools";E={ if (($_.guest.ExtensionData.Toolsversionstatus -eq $current) -or ($_.guest.ExtensionData.Toolsversionstatus -eq $unmanaged)) { $ok } else { 
if ($_.guest.ExtensionData.Toolsversionstatus -eq $needsupgrade) { $noact } else { $noinstall }}};a="center"} -a

El script sólo arroja un par de columnas, el nombre de la VM y el status de las Tools.

Espero les sea de utilidad.

spotify:track:2sQwrhVWXpZHPIF6YQbUvT

Reporte Snapshots

En los últimos días me ha tocado apoyar en un par de casos de “monster Snapshots”, en un caso en particular el disco del snapshot consumió la totalidad del datastore y la máquina virtual no podía encender, afortunadamente la máquina virtual estaba configurada con 24GB de RAM por lo que bastó reservarle toda su memoria para liberar espacio suficiente y así se pudo encender la VM. Tuvimos suerte.

¿Pero que es un Snapshot?
Understanding virtual machine snapshots in VMware ESXi and ESX (1015180)

En corto, un snapshot es un disco “delta” que se crea cuando deseamos mantener un punto de restauración de una máquina virtual, NO ES BACKUP. Mientras exista dicho archivo “delta” todas las operaciones de I/O que tenga la VM se van a redirigir hacia el delta, dejando el disco original VMDK en un estado de “solo lectura”. Dicho archivo VMDK “delta” puede crecer hasta el tamaño provisionado de la VMDK original. He ahí la importancia de mantener los snapshot a raya.

La teoría dice que los snapshot deben de durar abiertos la menor cantidad de tiempo, sin embargo muchas veces se olvidan, o lo que he visto mas comunmente, las herramientas de respaldo dejan snapshots sin cerrar y si no los estamos monitoreando pueden tener graves consecuencias para nuestras VMs.

Hay mucha información en línea y vmware ha publicando documentación al respecto, sin embargo, sigue siendo muy común los casos de problemas con los mismos. No es la intención hacer un post de la teoría, mas bien quiero compartir un script de PowerCLI que hice para reportar snapshots abiertos, tamaño y cuanto tiempo llevan creados, con la idea de no tener que llegar al punto donde ya tenemos el problema encima.

Primero, el KB de mejores prácticas:

Best practices for virtual machine snapshots in the VMware environment (1025279)

Script:

$VMs = Get-Cluster -Name $MiCluster | Get-VM
foreach ($VM in $VMs) {
Get-Snapshot -VM $VM |FT VM,
@{Name="Tamaño GB";Expression={"{0:N1}" -f $_.SizeGB};a="center"},
@{Name="Fecha";Expression={"{0:dd-MMM-yyyy}" -f $_.Created};a="center"},
@{Name="Dias";Expression={"{0:N0}" -f ((get-date) - $_.Created).days};a="center"}, 
@{Name="Descripcion";Expression={$_.Description};a="left"} -a
}

Así se ve la salida del script y aprovecho para compartirles un ejemplo.

vm_1

Lo hice para que me arrojara la información de un cluster, pero puede ser editado para que arroje información de las VMs de todo el vCenter, Datacenter, Folder, Resource Pool, vApp, etc.. Con Task Scheduler se puede programar y que nos llegue el reporte por correo.

Es un pequeño script pero puede darnos información muy valiosa que nos puede ayudar a monitorear y así poder tomar medidas antes de que tengamos datastores completamente llenos o, en el peor de los casos, corrupción de discos de máquinas virtuales.

Espero les sea de utilidad.

spotify:track:07YhAU4StAFzsWv2gMCCPb

Exportar syslog de ESXi 5.x a Splunk Storm

Recientemente un cliente me pidió ayuda para exportar los logs que genera sus ESXi a algún servicio en la nube. Le propuse Splunk Storm, es buen servicio y además gratuito. Está muy limitado en espacio, 20GB, no te permite generar alarmas, entre algunas otras herramientas, pero como la idea es tener fuera del datacenter los logs en caso de que algo grave suceda y poder analizarlo, Splunk Storm resulto una muy buena opción.   Lo primero fue abrir la cuenta en SplunkStorm.com, una vez generada se crea un “Proyecto” …

add-proyect

Luego lo nombramos …

name-proyect

Seleccionamos la opción de configuración automática y Splunk nos asigna direcciones y puerto a donde apuntar los logs de los ESXi.

puertos-enviar-datos2

Ahora lo que hay que hacer es hacer la configuración en los ESXi y crear la regla de firewall con el puerto específico que nos entrega Splunk. Para esto se necesita crear un archivo XML y guardarlo en la ruta /etc/vmware/firewall/. Yo lo nombré “service1.xml” y con éste se crea la regla de firewall llamada “syslog-Splunk”

<!-- Firewall configuration information -->
<ConfigRoot>

  <!-- Known and blessed services -->

  <service id="0101">
    <id>syslog-Splunk</id>
    <rule id='0000'>
      <direction>outbound</direction>
      <protocol>udp</protocol>
      <porttype>dst</porttype>
      <port>21222</port>
    </rule>
    <enabled>false</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

Ahora hay que enviarlo al host ESXi, yo utilicé SCP y lo envié a la carpeta /etc/vmware/firewall/ en el host ESXi

guardar-XML

Ahora nos conectamos via SSH al host y revisamos que haya sido reconocido como una nueva regla del firewall

esxcli network firewall refresh
esxcli network firewall ruleset list

Ahora ya podemos ver listada la regla …

nueva-rule

..y también ya la podemos ver en el web client …

rule-webclient

Ahora utilizando un poco de PowerCLI apuntamos los logs del ESXi hacia el servicio de Splunk y habilitamos la excepción del firewall

Get-VMHost $interpol | Set-VMHostAdvancedConfiguration -Name Syslog.global.logHost -Value udp-xxxx-xxxx.data.splunkstorm.com
Get-VMHost $interpol | Set-VMHostSysLogServer -SysLogServer udp-xxxx-xxxx.data.splunkstorm.com -SysLogServerPort 21222
Get-VMHost $interpol | Get-VMHostFirewallException | where {$_.Name.StartsWith('syslog-Splunk')} | Set-VMHostFirewallException -Enabled $true

Volvemos a nuestra sesión de SSH y reiniciamos el servicio de syslog

esxcli system syslog reload

Ahora si, en unos momentos mas se registra el host en Splunk y comienza a recibir los logs …

nuevo-syslog-splunk2 listo2

 

Como podrán ver es un proceso sencillo y que permite contar con información para analisis detallado en caso de que algo salga mal en el centro de datos.

Hay muchas herramientas que se pueden utilizar como servidores de logs, puede ser cualquiera, ya que lo importante es tener esa información disponible en el momento que se requiera.

Fuentes:

http://www.virtuallyghetto.com/2011/07/how-to-create-custom-firewall-rules-in.html

http://kb.vmware.com/kb/2003322