Comandos habituales

29 mayo, 2013

MAQUINAS REGISTRADAS EN HOST Y VMID: vim-cmd vmsvc/getallvms |grep <vm name>
ESTADO DE LA MAQUINACON EL VMID: vim-cmd vmsvc/power.getstate <vmid>
ESTADO DE LAS VNICS: esxcfg-nics -l
LISTAR COMANDOS ESXCFG: /sbin/ls -l esxcfg*
MAQUINAS ENCENDIDAS Y SU ID: vm-support -x
EXPORTAR LOGS: vm-support
LISTAR MAQUINAS Y UBICACION: vmware-cmd -l
ESTADO DE LA MAQUINA: vmware-cmd <*.VMX> getstate
APAGAR/ENCENDER/RESETEAR: vmware-cmd <vm-cfg-path> start/stop/ <powerop_mode>


Como saber si un disco duro está siendo utilizado

1 abril, 2013

Hay ocasiones en que tenemos algún disco vmdk aislado y no sabemos si está asociado a alguna maquina. Para ello podemos utilizar el comando:

egrep -i <nombredeldisco>.vmdk /vmfs/volumes/*/*/*.vmx

Este comando busca el vmdk dentro de los archivos vmx dentro del host donde se ejecuta, por lo que tendríamos que ejecutarlo en todos los hosts que vieran el almacenamiento donde se ubica el vmdk.


Nueva versión de RVtools

7 marzo, 2013

En grandes entornos, solemos tener problemas a las hora de buscar una máquina en la vista de VM y Templates.

La nueva versión de RVtools nos facilita enormemente esta tarea ya que han añadido en la pestaña vInfo la carpeta que contiene la máquina.

 

GRACIAS OTRA VEZ!

 


Herramientas de terceros indispensables

5 noviembre, 2012

Después de un tiempo de inactividad por un cambio de proyecto vuelvo a ponerme con el blog aconsejando dos herramientas muy útiles para el día a día en la administración de VMware.

RVtools: es una aplicación sencilla pero muy útil. En una ventana en .Net 2.0 se nos muestra información de CPU, memoria,  red, … de toda nuestra plataforma. Cabe destacar la pestaña vHearth que nos muestra posibles problemas detectados en nuestro entorno, como por ejemplo, maquinas o discos huérfanos  máquinas con nombres inconsistentes, snapshots, dispositivos conectados, etc…

Podemos importar la información a un Excel para realizar rápidamente informes.

Nos podemos descargar la aplicación en:

http://www.robware.net/

VMturbo: excelente aplicación para la gestión de carga de trabajo y motorización, con infinidad de funcionalidades. En un solo vistazo podemos comprobar si nuestro entorno de VMware esta corriendo correctamente o si tenemos alguna incidencia.

Podéis descargarla en:

http://www.vmturbo.com/


Diseño de VMware vSphere: 6 cuestiones importantes

20 febrero, 2012

Buscando información de los puntos mas importantes para el diseño de una infraestructura VMware vSphere, he encontrado una presentación muy interesante que se planteaba estas 6 cuestiones:

1. ¿vSwitch estándar o distribuido?

2. ¿vCenter físico o virtual?

3. ¿Servidores enracados o blades?

4. ¿ESX o ESXi?

5. Mejores practicas en cuanto a la ubicación de los hosts en cluster.

6. Mejores practicas en cuanto a la ubicación de las VMs en las LUNs.

Voy a intentar explicarlo lo mejor posible en castellano…

¿vSwitch estándar (VSS) o distribuido (VDS)?

– vSwitch distribuido necesita licencia Enterprise Plus

Estas características están disponibles con dos tipos de switches virtuales:

– Pueden enviar tramas L2
– Pueden segmentar el tráfico en VLANs
– Pueden utilizar y entender VLAN 802.1q
– Pueden tener más de un uplink (NIC Teaming)
– Pueden tener traffic shaping para outbound (TX) traffic

Estas características están disponibles sólo con Distributed Switch:

– Permite inbound (RX) traffic
– Tiene una interfaz de gestión centralizada unificada a través de vCenter
– Soporta VLAN privadas (PVLAN)
– Proporciona personalización potencial de los datos y planos de control

vSphere 5.0 proporciona las siguientes mejoras a la funcionalidad de Distributed Switch:

– Mayor visibilidad entre el tráfico de máquina virtual a través de Netflow
– Un mejor control a través de la duplicación de puertos (dvMirror)
– Soporte a  LLDP (Link Layer Discovery Protocol), un protocolo independiente del proveedor.

Con las características que necesitemos para nuestro entorno de VMware optaremos por uno u otro teniendo en cuento el licenciamiento.

 ¿vCenter físico o virtual?

Beneficios de vCenter físico:

– No compite con los recurso de las demás máquinas virtuales.

– Si fallan los ESX tendremos podremos acceder inmediatamente al vCenter  sin tener que esperar que HA se ejecute.

Beneficios de vCenter virtual:

– No se necesita gastar dinero en un servidor físico.

– Poder usar la características mas importantes de vCenter, tales como, HA, DRS, vMotion, Snapshots, vSwitch distribuidos, …

– Poder realizar una restauración rápida del servidor en caso de desastre.

– Poder asignar mas recursos al servidor en caso necesario.

– Administración centralizada mas potente.

¿Servidores enracados o blades?

Beneficios de servidores en blade

– Ahorro de espacio.

– Menor consumo de energía, ya que está más optimizada y necesita menos tiempo de enfriamiento. Además los chasis de los blades consumen mas o menos energía dependiendo del numero de servidores que tengamos encendidos.

– El chasis se conecta con un solo cable, lo que elimina el desorden de cables.

