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

Advertisements

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

Agrega en automático una nueva VM a un Job de Respaldo de Veeam

En este post mostraré una opción para agregar de forma automática una máquina virtual recién creada a un trabajo de respaldo de Veeam, todo esto utilizando PowerCLI y los cmdlet’s de PowerShell que nos ofrece Veeam.

El primer paso es identificar el evento dentro de vCenter de creación de una nueva máquina virtual. Puede haber otros métodos mejores, pero encontré una buena forma con el cmdlet “Get-VIEvent”, ya que incluye un campo llamado “FullFormattedMessage” que lleva la información del evento, sólo debo de buscar que patrón sigue cuando se crea una máquina virtual nueva. Sin embargo, hay diferencias entre como se describe una VM que es creada desde cero o con un OVA/OVF y una que es clonada.

Ejemplo de mensaje cuando es VM nueva:

FullFormattedMessage : Created virtual machine nueva1 on host.infra.lab in Lab

Ejemplo de mensaje cuando es clonada una VM:

FullFormattedMessage : Cloning Kiwi on host host.infra.lab in Lab to clon-kiwi on host host.infra.lab

Ok, ahora ya sabemos que textos “clave” deberíamos de incluír en el script, y nos auxiliaremos del cmdlet “Where-Object” para identificarlos entre los eventos generados en vCenter.

El Script está escrito pensando en ejecutarse cada 24 horas, si por ejemplo nuestros respaldos los ejecutamos una vez al día podemos correr el script antes de que se ejecute para que se incluyan las nuevas VM en nuestro entorno virtual.

Como se vería el Script…

## vSphere 5.5 + Veeam 8

## Aqui y ahora =)
$tiempo = Get-Date

## Buscamos en las ultimas 24 horas todas las VM creadas u OVA/OVF "deployed"
$nuevasVM1 = Get-VIEvent -Start $tiempo.AddDays(-1) | where {$_.FullFormattedMessage -like "*created virtual machine*"}
$nuevas1 = $nuevasVM1.Vm.Name
## Agregamos al job de respaldo $MiJob las VMs encontradas
foreach ($vm1 in $nuevas1) {
Find-VBRViEntity -Name $vm1 | Add-VBRViJobObject -Job $MiJob
}

## Buscamos en las ultimas 24 horas todas las VMs clonadas
$nuevasVM2 = Get-VIEvent -Start $tiempo.AddDays(-1) | where {$_.FullFormattedMessage -like "*Cloning*"}
$nuevas2 = $nuevasVM2.DestName
## Agregamos al job de respaldo $MiJob las VMs encontradas
foreach ($vm2 in $nuevas2) {
Find-VBRViEntity -Name $vm2 | Add-VBRViJobObject -Job $MiJob
}

Este script considera todas las VMs que se encuentran administradas en un mismo vCenter server, sin embargo lo podríamos editar para que sólo ciertas VMs sean agregadas, ejemplo podría ser que tengan cierto prefijo, sufijo, Host, Datacenter o Cluster. Un caso podría ser que las VMs de un cluster vayan a un Job y las de otro Cluster a un Job distinto. Mil variantes.

Espero les sea de utilidad.

spotify:track:5c5a2Ptu8eyIpljhQHjIqk

Configuración de políticas de seguridad de vSwitch con PowerCLI

Una de las 3 políticas que podemos configurar a un vSwitch/Port Group de un ESXi son las políticas de seguridad, éstas tienen 3 parámetros. MAC Address Changes, Forged Transmits y Promiscuous Mode. Cuando se crea un vSwitch/Port Group Standard en un host ESXi, éstos son los valores default:

Promiscuous Mode. Default: Reject.
MAC Address Changes. Default: Accept
Forged Transmits. Defaul: Accept

Por alguna razón, los valores por default de los vSwitches Standard en cuanto a MAC Address Changes y Forged Transmits está en “Accept”, siendo que el default en los switches distribuídos cambia, por default MAC Address Changes y Forged Transmits se encuentran en “Reject”.

