Identificación de CPU

Identificación de CPU

Es importante conocer datos sobre los procesadores de nuestros servidores actuales (o futuros), con objeto de poder utilizar sin problema funcionalidades como “vmotion”, “ft”, etc.

A través de este link de vmware podemos descargar una imagen .iso para obtener esa información:

https://www.vmware.com/support/shared_utilities

Displays CPU features for VMotion compatibility, EVC and indicates 64-bit VMware support.

Es tan sencillo como arrancar un servidor con esa imagen .iso, y ver los datos que nos muestra, vamos a ver un ejemplo:

1

1

Como podemos observar, nos aparecen datos de SSE, de esta manera podemos comparar con otros servidores , con objeto de ver si tienen mismas instrucciones para “llevarse bien” en el caso de una migración con vmotion.

En el caso del equipo del ejemplo, NO soporta EVC , por tanto no nos muestra el modo EVC con el que puede trabajar.

El inconveniente que le veo a esta herramienta, es que no lo podemos lanzar en remoto contra una máquina en concreto, sino que necesitamos parar la producción en esa máquina  y reiniciarla para ver esta información, imaginaros que iniciais un proyecto de virtualización y necesitamos saber si podemos “reutilizar servidores fisicos” que actualmente están en producción, y no podemos apagarlos o no es tan fácil.

Un saludo,

 

 

 

 

 

Anuncios

Expansión de Datastores

Expansión de Datastores

En este documento vamos a ver el proceso de expandir un datastore en vsphere. Vamos a ver las distintas opciones que tenemos.

Procedemos a ir a nuestra cabina de almacenamiento (imaginemos que accedemos a una cabina via FC, por ejemplo una v7000 de IBM).

1

Ahi creamos un nuevo volumen, en la imagen vemos uno de 250 gb.

Ahora a través de vcenter, en el esxi “creamos un nuevo datastore” y le llamamos “PruebaGROW” como vemos en la imagen:

2

Lo montamos sin problemas en un esxi.

Ahora sobre el datastore con el botón derecho vamos a “PROPIEDADES”.

3

Como vemos en la imagen, el disco es de 200 gb, es decir, en la cabina la primera vez se creo un volumen de 200 gb, después en la cabina se agrando 50 gb mas, y como podemos ver esta información nos la muestra al dar en propiedades sobre el datastore.

Por tanto volvamos a ver el tamaño de nuestro datastore:

4

Vemos que el tamaño son 200 gb, nuestro objetivo es subirle esos 50 gb adicionales que nos indica las propiedades.

 

PRIMERA CUESTION

No vamos a poder aumentar esos 50 gb a ese datastore, mientras “otros hosts” tengan montado ese datastore.

Por tanto tenemos que mirar en la cabina si ese datastore es accedido por mas host, si es accedido por mas host , nos encontraremos que no nos aparecen esos 50 gb extra, como vemos en el ejemplo:

5

A la izquierda debemos pulsar en INCREASE, luego a la derecha nos debería aparecer esos 50 gb extra, NO lo hace al tener mapeados mas de un host.

6

En la imagen superior vemos que en la cabina a ese volumen acceden dos host (ESX7 y 8).

Para poder ampliar ese datastore , debemos por tanto quitar el mapeo de un host y dejar solo un host que vea el datastore.

7

NOTA:

Es importante REESCANEAR antes , ya que en el host al que hemos desmapeado el acceso al datastore nos puede aparecer de la siguiente manera:

8

Por tanto, aunque no es accesible, seguramente no podremos ampliar el espacio disponible en el datastore al otro host.

 

9

10

11

Una vez concluido ya vemos que ahora el espacio es de 250 gb.

12

SEGUNDA CUESTION

 

En la infraestructura puede existir alguna máquina virtual que esté utilizando RDM , (raw device mapping).

Raw Device Mapping consiste en que una de nuestras máquinas virtuales, tenga un disco duro que apunte a un disco físico de la cabina de almacenamiento. Es decir, tienen una “ruta” para accedir directamente a un disco.

Normalmente se crea un volumen en la cabina, ese volumen lo puede contener varios discos físicos, después ese volumen se presenta al vmware a través de datastores, ese datastore se formatea con el sistema de archivos de vmware (VMFS), por tanto las máquinas están almacenadas en ese sistema de archivos , con las cualidades de ese sistema de archivos (sistema de archivos en cluster).

