VCAP-DTD Aprobado

Que tal gente, solo para comentarles que el día de hoy aprobé el examen VDTD510 para la certificación VMware Certified Advanced Professional – Desktop Design, sin duda es el examen MAS complicado que he tomado de VMware, este examen puso a prueba mis conocimientos y que tan bien había revisado la documentación, yo conté alrededor de 6 ejercicios de diseño tipo visio, con casos difíciles donde te piden que te enfoques a un tema en especifico, ej. storage, acceso, etc. al igual que los examenes de diseño de Datacenter Design o Cloud Infrastructure Design son 100% teóricos, no tenemos ejercicios aparte de aquellos tipo visio.

Siempre me tienden a preguntar ¿Como me preparo para tomar el examen?, en este caso les voy a pasar un tip… si ustedes descargan el blueprint, pueden notar que como parte de los puntos a estudiar se incluyen temas de ThinApp, ¡Estídienlos! conozcan los procesos para el capturado de aplicaciones a través de ThinApp (todos los procesos como aprobación de distintos grupos interno), el como integrarlos, temas de diseño de los repositorios, etc.

Mi kit de estudio consistió en lo siguiente:

  • VMware View: Design Best Practices (5.1)
  • View 5.1 architecture planning
  • Application Virtualization with VMware ThinApp

De igual manera les recomendaría tomarse el tiempo de leer todos los documentos que se referencian en el blueprint (todos estos ya los había leído con anterioridad por lo que no tomé tiempo para revisarlos de nuevo), el componente fundamental para su auto estudio la guía de planeación de arquitectura de View 5.1, deben conocerla de abajo hacia arriba.

Asegúrense poder llevar a cabo sin ningún problema la metodología de diseño de VMware View, es decir, que les den un caso y puedan hacer match con los puntos:

  • Definición de caso de uso
  • Diseño de pooles y escritorios
  • Diseño de protocolo
  • Diseño de Pods y bloques
  • Diseño de vSphere
  • Diseño de Storage
  • Diseño de sesión y método de acceso de usuario

Es decir, al entregarles un caso puedan identificar que información es relevante para cada uno de estos pasos de la metodología, siguiéndola todo es mucho mas sencillo.

Advertisements

VCAP5-CIA Beta aprobado

Que tal gente, el día de ayer recibí mi reporte del examen beta VCIA510 (VCAP5-CIA) y sorprendentemente aprobé, digo sorprendentemente debido a que tuve múltiples problemas en el transcurso del examen, comencé una hora después el examen debido a que las credenciales para firmarme al ambiente no eran correctas y tuve que salir 1 hora antes del examen debido a una emergencia que surgió. El examen consistía en 29 preguntas de las cuales yo contesté al rededor de 21 debido a la emergencia que me surgió, esta basado en las versiones 5.1 de vSphere y vCD e incluía temas de Chargeback y vShield (vCNS).

Al igual que el examen VCAP-DCA este es 100% practico, cada pregunta nos pide resolver ciertas tareas aplicadas directamente en un ambiente funcional, este examen busca que podamos aplicar nuestro conocimiento. Para estudiar solo seguí el blueprint 1 día antes en mi lab (el cual esta basado en vCD 5.1 y vSphere 5.1) y la verdad creo que con esto estuve mas que preparado.

Me gustó el examen al igual que el VCAP-DCA, es divertido y nos pone a prueba.

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.

 

 

 

VCAP – Sección 5 – instalar y administrar ambientes complejos de VUM

Que tal gente, vamos a continuar con los temas para la certificación VCAP-DCA , en este caso nos toca hablar un poco sobre VMware Update Manager.

Identificar requerimientos de firewall para VUM

VUM utiliza por default los siguientes puertos (a menos que sean cambiados en el momento de instalación):

  • 80 (http)
  • 443 (https)
  • 9084 (Web Server)
  • 8084 (Conexiones SOAP)

Aquí la comunicación entre vCenter y VUM va  a depender si este esta instalado en el mismo host que el vCenter, tenemos los siguientes casos:

  • vCenter y VUM residiendo en el mismo host – en este caso los hosts ESX(i) se comunican con el servicio de VUM a través del puerto 80, este puerto es un reverse proxy ofrecido por el vCenter, por lo cual las peticiones son redirigidas al puerto 9084. En el caso de comunicación entre el vCenter y VUM esta se realiza a través del puerto 9084 (SOAP) y no requiere ningún proxy ya que residen en el mismo host.

  • vCenter y VUM en distintos hosts – En este escenario nuestro vCenter y VUM residen en servidores independientes el uno del otro pueden ser físicos o virtuales, la comunicación entre vCenter y VUM se realiza a través del puerto 443 al realizarse las peticiones del lado de VUM son redirigidas al puerto 8084.  La comunicación entre ESX(i) y VUM se lleva a cabo en el puerto 80, una vez que estas peticiones llegan al host de VUM son redirigidas al puerto 9084. En el momento que se requiere enviar una actualización para algún host ESX(i) esta es enviada a través del puerto 902.