– Permite arrancar las máquinas virtuales desde la SAN, mediante PXE.

Beneficios de servidores enracados

Aunque las tecnología blade ha evolucionado bastante, los principales beneficios podria ser:

–  Mayor número de adaptadores de red y almacenamiento.  Servidores tradicionales es la mejor opción si necesitamos un gran número de tarjetas de red o los controladores de almacenamiento.

– Si un chasis de blade se completa, es necesario comprar otro.

– Mas fácil de instalar y configurar.

– Tienen puertos serie, paralelo y USB de E / S para conectar dispositivos externos

¿ESX o ESXi?

Debido a que la nueva versión de vSphere instala únicamente  ESXi, dejaré por obsoleta esta cuestión. ESXi no trae la consola de administración con lo que tendremos que familiarizarnos con VMware vSphere Command-Line Interface (vSphere CLI)

Mejores prácticas en cuanto a la ubicación de los hosts en cluster

Seguir las mejores prácticas descritas en la página 51 del documento: http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Mejores practicas en cuanto a la ubicación de las VMs en las LUNs.

Por lo que he estado leyendo en foros y documentación, lo óptimo es crear LUNs de 500 a 800 Gb que alberguen de 10 a 12 máquinas virtuales.


Entendiendo la pestaña “Resource Allocation” en una VM

5 enero, 2012

En el post anterior explicaba la pestaña “Resource Allocation” en un cluster, ahora vamos a ver la misma pestaña pero en un máquina virtual.

Los gráficos se dividen en CPU y Memoria.

– En cuanto a la CPU no hay nada nuevo, nos muestra los mismos valores que en el cluster, pero esta vez, en un gráfica.

– En la memoria si hay nuevos valores que intentaré explicar:

En primer lugar hay que diferenciar entre host memory y guest memory.

– Host memory, es la cantidad de memoria que está consumiendo la VM en el ESX.

– Guest memory: es la cantidad de memoria que se está consumiendo en realidad en ese momento. Dentro de guest memory existen varios tipos de memoria:

  • Private: es la cantidad de memoria que esta respaldada por la memoria del host y no esta compartida-
  • Shared: es la cantidad de memoria que está compartida.
  • Swapped: es la cantidad de memoria que está haciendo swapping.
  • Balloned: es la cantidad de memoria que está haciendo ballooning. Con el balloon-driver, lo que se hace es que una VM puede ceder memoria al VMKernel y este asigna dicha memoria a otra VM  que necesita memoria RAM. 
  • Unaccessed: entiendo que es la memoria que no se está usando en ese momento.
  • Active: entiendo que es la memoria que se está usando en ese momento.

Entendiendo la pestaña “Resource Allocation” en un cluster

4 enero, 2012

Voy a intentar explicar los elementos  de la asignación de recursos en un cluster para que queden claros a la hora de modificarlos, ya que de ello depende muchas veces, que las máquinas que corren en dicho cluster puedan utilizar los recursos del cluster de manera ordenada.

En cuanto al cluster:

  • CPU:  

– Total Capacity: es la cantidad total de CPU en MHz que tenemos en ese cluster.

– Reserved Capacity (capacidad de reserva): Nos muestra la cantidad de CPU que el cluster necesita para que haya alta disponibilidad y que , por lo tanto, tiene reservada.

– Available Capacity (capacidad disponible): es la cantidad de CPU que no está reservada para HA y que, por lo tanto, tenemos disponible.

  • Memoria.

– Total Capacity: es la cantidad total de memoria en MB que tenemos en ese cluster.

– Reserved Capacity (capacidad de reserva): Nos muestra la cantidad de memoria que el cluster necesita para que haya alta disponibilidad y que , por lo tanto, tiene reservada.

– Overhead Reservation (reserva de overhead): El overhead es  la cantidad de memoria necesaria para que el ESX virtualize la memoria física.

– Available Capacity (capacidad disponible): es la cantidad de memoria que no está reservada para HA y que, por lo tanto, tenemos disponible.

En cuanto a las VM:

– Nombre: el nombre de la VM.

– Reservation: con este parámetro le reservamos un mínimo de CPU o memoria a esta máquina.

– Limit: es la máxima cantidad de CPU o memoria que puede utilizat la VM.

 – Shares: en CPU, permite a una máquina ser la primera en disponer de tiempo de procesador en contra de otras máquinas con este parámetro mas alto. En RAM, si una VM tienen que competir con otras por la consulta de memoria compartida, este parámetro establece la prioridad.

Los shares especifican la importancia de una máquina virtual. Si una VM tiene el doble de shares de un recurso que otra VM, tiene derecho a consumir el doble de este recursos cuando estas dos VM compiten entre si por lo recursos.

Los shares se pueden configurar como High, Normal o Low, en una proporción de 4:2:1, respectivamente. También podemos configurarlo como Custom, con lo que asignamos un número especifico de shares a cada máquina.

– Shares Value: según la cantidad de memoria o de CPU de la VM y con el parámetro que hayamos configurado el share, se le asiguna un valor de share.

High: 2000 shares per virtual CPU / 20 shares per megabyte of configured virtual machine memory.

Normal:  1000 shares per virtual CPU / 10 shares per megabyte of configured virtual machine memory.

Low: 500 shares per virtual CPU / 5 shares per megabyte of configured virtual machine memory.

– % Share: Porcentaje de recursos del cluster asignados la VM. 

– Worst Case Allocation: es la cantidad de memoria que a la máquina virtual se le puede asignar cuando todas las máquinas virtuales están consumiendo el total de recursos asignados. Básicamente, cuando hay saturación de recursos, esto son los recursos con los que la VM contará en el peor de los casos.