RDM no usa VMFS, una disco de una máquina que esté como RDM, puede estar formateado en un sistema de archivos como NTFS.

Cuando tenemos alguna máquina con RDM y esa ruta hacia un disco de la cabina está en ese datastore que queremos ampliar, NO vamos a poder ampliar el datastore.

 

TERCERA CUESTION

 

Si necesitamos ampliar el tamaño de un datastore, pero tenemos maquinas con RDM o varios host ven el mismo datastore, podemos:

Lo ampliamos en la cabina

Reescaneamos all

Migrar las máquinas de ese datastore a otro con vmotion.

Ir a propiedades para ver si en VMFS está expandido.

Destruir el datastore y volverlo a crear ya con el tamaño deseado.

Comprobar que el tamaño es el ok.

 

CUARTA CUESTION

 

Otra opción que tenemos para ampliar el datastore es , en lugar de acceder al vcenter para ampliar el datastore, “accedemos directamente a un host esxi”, desde allí podremos perfectamente añadir el espacio disponible al datastore.

NOTA: Este procedimiento nos lo explica vmware en el siguiente artículo

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

To increase the capacity of a VMFS datastore:

  1. In vCenter Server, select the Datastores view.
  2. Select the datastore you want to grow and identify the host that has more virtual machines running on it.
  3. Open another vSphere client that connects directly to the ESX host.
  4. Go to Configuration > Storage adapters and perform a rescan. For more information, see Performing a rescan of the storage on an ESX/ESXi host (1003988).
  5. Go to Configuration > Storage, click the datastore that you want to grow, and click Properties.
  6. Ensure that the new size of the device is listed in the Extent Device list. If the increased size does not reflect, review the changes on the storage array and rescan again.
  7. Click Increase.
  8. Select a device from the list of storage devices for which the Expandable column is Yes and click Next.
  9. Set the capacity for the extent. The default capacity for the extent is the entire free space on the storage device.

    Note: VMware recommends you to use the default setting.

  10. Click Next.
  11. After the process completes, go to vCenter Server, right-click the cluster that sees the expanded datastore, and click Rescan for Datastores. For more information, see Performing a rescan of the storage on an ESX/ESXi host (1003988).
  12. If there are other hosts that see the expanded datastore, perform a rescan on these hosts also.

 

QUINTA CUESTION

 

En este artículo de vmware, nos dice las causas de porqué NO podemos extender un datastore:

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

Sintomas:

  • You cannot extend a datastore when vSphere Client is connected to vCenter Server.
  • vCenter Server does not show available unused space.
  • The SAN LUN is extended and the new storage appears under Storage Adapters when viewed in vCenter Server. When you extend the datastore through the datastore properties, the free space does not appear.
  • You can extend a datastore when vSphere Client is connected directly to the ESX host.

Solucion:

vCenter Server calls a specific function to get all the available extents for that datastore. After getting extents, vCenter Server displays the extents as available if they meet these criteria filters:

  • LUNS are not used as datastores on that host or on any other host (with exceptions to force mounted volumes).
  • LUNS are not used as Raw Device Maps(RDMs) on that host or any other host.

 

CONCLUSIONES

 

Según las condiciones actuales, configuraciones, o cambios de nuestro entorno de la organización, es posible que tareas como la expansión de datastores no se pueda realizar de manera tradicional (expandir volumen en cabina, reescanear , y el datastore aparece aumentado), además de por los propios métodos y mecanismos que vmware tiene para evitar corrupciones de datos.

Hemos citado las formas que hay de poder aumentar un datastore.

 

Un saludo,

Desregistrar extensión VR

Desregistrar extensión VR

Imaginemos un entorno con dos CPDs en donde hay conectividad entre ellos, es decir, los vcenter se pueden comunicar.

Queremos implementar la replicación de vmware (VR) para que las máquinas del cpd1 esten en el cpd2 y al revés, y cuando me haga falta en caso de desastre en el cpd1 por ejemplo, poder levantar esas máquinas en el cpd2.

