VCAP

Crear regla de SATP para identificar almacenamiento como SSD

Que tal gente, existen casos en los cuales un dispositivo de almacenamiento no sea detectado como de estado solido o SSD en ESXi 5, para estos casos tenemos la opción de crear reglas de SATP (Storage Array Type Plugin) con la opción de marcar dicho dispositivo como SSD en el momento que el stack de NMP lo reclama.

Una vez reclamado e identificado como SSD podemos habilitar Host Cache.

¿Como identifico un dispositivo de almacenamiento como SSD?

Primero identificamos nuestro dispositivo, para esto utilizamos esxcli:

esxcli storage nmp device list

En este caso estaré trabajando con un LUN presentado por un appliance virtual de Lefthand, que tiene el identificador “naa.6000eb31e698711c000000000000000c”

Podemos notar que dicho dispositivo es identificado como “non-ssd” desde el vSphere client:

En este caso tenemos que crear una nueva regla de SATP para que dicho dispositivo sea identificado como SSD, para esto estaremos utilizando esxcli nuevamente:

esxcli storage nmp satp rule add –satp VMW_SATP_DEFAULT_AA –device
naa.6000eb31e698711c000000000000000c –option=enable_ssd

Podemos notar que en el comando debemos especificar el SATP utilizado para dicho dispositivo, en este caso VMW_SATP_DEFAULT_AA, esta información la obtuvimos en el comando anterior, también podemos notar que se especifica el dispositivo que se verá afectado por esta nueva regla. Por último agregamos la opción para habilitar SSD.

Una vez hecho esto, solo es cuestión de verificar que nuestra regla haya sido creada con el siguiente comando, realizaremos un filtro de todas las reglas con un simple grep:

esxcli storage nmp satp rule list | grep enable_ssd

Reclamamos el dispositivo:

esxcli storage core claiming reclaim -d naa.6000eb31e698711c000000000000000c

Y podemos ver que ahora ya es detectado como SSD, es posible que se requiera un refresh del cliente para que el cambio se vea reflejado:

VCAP – Sección 7– seguridad para hosts ESX/ESXi

Que tal gente, después de algunas semanas difíciles, trabajo, problemas personales, etc. estoy de regreso para continuar con los temas del examen VCAP-DCA . En esta ocasión nos toca hablar sobre seguridad específicamente en el caso de nuestros hosts ESX/ESXi.

Identificar características de seguridad a nivel de switch virtual

Bueno aquí básicamente debemos conocer que políticas de seguridad tenemos disponibles:

  • Promiscuous mode- Con esta política definimos si el switch o portgroup que estemos modificando permitirá que las vms conectadas al mismo puedan capturar paquetes que no estén específicamente destinados para ellas, útil cuando necesitamos hacer sniffing de red.
  • MAC Address Changes – Con esta política definimos si permitirá la modificación de mac address desde el sistema operativo de dicha VM.
  • Forged Transmits – Con esta política definimos si se permite o no al sistema operativo de la vm crear paquetes con una mac address distinta a la suya.

Agregar/editar y remover usuarios/grupos en un host ESX

Tenemos 2 maneras de crear, remover y editar usuarios, desde la linea de comando o desde la interfaz gráfica:

  • vicfg-user – utilizando vSphere CLI / vMA podemos crear usuarios remotamente en nuestros hosts, aquí les dejo unos ejemplos:

vicfg-user –server esxi01.hispavirt.test.com –entity user –operation add –login soporte –password password

–entity user/group

–operation add/delete/list/modify

–login nombre de usuario


vicfg-user –server esxi01.hispavirt.test.com –entity user –operation delete –login soporte

Para agregar usuarios directamente desde la interfaz gráfica ingresamos con nuestro vSphere client y vamos al tab de “Local Users & Groups”, click derecho y “add”:

Si nosotros estamos utilizando ESX/ESXi 4.1 +, con nuestros servidores agregados a un dominio windows si quisiéramos agregar permisos a usuarios windows vamos a el tab de “permissions” y hacemos click derecho> Add Permission..

Personalizar la configuración de SSH para una mejor seguridad

Aquí básicamente es recordar que para utilizar ssh la mejor practica es siempre accesar con un usuario que no sea root y en el caso de requerir privilegios podemos realizar un SU.

Para habilitar el acceso de root en ESX:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=8375637

Habilitar o deshabilitar la verificación de certificados SSL

Existe un kb de VMware de como realizar esto, muy sencillo aquí les dejo el link:  KB Article: 4646606

Generar certificados de Hosts ESX/ESXi

En el momento de la instalación tanto ESX como ESXi generan sus propios certificados SSL, los cuales los podemos encontrar en  /etc/vmware/ssl, para regenerar estos certificados en el caso de haberlos borrado o haber cambiado el hostname seguimos los siguientes pasos:

  • ESXi: En la consola directa o DCUI, seleccionamos “reset system configuration”, con esto todos los parámetros modificados serán regresados a su estado default, reiniciamos el servidor y se crearan nuevos certificados ssl.

  • ESX: navegamos a la ruta donde se encuentran nuestros actuales certificados de ssl, y podemos ya sea borrar los certificados, o renombrarlos:

mv rui.crt orig.rui.crt

mv rui.key orig.rui.key

reiniciamos  el servicio de hostd:

service mgmt-vmware restart

y tendremos listos nuevos certificados.

Habilitar Lockdown mode para nuestros hosts ESXi

El modo “lockdown” previene que nos podamos loggear con el usuario root a través del vSphere client, PowerCLI, vMA, y demás.

Para habilitarlo tenemos la capacidad de realizarlo directamente en la consola o DCUI,  a través del vSphere client o vim-cmd:

  • DCUI:

  • vSphere client – seleccionamos nuestro host, hacemos click en configuration>security profile:

  • vim-cmd – vim-cmd -U dcui vimsvc/auth/lockdown_mode_enter

Remplazar certificados default por certificados de una autoridad de CA

Aquí les voy a dar un ejemplo de como crear certificados con OpenSSL y un CA de Windows 2003, vamos a seguir los siguientes pasos:

  • Paso 1-. navegamos a nuestra carpeta bin de OpenSSL
  • Paso 2-. creamos nuevos certificados

openssl req -new -nodes -out micert.csr -config openssl.cfg

En el paso donde les pregunta el “common name” aquí debemos ingresar el FQDN de nuestro vCenter o host ESX/ESXi para el cual sea este certificado.

En este punto ya tendremos creados 2 archivos en la carpeta bin de OpenSSL, micert.csr y privkey.pem.

  • Paso 3-. Abrimos un navegador y apuntamos a nuestro servidor CA, Https://myservidor/certsrv, seleccionamos “request a certificate” > “advanced certificate request” > “submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file”

Aquí  necesitamos abrir el archivo “micert.csr” que creamos anteriormente y se encuentra en la carpeta bin de OpenSSL, copiamos todo su contenido para después pegarlo en el campo de saved request:

Pegamos el contenido, y cambiamos el template a “web server” y hacemos click en “submit”

Una vez hecho esto, descargamos el certificado “base 64 encoded”

  • Paso 4-. Ya tenemos nuestro nuevo certificado, solo es cuestión de abrir nuevamente nuestra linea de comando, navegar a openssl\bin, y vamos a ejecutar el siguiente comando sobre nuestro nuevo certificado:

openssl x509 -in certnew.cer -out micert.cer

Con este ultimo paso ya tenemos listo nuestro certificado, en este caso creamos uno para el host vcenter.hispavirt.test.com, solo es cuestión de cambiar el “common name ” al host que se requiera. Para sustituir los certificados:

  • vCenter: navegamos a “C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL”, y copiamos los archivos “micert.cer” y “privkey.pem”, realizamos un backup de nuestros certificados actuales (rui.crt y rui.key). Paramos los servicios del vCenter, y renombramos los archivos recién copiados a:

micert.cer > rui.crt

privkey.pem > rui.key

  • ESXi – renombramos de igual manera los archivos micert.cer y privkey.pem, solo que esta vez vamos a utilizar vSphere Cli para copiar los archivos a nuestros hosts:

vifs –server <hostname> –username <username> –put rui.crt /host/ssl_cert
vifs –server <hostname> –username <username> –put rui.key /host/ssl_key


Configurar timeout de SSL

Tanto en ESX/ESXi, necesitamos editar el archivo llamado “config.xml” que encontramos en la ruta “/etc/vmware/hostd/” y modificamos el valor que requerimos, tenemos 2 tipos:

  • read timeout: es el valor en milisegundos para aquellas conexiones que ya completaron el handshake de SSL
  • handshake timeout: es el valor en milisegundos para aquellas conexiones que todavía no completan el handshake de SSL.

Para modificarlos, editamos el archivo “config.xml” e ingresamos las siguientes lineas:

  • read timeout – <readTimeoutMs>tiempoenms</readTimeoutMs>
  • handshake timeout – <handshakeTimeoutMs>tiempoenms</handshakeTimeoutMs>

Seguridad de Proxy web en hosts ESX/ESXi

Aquí vamos a necesitar modificar un archivo llamado proxy.xml que encontramos en la ruta /etc/vmware/hostd, en el cual podemos definir que puerto se estará utilizando, si se aceptan conexiones http, https, etc. les recomiendo leer la guia de configuración de esxi/esx para poder llevar a cabo esta tarea.

Politicas de passwords complejas

Les recomiendo leer los siguientes links para realizarlo:

En el caso de ESX, podemos utilizar esxcfg-auth , para definir días de validez de las passwords:

esxcfg-auth –maxpassdays=90 –minpassdays=30 –passwarnage=75

-maxpassdays – validez de hasta 90 días

-passwarnage – se nos mandará un warning de password a los 75 días

-minpassdays – la password deberá ser utilizada al menos 30 días

Identificar metodos para la seguridad a nivel de VM

Les recomiendo leer el draft del whitepaper “Security Hardening Guide” para vSphere 4.1:

http://communities.vmware.com/docs/DOC-14548

VCAP – Sección 6 – troubleshoot de vCenter y administración de hosts ESX/ESXi