No es la intención de este post explicar a detalle la función que desempeña cada parámetro. Chris Wahl tiene un par de posts excelentes donde explica MAC Address Changes y Forged Transmits. En cuanto a Promiscuous Mode, cuando se habilita, permite a las VMs que se encuentran en el PortGroup “escuchar” todo el tráfico que se está transmitiendo en dicho Portgroup, el caso típico es cuando se instala un sniffer como WireShark para monitorear el tráfico de red.

¿Cual es la mejor práctica? De acuerdo al “Hardening Guide” para vSphere 5.5, una buena práctica es dejar en “Reject” los tres parámetros de las políticas de seguridad. La intención de este post es ofrecer una opción para automatizar esta configuración empleando PowerCLI.

Un detalle importante, el documento de hardening se refieren en general al vSwitch, sin embargo, el script lo vamos a aplicar directamente a los Port Groups que llevan el tráfico de red de las máquinas virtuales, no vamos editar a los Port Groups de tipo “vmkernel” que le dan servicio de red al host ESXi.

Ok, ahí vamos…

Vamos a empezar desde abajo con un host, en este caso “esx-daftpunk.infra.lab” y un virtual switch “VM Network”. Con esta línea editamos las políticas de seguridad del PortGroup:

Get-VirtualPortGroup -VMHost esx-daftpunk* -Name "VM Network" | Get-SecurityPolicy | Set-SecurityPolicy -MacChanges $false -ForgedTransmits $false -AllowPromiscuous $false

Revisamos la configuración de la política de seguridad del PortGroup y observamos que nuestra línea de PowerCLI funcionó, fue fácil porque lo aplicamos a sólo un host y conocemos el nombre del PortGroup.

skitch

¿Pero como automatizar este proceso cuando tenemos en nuestro centro de datos distintos Port Groups en cada host que llevan el tráfico de red de las máquinas virtuales y muchos hosts ESXi?

Modificamos un poco el script y con un “one-liner” podemos modificar la configuración en todo nuestro Datacenter, aunque también podría hacerse por Cluster, Carpeta, hosts “taggeados” o haciendo una lista específica de hosts.

Get-VMHost $misESXi | Get-VirtualPortGroup | Where {$_.Port.Type -ne "host"} | Get-SecurityPolicy | Set-SecurityPolicy -MacChanges $false -ForgedTransmits $false -AllowPromiscuous $false

Ok, con esta linea deberíamos de tener la configuración de seguridad de todos nuestros Port Groups de acuerdo a lo que nos sugiere el “Hardening”.

Ahora, podemos correr este otro script para sacar un pequeño reporte y documentar lo que acabamos de hacer.

Por default, PowerCLI le llama “True” a lo que en la GUI vemos como “Accept”, y “False” a “Reject”. Así que le incluí una condición de PowerShell para que salga como aparece en la GUI.

$truePG = "True"
$reject = "Reject"
$accept = "Accept"
$hosts = Get-VMHost -Location HA-DRS
foreach ($miesx in $hosts){ 
Write-Host "-- Configuración PortGroup Security Policy VM Networking en host $miesx"
Get-VMHost $miesx | Get-VirtualPortGroup | Where {$_.Port.Type -ne "host"} | Get-SecurityPolicy | 
Format-Table @{Name="Port Group";E={$_.VirtualPortGroup};a="left"},
@{Name="Promiscuous Mode";Expression={ if ($_.AllowPromiscuous -eq $truePG) { $accept } else { $reject }};a="center"},
@{Name="Mac Address Changes";Expression={ if ($_.MacChanges -eq $truePG) { $accept } else { $reject }};a="center"},
@{Name="Forged Transmits";Expression={ if ($_.ForgedTransmits -eq $truePG) { $accept } else { $reject }};a="center"} -a
}

Ojalá les sea de utilidad.

gc

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