Este artículo trata de “desregistrar” del vcenter, un VR en uno de los CPDs que tiene una versión diferente al otro Cpd, es decir , queremos versiones iguales de VR en ambos cpds.

Cuando borramos la appliance de VR, no se borra la extensión registrada en el vcenter, por lo que al desplegar y configurar un nuevo VR , puede haber problemas de comunicación con el VR real.

Procedemos entonces a eliminar extensiones innecesarias:

1

Aqui vemos dos extensiones de VR, son las dos de los dos CPDs, a mi me interesa eliminar una de ellas, ya que la otra si tiene la versión que me interesa.

Tecleamos en el navegador https:/ipdelvcenter/mob

 

P2

En la lista pulsamos donde pone “ExtensionManager”.

3

Nos saldrá la lista de extensiones, seleccionamos la de VR:

4

Ahí pulsamos encima para acceder a la opción de “desregistrar2:

5

Y en “value” ponemos el nombre tal cual.

6

Es decir….com.vmware.vcHms

7

Y con esto pulsamos en la esquina inferior derecha donde pone “Invoke Method”, debemos asegurarnos que en “method Invocation Result:” aparece VOID.

Ahora si volvemos a las extensiones de vcenter ya no la tenemos,

Un saludo,

 

 

Vcenter 5.5 exceso consumo CPU

Vcenter 5.5 exceso consumo CPU

Un dia cualquiera nos encontramos con nuestro vcenter 5.5, en consumos de 100% de cpu, haciendo imposible el acceso via web o mediante virtual infrastructure client.

Los servicios están arrancados.

En los procesos se observa el servicio vcenter con alto consumo de cpu, asi como procesos java, servicio de inventario….etc , con alto consumo.

Después de darle vueltas a todo y no funcionar nada de lo probado, me da por mirar el estado de la base de datos, básicamente el espacio libre, veo que el espacio libre es de 15 mb.

Por tanto procedo a reducir el tamaño de la base de datos.:

Os remito a este artículo de vmware, y pego el procedimiento seguido:

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

——————————————————————

Primero como es lógico, hacer un backup de la base de datos.

Parar los servicios de vcenter.

Purga de datos en la tabla VPX_EVENT :

 

  1.  databases  seleccionar VIM_VCDB > Tables.
  2. Botón derecho sobre,  dbo.VPX_PARAMETER Open.
    Comprobar que……..
  3.  event.maxAge está 30, and  event.maxAgeEnabled a true.
  4. task.maxA age a 30task.maxAgeEnabled a true.Ir a……..
    1.  VIM_VCDB > Programmability > Stored Procedures.
    2. Sobre dbo.cleanup_events_tasks_proc seleccionamos Execute Stored Procedure.Estos purga datos desde vpx_event, vpx_event_arg, y vpx_task
  5. Despues de terminar este proceso (puede durar 1 hora), hacemos una  nueva query y tecleamos: 1, ejecutamos. Puede tardar como 15 minutos.
    1. Cerrar y arrancar servicio vcenter

Reiniciamos el vcenter.

Al principio observamos que la CPU es alta, pero en unos minutos la base de datos está reducida y el consumo se reduce hasta límites normales.

 

Un saludo,

VDP residuales

VDP residuales

Vmware Data Protection.

Teniamos una instalación de VDP y vamos a proceder a desplegar una nueva appliance.

Si vamos via web a nuestro vcenter, observamos que el plugin de la versión anterior de VDP sigue apareciendo., es decir, aparece el icono de data protection.

Lo queremos eliminar, o bien, puede ocurrir que después de haber implementado la appliance de VDP , NO veamos el icono, y, lógicamente sin él no podemos gestiónar las opciones de backup.

Tecleamos lo siguiente en nuestro navegador:

https://<ip de nuestro vcenter>/mob

1

Seleccionamos “content”, nos aparece una lista y seleccionamos “extensionmanager”.

2

Veremos algo parecido a esto:

3

Pondrá extensionlist “com.vmware.vdp”, “com.vmware.vdp2″…..

4

Pulsamos en “unregisterextension”, y luego en donde pone InvokeMethod”.

5

En donde pone VALUE introducimos lo que veiamos anteriormente en extensionlist.

6

Este procedimiento nos sirve para que o bien “nos aparezca vsphere data protection”, o para “quitarlo”.