Es importante tener en mente que para poder obtener las actualizaciones requeridas de http://www.vmware.com y http://www.shavlik.com se requiere que el servidor donde resida VUM tenga los puertos 80 y 443 abiertos y con salida a internet.

Configurar un repositorio compartido

Para configurar un share donde se estarán alojando todos los parches y actualizaciones que se requieren para la infraestructura vamos a Configuration > Patch Download Settings.

Puntos importantes que tenemos tener en cuenta para el share:

  • El share debe de ser ya sea una ruta local, http o https. No podemos utilizar shares de red ej. \\NAS\vum
  • Necesitamos tener en cuenta que entre el servidor de VUM y el servicio de UMDS (Uptdate Manager Download Service) debe existir compatibilidad en sus versiones, es decir, en el caso que nosotros tengamos un servidor VUM que no tiene acceso a internet e instalamos el servicio de UMDS en otra máquina que cuenta con acceso a internet para descargar las actualizaciones estos dos deberán ser compatibles, aquí les dejo la tabla actual de compatibilidades:

Configurar Smart Rebooting

Smart Rebooting lo que nos permite es el reiniciar las VMs que pertenezcan a un vApp siguiendo su orden de inicio, para poder así mantener las dependencias que existan entre ellas. En este caso estamos hablando de actualizaciones a nivel de VM. Smart Rebooting viene habilitado por default en el caso que quisiéramos verificar si esta habilitado o deshabilitarlo, debemos de ir a Configuration>vApp Settings

Descargar manualmente actualizaciones a un repositorio

Tenemos la capacidad de importar actualizaciones que hayan sido descargadas directamente de VMware, como ejemplo, en el caso de una actualización “mayor” como la transición entre 4.0 y 4.1 se nos ofrece la opción de descargar un zip directamente, este zip contiene el bundle de actualización. Para importar estas actualizaciones a VUM debemos de ir a Configuration>Patch Download Settings  y hacemos click en “import patches”:

Realizar actualizaciones orquestadas a hosts y VMs

Aquí mas que nada es saber que podemos realizar las actualizaciones a nivel de datacenter, cluster, folders, etc, es decir en cada objeto del inventorio. Por lo cual podemos realizar actualizaciones de varios hosts o vms seleccionando el nivel correcto del inventorio y aplicando el baseline que necesitemos.

Crear y modificar grupos de baselines

Recordemos que un baseline es un conjunto de parches y actualizaciones, en este caso podemos crear grupos de baselines con lo cual podemos englobar ciertas actualizaciones que nosotros queramos, para esto vamos a Solutions and Applications>Update Manager>vCenter , una vez dentro de la vista de administrador de VUM vamos a Baselines and Groups.



Troubleshooting de VUM

En la guia de instalación y administración de VUM a partir de la pagina 163 podemos ver resolución de problemas comunes.

http://www.vmware.com/pdf/vsp_vum_41_admin_guide.pdf

Generar reportes de base de datos de VUM utilizando Excel o Microsoft SQL

Esto esta muy bien documentado en la guía de instalación y administración de VUM, pueden encontrarlo en la página 161 del mismo documento.

Actualizar vApps con VUM

Es tan simple como seleccionar dicha vApp dentro del inventorio y agregar el baseline deseado, escanear dicha vApp y en caso de necesitar una actualización remediarla.

Línea de Comando para UMDS

Tenemos la capacidad de modificar ciertos aspectos de configuración con la línea de comando de umds:

Para solo descargar actualizaciones de hosts ESX/ESXi:

vmware-umds –set-config –enable-host 1 –enable-win 0 –enable-lin 0

Para solo descargar actualizaciones de VMs Windows:

vmware-umds –set-config –enable-host 0 –enable-win 1 –enable-lin 0

Para solo descargar actualizaciones de Linux:

vmware-umds –set-config –enable-host 0 –enable-win 0 –enable-lin 1

Para descargar aquellas actualizaciones configuradas:

vmware-umds –download

Para modificar la ruta del repositorio de actualizaciones:

vmware-umds –set-config –patch-store C:\rutaalacarpeta

Para exportar las actualizaciones descargadas incluyendo el metadata a un share:

vmware-umds -E –export-store C:\ruta

Para exportar las actualizaciones pero de un periodo de tiempo en específico:

vmware-umds -E –export-store C:\ruta –start-time 2009-05-01T00:00:00 –end-time
2009-05-31T23:59:59