Que tal gente, vamos a continuar con los temas para el examen VCAP-DCA, en este caso nos toca hablar un poco sobre troubleshooting de vCenter y de la administración de hosts, que herramientas y comandos podremos estar ocupando para este fin.

Identificar comandos y herramientas utilizadas para realizar troubleshooting de administración

Bueno aquí básicamente en el caso de tener problemas de conexión con nuestros hosts ESX/ESXi seria utilizar los comandos que nos permiten observar cual es la configuración actual de red:

  • esxcfg-vswitch
  • esxcfg-vswif (solo ESX)
  • esxcfg-nics

En este punto también es bueno saber que tenemos la opción para utilizar los dos métodos de colección de logs que tenemos a nuestro alcance:

  • vm-support –  este script recolecta logs de vpxa (agente de vCenter),configuración de este, y dumps del mismo, realiza lo mismo en el caso de hostd y de HA.
  • vc-support – con esta utilidad que encontramos en el servidor de vCenter, podemos recolectar archivos de configuración del vpxd, logs, etc.

Troubleshoot del servicio de vCenter y la conexión a la base de datos del mismo

Aquí les recomiendo leer los siguientes kb de VMware:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003928

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003926

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003960

Y también una fuente excelente para poder comenzar con nuestro troubleshooting son los logs que pertencen al vCenter, los cuales encontramos en:

  • C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs

Esta ruta la podemos modificar ingresando las siguientes líneas en el archivo vpxd.cfg:

<log>
<directory>c:\ruta</directory>
</log>

Troubleshooting del firewall en el Service Console (ESX)

Bueno para poder consultar y modificar la configuración del firewall que se tiene en el Service Console lo realizamos con el comando esxcfg-firewall, estas son las opciones que acepta:

  • -q –query – nos muestra la configuración del firewall
  • -q –query (nombreservicio) – nos muestra si el estatus de dicho servicio.
  • -q –query incoming|outgoing – nos muestra si los puertos ya sean de entrada o salida estan bloqueados, por default vienen bloqueados excluyendo aquellos que ya tienen una regla para permitir su uso.
  • -s –services – nos muestra aquellos servicios conocidos que están permitidos.
  • -l –load – carga la configuración actual de firewall
  • -r –resetDefaults – regresa la configuración de firewall a sus valores default.
  • –blockIncoming – bloquea todos los puertos de entrada, a menos que tengamos un servicio o regla permitido.
  • –blockOutgoing – bloquea todos los puertos de salida, a menos que tengamos un servicio o regla permitido.
  • –allowIncoming – permite conexiones en todos los puertos de entrada.
  • –allowOutgoing – permite conexiones en todos los puertos de salida.
  • –e –enableService (nombreservicio) – habilita un servicio en especifico, abriendo así los puertos que se necesitan para el funcionamiento del mismo.
  • –d –disableService (nombreservicio) – deshabilita un servicio en especifico, cerrando así los puertos que se necesitan para el funcionamiento del mismo.
  • -o –openPort -AR -port,tcp|udp,in|out,name – con esta opción podemos abrir un puerto, ej. esxcfg-firewall -o 500,tcp,out,servicio
  • -c –closePort – con esta opción cerramos un puerto, ej. esxcfg-firewall -c 500,tcp,out,servicio

Troubleshoot management de hosts ESX/ESXi y problemas de conexión

Bueno aquí mas que nada les recomiendo leer mi post de troubleshooting de red VCAP – Sección 6 – Troubleshooting de Red y también VCAP – Sección 6 – Configurar,administrar y analizar logs de vSphere.

VCAP – Sección 6 – Troubleshooting de almacenamiento

Que tal gente vamos a continuar con los temas para el examen VCAP-DCA, en este caso nos toca hablar de como realizar troubleshooting a nivel del almacenamiento, poder identificar donde esta el problema y conocer los comandos que nos pueden apoyar con estas tareas.

Comandos de vicfg-* utilizados para temas de almacenamiento

  • vicfg-iscsi.pl – con este script de perl tenemos la capacidad para manejar el adaptador de sw iscsi y adaptadores físicos de iscsi.

  • vicfg-volume – con este script podemos manejar aquellas LUNs (volúmenes) detectadas como replicas, montarlas,etc.
  • vicfg-mpath – con este script podemos obtener información de los paths existentes para almacenamiento ISCSI y FC.

  • vicfg-mpath35.pl – esta pensado para la administración de paths para hosts vi 3.5
  • vicfg-nas.pl – con este script podemos manejar los exports de nas, montar,desmontar,etc.

  • vicfg-rescan.pl – con este script podemos realizar rescans a nivel de adaptador.
  • vicfg-scsidevs.pl – con este script podemos obtener información de LUNs, como identificadores (naa,vml,t11).

  • vicfg-module.pl – con este script podemos manejar módulos del kernel de VMware, un ejemplo claro para el uso de este es el aumentar el queue depth de un adaptador:

vicfg-module -s ql2xmaxqdepth=64 <module_name>

C0nocer los máximos de almacenamiento

Aquí les dejo el link a la guía de máximos de vSphere 4.1 http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