Un saludo,

Ram en vcenter appliance

Ram en vcenter appliance

Situación:

Necesitamos bajar la memoria ram asignada a un vcenter appliance, recordemos que por defecto nos pone 8 gb de ram. Para un entorno pequeño es mas que suficiente con 4 gb.

La versión de hardware que tenemos es version 11, por tanto debemos ir via web para reducir ram, ya que mediante virtual infrastructure client no nos deja entrar a las propiedades.

1

NO tenemos “hot add” activado, por tanto necesitariamos apagar la máquina virtual para poder bajar la memoria ram asignada.

Si apagamos la máquina virtual ¿que pasa entonces?, pues que no podemos acceder via web para reducir la ram.

2

Vmware nos dice que para reducir ram , entremos por https a la appliance y en “services” en la parte de “inventory size”, seleccionemos en el desplegable el tamaño que deseamos, seleccionamos “small”, mejor dicho, es lo que aparece por defecto para el entorno mas pequeño (menos de 100 hosts).

Por tanto por ahí no podemos hacer nada mas para reducir la ram.

La máquina virtual en las propiedades tiene asignado 8 gb y no podemos editar las propiedades para reducir la ram.

Posible solución:

(La he probado en producción).

Entramos por ssh a la appliance y modificamos los siguientes ficheros:

(vSphere Web Client Service)

usr/lib/vmware-vsphere-client/server/wrapper/conf/wrapper.conf

Cambiar wrapper.java.maxmemory a 1024 (default = 2048)

3

(Inventory Service)

/usr/lib/vmware-vpx/inventoryservice/wrapper/conf/wrapper.conf

Cambiar wrapper.java.maxmemory a 1536 (default = 3072)

4

(Storage Profile Service)

/usr/lib/vmware-vpx/sps/wrapper/conf/wrapper.conf

Cambiar wrapper.java.maxmemory a 512 (default =1024)

Shut down de la appliance.

Despues del apagado debemos cambiar las propiedades a 4 gb, el problema es que no vemos la forma porque debemos apagar el vcenter y entrar via web no podemos, editamos el archivo .vmx y cambiamos ahí 8 por 4.

5

Arrancamos la máquina vcenter appliance.

NOTA: Aunque hemos cambiado el archivo .vmx con 4 gb, en las propiedades de la máquina virtual sigue apareciendo 8.

Aunque, una vez la arrancamos ya se actualiza.  🙂

6

Por tanto ya tengo lo que queria, una reducción de la ram de mi vcenter appliance.

NOTA: Este procedimiento me ha funcionado en mi entorno de laboratorio, pero esto mismo en entorno productivo “no a medias”, es decir, si he conseguido reducir algo de ram en la máquina virtual vcenter appliance (al menos 1 gb), aunque en las propiedades sigue poniendo 8. Seguiremos investigando.

Un saludo,

 

Vsphere. Alternativas al backup de pago

Vsphere. Alternativas al backup de pago

Si, eso es, hace años en entornos de virtualización se hacian backup con scripts, luego aparecieron diferentes herramientas de backup, imaginemos que esa herramienta que tenemos de backup , no podrá estar operativa algunos dias, bien sea porque tenemos realizada una migración de una infraestructura de vcenter a una versión mas moderna y nuestro backup es mas antiguo y no tenemos licencias para esa versión, o tenemos que actualizar la versión de backup para que reconozca el nuevo vcenter…. por lo que sea, el caso es que “de mientras”, debemos realizar un backup.

Y ahí es donde entran esos scripts de backup que mientras durá ese  proceso los podemos implementar, o bien incluso en algunos casos , ser la alternativa del backup de pago.

En este caso os doy a conocer uno que se llama:

XSIBackup

He creado dos datastores:

Uno para instalar ahí mi script de backup, y otro en donde voy a dejar los backup.

1

Lo primero es instalar el soft de backup con scripts, me voy a conectar por ssh al servidor esxi, voy a ir al datastore SSD y ahí ejecuto el comando para descargarlo e instalarlo:

2

3

wget http://33hops.com/downloads/xsibackup.zip -O xsibackup.zip && unzip -o xsibackup.zip && chmod 0700 xsibackup*

Con esto ya lo tenemos descargado e instalado, muy sencillo.

Hacemos un ./xsibackup y esperamos….

Nos aparecerán los argumentos de uso:

4

Bien, ahora en el datastore que hemos definido para dejar los backup, voy a crear una carpeta , en donde dentro el script dejara los backup:

5

Bueno, como veis la carpeta la he llamado “losbackup”.

Ahora vamos a lanzar un comando para realizar el backup de las máquinas que tenemos un uno de nuestros datastores:

6

/vmfs/volumes/ssd/xsibackup –backup-point=/vmfs/volumes/backup –backup-type=running

Va viendo las máquinas de nuestros datastores y va realizando el backup a la carpeta que hemos creado:

NOTA: Durante la redacción de este documento si os fijais hay un error, yo habia creado una carpeta en donde queria dejar los backup, que se llamaba “losbackup”, en lugar de dejarlos ahí se están quedando en la raiz del datastore “backup”.

Importante es tener las tools instaladas para que no nos salga el siguiente mensaje:

7

Nos da datos de necesidades de espacio para el backup y las máquinas que se están haciendo backup:

8

Durante el backup si nos fijamos en las máquinas, el script hace un snapshot mientras está con el backup:

9

Lógicamente al acabar el backup los elimina:

11

Toda la progresión de backup lo vemos durante la ejecución en la consola:

10

Y paralelamente a comprobar desde la consola , vamos viendolo al explorar nuestro datastore destinado al backup, las carpetas con los nombres de las máquinas virtuales.

12

En este caso la máquina SI tiene las tools y por tanto no nos da el mensaje que os presentaba mas arriba.

13

Y vemos cómo está creando el snapshot.

14

Seguirá haciendo backup… y veremos progresiones.

15

Elección de máquinas para el backup

En el comando con la opcion “custom”, podemos especificar “de qué” máquinas queremos hacer backup:

20

/vmfs/volumes/ssd/xsibackup –backup-point=/vmfs/volumes/backup –backup-type=custom –backup-vms=“VIO-DHCPServ
er-0,VIO-DHCPServer-1″

Programar el Backup

En nuestra linea de backup podemos especificar cuándo queremos realizar el backup programado , y ” de qué máquinas”.

Lo hacemos con cron y para ello lo activamos:

./xsibackup –install-cron

16

Como veis hay que reiniciar el host una vez instalado el cron.

Una vez reiniciado veremos que nos ha creado un fichero llamado “xsiackup-cron”, un archivo editable para ir cambiando lo que necesitemos.

17

–time=”Mon 02:00|Tue 02:00|Wed 02:00|Thu 02:00|Fri 02:00|Sat 02:00|Sun 02:00″

18

Un ejemplo de backup programado a las 02:00

Ahora ponemos un ejemplo para que nos haga copia durante los dias de la semana a las 2 y el dominigo a las 11.40, de dos máquinas.

19

/vmfs/volumes/ssd/xsibackup –time=”Mon 02:00|Tue 02:00|Wed 02:00|Thu 02:00|Fri 02:00|Sat 02:00|Sun 11:40″ –date-dir=yes –back
up-room=500 –backup-point=/vmfs/volumes/backup –backup-type=custom –backup-vms=”VIO-DHCPServer-0,VIO-DHCPServer-1″

ssd : es donde tenemos nuestro script

Fecha programada

Maquinas a realizar backup.

 

Backups Diferenciales

A parte de poder realizar “full backups”, tambien podemos realizar “diferenciales”.

Rsync se encarga de ello.

Podemos hacer backup diferenciales en local , o en otro host esxi.

Para hacer en otro host, primero tenemos que “linkarlos”, y luego ya podremos hacer backups diferenciales, algunos ejemplos:

xsibackup –link-srv=192.168.0.181

# ssh -o StrictHostKeyChecking=no -i xsibackup_id_dsa root@[192.168.0.181]

Y ahora el backup diferencial:

# /vmfs/volumes/ssd/xsibackup –backup-point=”192.168.0.181:/vmfs/volumes/ssd” –backup-type=custom –backup-vms=dc1

Esto es todo, espero os sirva.

Para mas información, la ayuda del script.

Un Saludo,