Identificar logs utilizados para troubleshooting de almacenamiento

Aquí básicamente estaremos observando el log de /var/log/vmkernel , aquí podremos ver reservaciones scsi, snapshots luns, etc.

Describir VMFS

La verdad no voy a describir VMFS ya que me tomaría un tiempo demasiado largo, les recomiendo leer este articulo http://blog.laspina.ca/ubiquitous/understanding-vmfs-volumes.

Utilizar comandos de vicfg-* y esxcli para realizar troubleshooting de mutlipath y la arquitectura de PSA

En este caso estaríamos obteniendo información de los paths utilizando vicfg-mpath, les recomiendo leer la guia de “vSphere Command-Line Interface
Installation and Reference Guide”
a partir de la pagina 83, donde podrán encontrar todos los usos de esxcli.

Vamos a ver algunos ejemplos:

Para cambiar el tipo de PSP (Path selection plugin):

esxcli nmp device setpolicy –device (naa.XXXX) –psp vmw_psp_XX

vmw_psp_RR – Round Robin

vmw_psp_fixed – Fixed

vmw_psp_mru – MRU

vmw_psp_fixed_AP – Fixed para almacenamientos Activos/pasivos con ALUA

Para enmascarar un LUN o algún path en especifico hacia un LUN:

Obtenemos la información de los paths utilizando esxcfg-mpath -l

Agregamos la regla con el plugin”Mask_path”:

esxcli corestorage claimrule add -r 121 –plugin mask_path –type location –adapter vmhba33 -C 3 -T 0 -L 0

-r numero de regla

–type tipo de regla

–adapter hba a través de la cual se ve dicho lun

Para que la nueva regla se vea reflejada:

esxcli corestorage claimrule load

En el caso que tengamos una regla para enmascarar un LUN o path en especifico y quisiéramos volver a tener acceso a dicho LUN/path debemos seguir estos pasos:

Liberamos el path en especifico o LUN:

esxcli corestorage claiming unclaim –type location –adapter vmhba33 -C 3 -T 0 -L 0

o Liberamos todo  de dicho adaptador:

esxcli corestorage claiming unclaim –adapter vmhba33

Una vez liberado, borramos la regla que enmascara dicho path/LUN , para esto enlistamos las reglas que tenemos:

esxcli corestorage claimrule list

Borramos dicha regla:

esxcli corestorage claimrule delete -r #numeroderegla

Y realizamos un reload de las reglas:

esxcli corestorage claimrule load

y podemos realizar un rescan

esxcfg-rescan -A

Obtener el path preferido para un dispositivo con PSP Fixed:

esxcli  nmp fixed getpreferred –device naa.xxx

Para cambiar el path preferido para un dispositivo con PSP fixed:

esxcli nmp fixed setpreferred –device naa.xxx vmhba33:C3:T0:L0

Utilizar vicfg-module para realizar troubleshooting de problemas con módulos de almacenamiento

Bueno aquí no tengo mucho que compartir con ustedes, aquí podríamos deshabilitar un modulo que este teniendo problemas con:

vicfg o esxcfg-module -d nombremodulo

Para poder ver los módulos que tenemos cargados

vicfg o esxcfg-module -l

Para configurar un parámetro en especifico de algún módulo:

vicfg o esxcfg-module -s  opcionavanzada nombredemodulo

Utilizar vicfg-* y esxcli para realizar troubleshoot de ISCSI

Aquí estaremos utilizando el comando esxcli swiscsi y vicfg-iscsi, vamos a ver algunos ejemplos:

vicfg-iscsi:

agregar un target iscsi dinámico:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –add -D -i 192.168.3.250:3260 vmhba33

agregar un target iscsi estático:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –add -S -i 192.168.3.250:3260 vmhba33

enlistar targets activos:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com -T –list vmhba33

enlistar propiedades de LUNs para un adaptador en especifico:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –list –lun vmhba33

Configurar autentificación (CHAP) uni-direccional:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –authentication –level chapRequired –method CHAP –auth_username administrator –auth_password –ip 192.168.3.250 vmhba33

enlistar adaptadores de iscsi:

vicfg-iscsi.pl –server esxi01.hispavirt.test.com –device –list

esxcli:

Agregar un segundo puerto de vmkernel para sw iscsi:

esxcli swiscsi nic add -n vmk1 -d vmhba33

Quitar un puerto de vmkernel para sw iscsi:

esxcli swiscsi nic remove -n vmk1 -d vmhba33

Enlistar sesiones de sw iscsi:

esxcli swiscsi session list –d vmhba33

Remover sesión de sw iscsi:

esxcli swiscsi session remove -d vmhba33

Troubleshooting de NFS

Les recomiendo leer este kb de VMware: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1003967&sliceId=1&docTypeID=DT_KB_1_1&dialogID=97106231&stateId=1%200%2097104743

Utilizar esxtop y vscsiStats para troubleshooting de almacenamiento

En el caso de esxtop tenemos que echarle un ojo a los siguientes:

DAVG – (device avg) – latencia a nivel del adaptador (hba), latencia entre la hba y el almacenamiento. Si este valor es alto (davg ≥ 25) debemos verificar nuestro almacenamiento (cantidad de discos, problemas) e infraestructura para llegar a el (switches , hba’s ,etc).

KAVG – (kernel avg) – latencia a nivel del vmkernel, generalmente este valor debe de ser menor al valor de DAVG o “0″, en el caso que sea mayor es posible que tengamos encoladas peticiones a disco (QUED).

GAVG (guest avg) – la suma de KAVG y DAVG nos da como resultado la latencia percibida por el guest o vm (GAVG),valores mayores a 25 nos indican problemas.

QUED – cantidad de comandos encolados a nivel del vmkernel, esto quiere decir que dichos comandos están esperando una oportunidad de entrar en el queue del almacenamiento. En el caso que se tenga un valor distinto a “0″ nos indica problemas con nuestro almacenamiento (queue depth).

ABRTS/s – cantidad de comandos abortados, esto sucede en el momento que después de cierta cantidad de tiempo (dependiendo el os), el almacenamiento  no ha sido capaz de responder a las peticiones de dicha vm, por lo cual el sistema operativo realiza dicho abort.

RESETS/s – reseteo del bus de scsi.

CONS/s – reservaciones scsi por segundo, en el caso de tener una cantidad alta de reservaciones (20+) se nos indica problemas con nuestro almacenamiento, las reservaciones scsi solo aplican para datastores VMFS. Estas ocurren en el momento ciertas operaciones requiere hacer un lock del metadata, por ej: encendido de vm, nueva vm, snapshot, vmotion de una vm, etc. Por estas se presentan comúnmente en el caso de tener una cantidad alta de VMs por cada datastore.

y para vscsiStats les recomiendo leer mi articulo Paso – a – paso – vscsiStats.

Configurar y realizar troubleshooting de VMFS con vmkfstools

vmkfstools es una herramienta para el manejo de VMFS y de VMDKs, vamos a conocer algunos ejemplos:

Para el manejo de VMFS:

Crear un VMFS con block size de 8mb con el nombre “iscsi-01” en el path vmhba33:3:0:0

vmkfstools -C vmfs3 -b 8m -S iscsi-01 vmhba33:3:0:0

Extender un VMFS entre distintas particiones

vmkfstools -Z vmhba33:3:0:1 vmhba33:3:0:0

Crear un vmdk de 2 GB en nuestro VMFS recién creado:

vmkfstools -c 2048m /vmfs/volumes/iscsi-01/win2k3.vmdk

Crear un vmdk de 2 GB pero eagerzeroed:

vmkfstools -c 2048m /vmfs/volumes/iscsi-01/win2k3.vmdk -d eagerzeroedthick

Crear un vmdk de 2 GB pero thin:

vmkfstools -c 2048m /vmfs/volumes/iscsi-01/win2k3.vmdk -d thin

Para crear un rdm passthrough (modo físico):

vmkfstools -z /vmfs/devices/disks/naa.60a980006e424f4f6c4a595261485168 /vmfs/iscsi-01/win2k3_RDM.vmdk

Para crear rdm modo virtual:

vmkfstools -r /vmfs/devices/disks/naa.60a980006e424f4f6c4a595261485168 /vmfs/iscsi-01/win2k3_RDM.vmdk

Para clonar un vmdk:

vmkfstools -i /vmfs/volumes/iscsi-01/01.vmdk /vmfs/volumes/iscsi-01/02.vmdk

Para romper el lock de un VMFS:

vmkfstools -B  /vmfs/devices/disks/vmhbaX:Y:Z:0

Para realizar un reset del bus a nivel del LUN (liberar reservaciones SCSI):

vmkfstools –lock lunreset /vmfs/devices/disks

Troubleshooting de snaphots y problemas de resignature de VMFS

Aquí en el caso de tener problemas con un snapshot que no se elimina desde el gui, podemos ir directamente al service console /DCUI y seguir estos pasos:

Dentro de la línea de comando ejecutamos el siguiente comando para enlistar las VMs que tenemos y poder conocer su ID:

vim-cmd vmsvc/getallvms

Una vez obtenido el ID borramos los snaps de dicha vm:

vim-cmd vmsvc/snapshot.remove VMID

o también podemos quitar los snaps con vmware-cmd (Solo ESX)

vmware-cmd vmfs/volume/vmfslabel/VMName/VMName.vmx removesnapshots

Para realizar resignature de VMFS les recomiendo leer mi post “VCAP – Sección 1 – Entendiendo y aplicando resignature a volumenes VMFS”

 

VCAP – Sección 6 – Troubleshooting de red

Que tal gente, vamos a continuar con los temas de preparación para el examen de certificación VCAP-DCA, en este caso nos toca hablar de como realizar troubleshooting a nivel de red en vSphere.

Identificar configuraciones de vSwitches en un .vmx

Para empezar recordemos que los archivos .vmx son aquellos en donde reside la configuración de nuestra VM, por lo cual todas las opciones de hardware y modificaciones que realicemos se verán reflejadas en este archivo, vamos a ver un ejemplo:

ethernet0.present = “TRUE”
ethernet0.virtualDev = “vmxnet3”
ethernet0.dvs.switchId = “36 85 17 50 c7 4e 07 a1-65 b0 9c ca 55 88 a9 0b”
ethernet0.dvs.portId = “105”
ethernet0.dvs.portgroupId = “dvportgroup-42”
ethernet0.dvs.connectionId = “692809732”
ethernet0.addressType = “vpx”
ethernet0.generatedAddress = “00:50:56:97:00:00”
ethernet1.present = “TRUE”
ethernet1.virtualDev = “vmxnet3”
ethernet1.dvs.switchId = “”
ethernet1.dvs.portId = “”
ethernet1.dvs.portgroupId = “”
ethernet1.dvs.connectionId = “0”
ethernet1.addressType = “vpx”
ethernet1.generatedAddress = “00:50:56:97:00:01”
ethernet1.networkName = “Produccion alterna”

  • virtualDev = “vmxnet3”  – Aquí se nos hace referencia al tipo de vNic que se tiene.
  • dvs.switchId = “36 85 17 50 c7 4e 07 a1-65 b0 9c ca 55 88 a9 0b” – el identificador del switch distribuido al que esta conectado, este id lo podemos verificar de una manera simple utilizando el comando net-dvs:

También tenemos la opción de verificar este ID en la carpeta .dvsData (net-dvs |grep com.vmware.common.port.volatile.persist):

 

  • dvs.portgroupId = “dvportgroup-42″ – este es el identificador del portgroup en la base de datos del vCenter, podemos confirmarlo de igual manera con el comando net-dvs

(select * from vpx_dvportgroup)

  • addressType = “vpx” – esta línea nos indica que el mac address del ethernet 0 (en este caso) esta a cargo de un vCenter, es decir, este se encargara del manejo de las mismas para que no haya problema con mac addresses repetidas.
  • generatedAddress = “00:50:56:97:00:00″ –  mac address generada para el adaptador.
  • networkName = “Produccion alterna” – vm portgroup (vSS) al cual esta conectado dicho adaptador.

Identificar entradas de vSwitches en el archivo de configuración del host ESX/ESXi

Aquí con archivo de configuración vamos a entender el archivo esx.conf , que encontramos en /etc/vmware. Vamos a ver un pequeño fragmento del mismo donde podemos ver las entradas de nuestro vSwitch:

/net/vswitch/child[0000]/name = “vSwitch0”
/net/vswitch/child[0000]/numPorts = “128”
/net/vswitch/child[0000]/portgroup/child[0000]/name = “Management Network”
/net/vswitch/child[0000]/portgroup/child[0000]/shapingPolicy/enabled = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/hasUplinkOrder = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/beacon = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/fullDuplex = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/minSpeed = “10”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/linkCriteria/pctError = “ignore”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/maxActive = “1”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/notifySwitch = “true”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/reversePolicy = “true”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/rollingRestoration = “false”
/net/vswitch/child[0000]/portgroup/child[0000]/teamPolicy/team = “lb_srcid”

Aquí podemos ver que tenemos el nombre de un vSwitch, el vSwitch0,  y podemos ver todas sus configuraciones como load balancing (lb_srcid , port ID) , beacon probing, etc. Todas las configuraciones de switches standard las encontraremos en este archivo empezando con “/net/vswitch/”.

Identificar comandos y herramientas que podemos utilizar para el troubleshooting de red en vSphere

  • esxcfg-vswitch
  • esxcfg-vswif
  • esxcfg-vmknic
  • esxcfg-vmknic
  • net-dvs

Les sugiero darle un vistazo a esta página http://vmware-land.com/esxcfg-help.html , para poder conocer el uso de estos comandos (con excepción de net-dvs)

identificar logs a utilizar en el troubleshooting de red

Aquí no existen los en especifico que nos brinden información de red, pero por experiencia propia les podría decir que cualquier problema que se tenga en cuanto a desconexiones en las vmnics lo pueden encontrar en /var/log/messages.

utilzar net-dvs para troubleshooting de vDS

El problema con este comando es que no existe documentación oficial por parte de VMware para el uso del mismo, además de ser “unsupported”. Aquí como vimos anteriormente podemos obtener información del mismo. La manera más facil seria ejecutando el comando y mandando el resultado del mismo a un archivo de texto que podamos observar con mas calma:

net-dvs >infodvs.txt

Aquí podemos ver todas las opciones que tenemos para el uso del mismo:

~ # net-dvs –help
net-dvs: unrecognized option `–help’
Warning: This is an unsupported command. Use at your own risk.
net-dvs -a [ -P maxPorts] switch_name
net-dvs -d switch_name
net-dvs [ -A | -D ] -p port switch_name
net-dvs [ -s name=value | -u name ] -p port switch_name
net-dvs -l [ switch_name ]
net-dvs -i (init database)
net-dvs [-S | -R | -G ]
net-dvs -T
net-dvs -v “vlanID[;t|p[0-7][;min-max,min-max…]]
net-dvs -V “primaryVID,secondaryVID,i|c|p;primaryVID,secondaryVID,i|c|p…”
net-dvs -m “sid;dname;snaplen;[oiveld];encapvlan;wildcardsIn,wildcardsOut;dstPort1,dstPort2,…;srcInPort1,srcInport2,…;srcOutPort1,srcOutPort2,…;:sid2;dname2…”
net-dvs dvswitch -k “respool1_id;respool2_id;…”
net-dvs dvswitch -p dvport -K “respool1_id:shares:limit;respool2_id:shares:limit;…”
net-dvs dvswitch -p dvport -z “respool_id”
net-dvs dvswitch -j [activate|deactivate]
net-dvs -L uplink_name1[,uplink_name2,…] -t team_policy_type -p port switch_name
net-dvs dvswitch -H “red|yellow|green:some message” switch_name
net-dvs -o “depth,param|classname;depth,param|classname;… -p port|globalPropList switch_name
net-dvs –mtu mtu_value [-p dvport] switch_name
net-dvs –x 0|1 -p dvport switch_name
net-dvs –vlan vlanID -p dvport switch_name
net-dvs –reset -p dvport switch_name
net-dvs –cap cap_value -p dvport switch_name
net-dvs –states -p dvport switch_name
net-dvs –miscInfo  ;# Dumps cpu/meminfo
net-dvs –vmknicIp <vmknic> ;# Displays IPv4 address on <vmknic>

Utilizar comandos de vicfg-* (vSphere CLI) para realizar troubleshooting de configuraciones de red

Aquí vamos a encontrar muchos equivalentes de los comandos esxcfg-* les sugiero echar un vistazo a este link http://www.vmware.com/support/developer/vcli/vcli41/doc/reference/index.html para que puedan encontrar que comandos pueden utilizar y como utilizarlos.

Configurar un analizador de paquetes en un ambiente vSphere

Aquí básicamente estarán instalando el analizador de paquetes que ustedes utilicen, generalmente nos vamos por wireshark. Un punto importante que debemos de tener en cuenta al configurar la VM donde estará siendo ejecutando este sniffer es que la vNic o interfaz de red de dicha vm que estará capturando paquetes debe de ser conectada a un portgroup que permita “promiscuous mode”

Y para poder capturar paquetes de todas las VLANs configuradas en dicho vSwitch podemos configurar para dicho portgroup la vlan 4095, esto solo aplica para VST.

Troubleshooting de Private VLANs

Aquí mas que nada sería cuestión de entender el concepto de PVLAN, les dejo un link a un articulo propio explicándoselos VCAP – Sección 2 – Configurar y administrar VLANs y PVLANs

Existen algunos puntos importantes en cuanto a la configuración de red física:

  • lógicamente los puertos conectados a nuestro servidor ESX/ESXi deben de ser trunk
  • Nuestros Switches deben de ser PVLAN aware.
  • En el caso del uso de PVLANs VTP (VLAN trunking protocol) deberá estar en modo transparente, debido a que las PVLANs son definidas localmente.

Troubleshooting de red en Service Console e interfaces de vmkernel

Les recomiendo echarle un vistazo a este KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007986. Estaremos utilizando el comando esxcfg-vswif para el manejo de las configuraciones de Service Console.

En el caso de tener ESXi el termino de Service Console nos es irrelevante, por lo cual estaremos realizando troubleshooting de una interfaz de vmkernel y estaremos utilizando el comando esxcfg-vmknic.

También necesitaremos del comando esxcfg-vswitch para poder agregar uplinks,vlans,etc.

 

Troubleshooting de DNS y ruteo

Para modificar nuestros DNS lo podemos realizar desde el vSphere client en “Configuration>DNS and Routing” , al igual que nuestro Default gateway.

Esto también puede ser modificado directamente en los archivos

/etc/sysconfig/network – para poder modificar el default gateway del service console

/etc/resolv.conf – para poder modificar nuestros DNS

Para modificar el gateway del vmkernel, lo tenemos que realizar directamente con el comando esxcfg-route

 

Utilizar ESXTOP / RESXTOP para troubleshooting de red

Aquí les recomendaría leer mis artículos VCAP- sección 3 – utilizar herramientas avanzadas para el monitoreo de performance y VCAP – Sección 3 – realizar medición y calculo de recursos en un ambiente vSphere para que se den una mejor idea de como funciona esxtop.

Aquí solo sería cuestión de poner atención a paquetes caídos:

%DRPTX – “dropped transmit packets” porcentaje de paquetes transmitidos que se han caido, esto representa problemas con la red fisica, alto consumo de la misma, problemas de hardware , etc. si el valor es distinto a “0″ , es algo que tenemos que verificar.

%DRPRX – “dropped received packets” porcentaje de paquetes recibidos que se han caido, aquí puede ser por cuestiones de recursos en el lado de la VM (no hay suficiente capacidad de procesamiento , aumentar recursos) o porque se esta teniendo un buffer overflow a nivel de rx rings.

 

Utilizar CDP y network hints para identificar problemas de conectividad

Podemos obtener información de CDP (Cisco Discovery Protocol) directamente desde nuestro vSphere client en la sección de “Configuration>Networking”, seleccionamos una vmnic conectada a un vSwitch donde tendremos el siguiente simbolo:

Y haciendo click sobre el mismo podremos ver información de CDP (si es que está disponible):

 

También tenemos la opción de obtener esta información desde la línea de comando, utilzando vim-cmd:

vim-cmd hostsvc/net/query_networkhint

 

 

 

VCAP – Sección 6 – Troubleshooting de Memoria y CPU

Que tal Gente, vamos a continuar con los temas de estudio para la certificación VCAP-DCA, en este caso nos toca hablar sobre troubleshooting de Memoria y CPU en vSphere.

Identificar métricas relacionadas con memoria y CPU dentro de esxtop / resxtop

Memoria:

SWR/s – en caso de tener este medidor distinto a “0″  nuestro host esta leyendo de swap (.vswp).

SWW/s – en caso de tener este medidor distinto a “0″ nuestro host esta escribiendo a swap (.vswp).

MCTLSZ – en el caso que el valor de este medidor sea distinto a “0″ nuestro host esta reclamando memoria de las VMs utilizando el balloon driver.

ZIP/s – en el caso que el valor de este medidor sea distinto a “0″ nuestro host esta comprimiendo memoria.

CPU:

%RDY – porcentaje del tiempo de ejecución de un world (proceso de vm) en el cual se encuentra listo para ser enviado a un procesador físico para su ejecución pero este ultimo no esta disponible, por lo cual esta en una fila o “queue” de procesador, si el valor de %RDY es mayor  a “10″ tenemos problemas, generalmente debido a la cantidad de vCPUs que hemos entregado en el host.

%MLMTD – porcentaje del tiempo de ejecución de una vm en el cual no ha sido procesada debido a los limites de cpu configurados para la misma. En el caso que este sea distinto a “0″ debemos modificar el limite de dicha vm si es que tenemos problemas con ella.

%SWPWT – este indicador solo lo veremos activo cuando nuestro host este realizando swap de memoria , por este indicador nos muestra la cantidad de tiempo que la vm esta esperando al vmkernel para leer paginas del swap.

%CSTP – porcentaje del tiempo de ejecución de un world en cual el vmkernel lo pone en modo “co-deschedule”, para ser mas claros , en el caso que una vm tenga smp (symmetric multiprocessing) y el OS o la aplicación ejecutada dentro de dicho os no es capaz de llevar un manejo inteligente de los distintos cpus generando así mas carga en un vCPU que otro, generando así un des balance. Este valor nos ayuda para determinar que una aplicación u OS en especifico no manejan de manera correcta multiples cpus, también nos puede indicar afinidad de un vcpu.

%SYS – porcentaje de tiempo en el cual servicios o worlds del sistema se ha dedicado a dicha vm, generalmente en el caso de tener un valor mayor a “20″ nos indica que dicha vm tiene una alta cantidad de i/o.

 

Identificar métricas de performance relacionadas con memoria y CPU dentro del vCenter

Dentro de nuestro vCenter tenemos la pestaña de “performance” donde se nos presentan dos vistas, Overview y Advanced. Dentro de “advanced” tenemos la capacidad de ver la información de metricas de una manera mas puntual, inluso tenemos opción de modificar que datos se nos presentan en estas graficas haciendo click en “chart options”:

 

¿Que datos debemos siempre tener bajo control?

Memoria:

  • Balloon, recordemos que se requiere de las vmtools instaladas para poder reclamar memoria de una vm, por lo cual siempre debemos de tenerlas instaladas.
  • TPS (transparent page sharing) (shared), recordemos que TPS solo actúa con paginas de 4k, por lo cual si estamos utilzando Large Pages veremos muy poca memoria compartida, solo hasta que exista un nivel alto de overcommitment estaremos viendo un mayor número de paginas compartidas.
  • Uso de Swap (swap used, swap in rate y swap out rate), en casos de overcommitment alto.
  • Consumida
  • Compressed, esto nuevamente en casos de overcommitment alto. (4.1)

CPU:

  • Usage , con esta métrica podemos saber como están los consumos en cuanto a CPU se refiere de nuestras VMs o host que seleccionemos.
  • Swap wait , tiempo que se espera para lectura de swap.
  • Ready, tiempo en el cual la vm estaba lista para ejecutar operaciones en CPU pero por cuestiones de contención der recursos no se puede procesar.

 

Les recomiendo leer mi post VCAP-Sección 3 – optimizando recursos de VMs para entender mejor todos estos términos.

 

Utilizar Hot-Add para resolver problemas identificados tanto de CPU como Memoria

En el caso que tengamos identificado un problema en cuanto a CPU y/o memoria se refiere podemos incrementar la cantidad de recursos que una VM tiene asignados en “caliente” es decir, agregarle vCPUs (Hot Plug) con la VM ejecutándose y/o memoria RAM (Hot Add), si han seguido mis posts sabrán que se tienen limitaciones y requerimientos para poderlo habilitar, en el post VCAP-Sección 3 – optimizando recursos de VMs podrán encontrar cuales son y como habilitar Hot add/Hot Plug.