vCenter 6.7 programar backups

vCenter 6.7 programar backups

Con vCenter 6.7 tenemos la posibilidad de realizar backups de la configuración (inventario, y configuración, estadísticas, eventos y tareas…).

Imaginemos que deseamos actualizar nuestro vcenter 6.7, debemos estar cubiertos ante un posible desastre en la actualización.

Dicha funcionalidad se encuentra disponible si accedemos a nuestro vcenter 6.7 appliance a través de :

https://iponombre:5480/ui

Una vez dentro, debemos ir en la parte izquierda de nuestra pantalla, y al final del todo vemos “copia de seguridad”, tal y como vemos en la siguiente imagen:

menu

Desde aqui podremos configurar la ubicación de la copia de seguridad, credenciales de acceso al servidor donde vamos a dejar los archivos de copia, y la programación. Asimismo podemos “cifrar” la copia de forma opcional. Estableceremos la retención y marcamos la información que deseamos (estadísticas, eventos y tareas….).

5

Para la ruta donde almacenamos el backup, podemos utilizar por ejemplo un servidor windows que tenga un recurso compartido en donde dejemos las copias, por tanto se utiliza el protocolo SMB, y , vmware necesita que lo especifiquemos:

protocolo-iponombreservidor-recurso

Tal y como vemos en la imagen superior.

Una vez rellenado todo, deberiamos poder ejecutar el backup pulsando en “realizar copia de seguridad ahora”.

NOTA: Después de esto, podria ocurrir que nos dé un error en el servicio “vmware-postgres-archiver”, el cual podria estar parado, si esto es asi, debemos conectarnos por ssh al servidor vcenter, entrar a la shell y levantar ese servicio, de la siguiente manera:

1

Tan sencillo como arrancar el servicio, si no sabeis cómo se llama exactamente, lo mejor es listar todos los servicios y buscar el nombre exacto:

2

Tras esto, ya deberiais poder hacer el backup con tranquilidad.

6

Y en la carpeta del recurso aparecerán los archivos del backup de la configuración de nuestro vcenter 6.7.

7

 

8

Un saludo

vSAN activar Performance Service en politica alternativa

vSAN activar Performance Service en politica alternativa

En esta ocasión vamos a ver cómo se activa el servicio de Performance de vSAN a través de powershell para vSAN, pero , teniendo en cuenta que deseamos hacerlo para “otra” politica de almacenamiento que hayamos definido, recordemos que por defecto utiliza una, pero podemos crear mas.

En algunas versiones de vSAN, dicho servicio no está activado por defecto, por tanto, vamos a ver cómo de una manera muy sencilla se puede activar mediante comandos de powershell.

Get-VsanClusterConfiguration -Cluster “vSAN” | Set-VsanClusterConfiguration -PerformanceServiceEnabled $true

Nos apareceran varias columnas:

cluster, y pondrá vsan.

VsanEnabled, y pondrá true.

Como decia antes, eso lo activa para la “politica predeterminada de almacenamiento”, para activarlo para otra alternativa seria:

Get-VsanClusterConfiguration -Cluster “vSAN” | Set-VsanClusterConfiguration -PerformanceServiceEnabled $true -StoragePolicy (Get-SpbmStoragePolicy -Name “nombre politica”)

El resultado será el mismo que antes, aparecerá en la columna cluster, vsan, y en la columna VsanEnabld, true.

Así de sencillo, un saludo.

 

vSAN witness

vSAN witness

Como sabeis en vmware , integrado con vsphere vcenter, disponemos de la posibilidad de tener un sistema hyperconvergente llamado vSAN.

Esto quiere decir que de un pool de servidores que tienen discos locales, podemos conformar un único datastore con esos discos

vSAN admite las características de VMware que requieren almacenamiento compartido (como HA, vMotion y DRS) y, al mismo tiempo, elimina la necesidad de usar almacenamiento compartido externo y simplifica las actividades de aprovisionamiento de máquinas virtuales y configuración de almacenamiento.

VMware vSAN emplea un enfoque definido por software que crea almacenamiento compartido para las máquinas virtuales. Lo que hace es virtualizar esos discos locales de los esxi que conformaran el cluster vSAN, los transformara en “grupos de almacenamiento” que pueden generarse de forma automática por el propio software de vSAN o por nosotros pudiéndose dividir y asignarse a máquinas virtuales y aplicaciones basándonos en lo que necesitemos en cuanto a calidad de servicio.

Podemos configurar un cluster hibrido o basado todo en flash. En los hibridos tendremos que especificar qué discos con para “capacidad” y cuales para “caché”, cuando es todo flash se utilizan para memoria cache y de capacidad.

Witness

El motivo de este artículo precisamente es el objeto witness que podemos crear dentro de la infraestructura, y lo que hay que hacer para montarlo correctamente.

Es un componente que contendrá metadatos y no datos reales de aplicaciones. Al final su misión es tomar una decisión en relación con la disponibilidad de los componentes del almacen de datos que restan después de un error, (es decir, que falle algún disco en algún host).

Al final utiliza un sistema de quorum en donde cada componente puede tener mas de un voto para decidir la disponibilidad de los objetos, debe ser superior al 50% esa accesibilidad de los votos que componen el objeto de almacenamiento. Si por lo que sea es igual o inferior a ese %, el almacen de datos (datastore vsan) ya no puede acceder al objeto, esos objetos inaccesibles pueden lógicamente afectar a la disponibilidad de la máquina virtual.

Opciones para implementar vSAN

Cuando estamos montando el cluster de vSAN tenemos varias opciones , (no vamos a entrar en todas, solo en una de ellas motivo de este artículo en relación al witness), son las siguientes:

  • Cluster de vSAN standard , consta de un mínimo de 3 host
  • Cluster de vSAN con DOS host
  • Cluster ampliado de vSAN (este artículo)

Este artículo es para hablar del “cluster ampliado”, o mejor dicho, un cluster en donde tenemos DOS host, y un witness, es paso una imagen.:

cluster ampliado

Si nos decidimos a implementar un cluster de vSAN con DOS HOST, el problema que tenemos es “la disponibilidad”, es como si tuvieramos un RAID0 , es decir, el sistema crea un datastore único con la suma del tamaño de los discos de los dos servidores, pero, en RAID0, esto quiere decir que si hay alguna máquina en ese datastore, y por lo que sea falla un disco, tendremos un problema con la máquina virtual ya que no tenemos disponibilidad ante un número “x” de errores.

En el ejemplo de un cluster de TRES host, el tema es distinto, existe entonces una disponibilidad de 1, es decir, disponemos de la posibilidad de tener un RAID1, el inconveniente que tenemos aqui es el coste, aumentara primero lógicamente porque tenemos un servidor mas , o otro porque debemos disponer de un switch, si además lo tenemos conectado por FC, mas costoso todavia.

Asi que, como posibilidad mas económica, podemos configurar un cluster ampliado vSAN, hace años era obligatorio 3 host mínimo, pero ahora podemos tener solo dos un un witness y simular lo mismo que con tres host, todo gracias al witness o testigo.

Al grano

La idea de este artículo es disipar las dudas a la hora de implementar un vSAN cluster ampliado, (2 host y testigo).

Imaginaros una topologia de dos host, en donde están conectados via FC 10G “directamente”, es decir, sin switch (ahorro de costes).

En cada host esxi, tendremos un switch virtual , llamemoslé “vsan”, que tiene una vmnic pongamos que se llame la vmnic1, esa será la red de vSAN traffic, y habrá un puerto vmkernel (vmk1), con la red por ejemplo 10.10.10.x, aqui debemos activar la casilla “vSAN” que aparece cuando editamos el puerto vmkernel. Con esto le estamos diciendo que  por ahí vaya el tráfico de vsan,  es decir, por esa red específica. También podremos activa la casilla vmotion.

Por otra parte cada host tendrá su vmk0 para management, imaginemos 192.168.10.x

El testigo.…..

Este será una máquina virtual que debemos desplegar en la infraestructura de vsphere, dicha máquina virtual se puede descargar de la web de vmware, y , después personalizarla con los datos de ip convenientes.

Realmente, cuando arrancamos la máquina vemos que es “un esxi”, ese esxi debemos añadirlo como “un host nuevo” en nuestro vcenter, PERO, FUERA DEL CLUSTER DE VSAN.

Pero es que esta máquina virtual, además , NO DEBE ESTAR EJECUTANDOSE EN ALGUNO DE LOS HOST DE VSAN, sino en otro host que tengamos (podria ser con licencia de esxi free).

Seguimos en busca del problema…..

La máquina virtual witness, nos vendrá con dos tarjetas de red, una para conectar a su administración, y otra para la red de vsan.

El tema es que con la topologia que os comento, NO vamos a poder conectar físicamente ese tercer host que ejecuta la máquina virtual witness en ningún sitio, ya que NO tenemos switch.

Y aqui está el error !!, creer que la tarjeta del witness se tiene que conectar a la red de vSAN de los host, mas bien lo que necesita es poder comunicarse con los host, por tanto para que no tengais problemas si os surge la necesidad de implementar dos host y testigo  sin switch para vsan, es pongo los siguientes esquemas, en donde claramente vais a poder ver , cómo conectar y configurar todo.

PRIMERA OPCION: UTILIZAR EL VMK0 DE MANAGEMENT

A mi me parece la mas sencilla, os pongo la imagen y la explico:

esquema por puerto administracion

Arriba del todo veis el witness, máquina virtual que se está ejecutando en un sitio fuera de los host del cluster de vsan, podriamos tenerla ejecutándose en otro  host de otro vcenter si es que tuvieramos otra infraestructura, o simplemente pinchado en la red de “servicio” o management que se tenga.

Os he dicho que venia con dos tarjetas de red, una se anula , y como veis se utiliza solo la VMK0 , es decir, management.

Ahí en el witness, tendriamos que editar el VMK0 y marcar la opción “vSAN”, únicamente.

NOTA IMPORTANTE: No vamos a poder editar el vmk0 y marcar la opción vsan, si no lo hacemos desde el servidor vcenter.

Luego vemos en la imagen que hay un switch, ese será el switch no de vSAN, sino de red donde tenemos pinchados los vLANS para mgmt, o red de servicio.

Los esxi de vSAN.

En la imagen veis que hay pinchado cable directo entre ellos para la red de vSAN. Cada servidor tendre su vmk0 de management, su vmk1 de vSAN, su vmk2 de vmotion….

Aqui lo importante es:

Que en el vmk1 de la red de vSAN, es decir, el cable directo, en las propiedades de ese vmk1 , marquemos la opción vSAN.

Y….también, que tageemos como “witness”, el puerto vmk0 de management, esto solo lo podemos hacer via comandos, pero el comando es muy sencillo, seria tal que asi:

Entramos a cada uno de los host y hacemos:

esxcli vsan network ip add -i vmk0 -T=witness

Después comprobamos con el comando:

esxcli vsan network list

comprobacion witness tag

Es decir, con esto lo que hemos hecho es configurar la topologia para que la máquina witness, se pueda comunicar con los host del cluster de vSAN, sin necesidad de tener un switch adicional, y sin necesidad de tener otro host mas.

Para comprobar que todo está correcto, podremos ir a la “supervisión” de vsan, para que nos vaya recorriendo todos los componentes (red, disco, cluster….etc), y nos diga si está bien o no.

Otra manera

Tenemos otra manera de configurar lo anterior, básicamente se trata de tener una red específica para cada esxi host, es decir, un trafico separado específico, lo mismo que antes os pongo un pantallazo, y ahí se ve claramente la diferencia, en donde ya en el witness hay un vmk1 especifico para vSAN traffic, con una ruta estática, y en los host lo mismo, tenemos un vmk1 que es donde tienen que llegar el witness.

esquema por puerto vmk especifico

Eso es todo !!, yo creo que simplemente con estos esquemas, seremos capaces de configurar un cluster de vSAN con dos esxi conectados directamente, sin switch y un witness o testigo como máquina virtual, para nuestros dominios de errores (si, igual no sabeis de que va esto, pero ampliaré mas información sobre vSAN en otro artículo).

Un saludo !!

 

 

VCSA fsck failed

VCSA fsck failed

Nos encontramos en un vcenter formato VCSA, es decir appliance de linux, el siguiente error:

fsck failed. Please repair manually and reboot. The root file system is currently mounted read-only. To remount it read-write do:
bash# mount -n -o remount,rw /
Attention: Only CONTROL-D will reboot the system in this
maintanance mode. Shutdown or reboot will not work.
Give root password for maintenance
(or type Control-D to continue):

error fcsk vcenter appliance

Para solucionar el problema, el procedimiento es el siguiente:

1.- Pulsamos Control-D para acceder a grub.

2.- Habilitamos el shell (bash), para ello pulsamos “p”, con la opción VMware seleccionada.

1

Introducimos la password de la cuenta de administrador (principalmente, o normalmente “administrator@vsphere.local”.)

2

Seleccionamos VMWare vCenter Server Appliance y presionamos la tecla “e”.

3

Seleccionamos la segunda entrada (la que comienza con Kernel) y pulsamos “e”.

4

Modificamos la línea final añadiendo init=/bin/bash y pulsamos enter para habilitar el bash Shell en el arranque.

5

Presionamos “b” para arrancar desde la línea modificada.

La máquina arranca hasta llegar al command prompt:

6

Introducimos los comandos:

mount -n -o remount,rw

fsck -f -c -y

Iniciara un proceso de reparación de errores en el fylesystem.

Cuando finalice ejecutamos el comando reboot para reiniciar el VCSA.

FIN

Este problema suele ocurrir cuando hay algún tipo de apagado no deseado, como es la ocasión, la cual la he aprovechado para que si os pasa lo mismo tomeis nota.

Un saludo.

NTP ver configuracion

NTP ver configuracion

Con esta linea de powershell , podemos ver las configuraciones de NTP de  nuestros servidores esxi:

configuracion ntp powershell

Get-VMHost | Select Name, @{N=”NTPSetting”;E={$_ | Get-VMHostNtpServer}}

Para cambiar a “todos” los esxi que tenemos la configuración NTP,  podemos lanzar la siguiente línea:

$NTPServers = “es.pool.ntp.org”, “pool2.ntp.org”Get-VMHost | Add-VmHostNtpServer $NTPServers

Como vemos, con powercli nos va a permitir una rápidez mayor a la hora de hacer algunos cambios, sobre todo si tenemos  muchos servidores.

Un saludo !!

 

Registros del sistema de host

Registros del sistema de host

Vemos la siguiente advertencia en los host:

alerta

ESXi se puede configurar para almacenar archivos de registro en un sistema de archivos en memoria. Esto ocurre cuando el directorio “/ scratch” del host está vinculado a “/ tmp / scratch”.

Cuando esto se hace, solo se almacena el valor de un solo día de registros en cualquier momento. Además, los archivos de registro se reiniciarán en cada reinicio.

Esto presenta un riesgo de seguridad ya que la actividad del usuario registrada en el host solo se almacena temporalmente y no persistirá durante los reinicios. Esto también puede complicar la auditoría y dificultar el monitoreo de eventos y el diagnóstico de problemas. El registro del host de ESXi siempre se debe configurar en un almacén de datos persistente.

Recuperar información actual

Get-VMHost | Select Name, @{N=”Syslog.global.logDir”;E={$_ | Get-VMHostAdvancedConfiguration Syslog.global.logDir | Select -ExpandProperty Values}}

Con esta línea de powershell, podemos sacar el listado de nuestros host con información de configuración :

ver configuracion con powershell

En la columna de “syslog.global.logdir”, vemos la configuración actual, en el caso de la imagen todo está correcto, ya que se especifica un datastore , asi como scratch/log.

Realmente lo que estamos viendo se corresponde con la configuración que existe en las opciones avanzadas del servidor en la parte de “syslog”, global.

configuracion a realizar

Si por lo que sea esa información está incorrecta y queremos solucionar el  mensaje de alerta del principio de este documento, o si deseamos cambiar la ruta, podemos ejecutar otra sencilla linea de powershell:

Get-VMHost | Foreach { Set-VMHostAdvancedConfiguration -VMHost $_ -Name Syslog.global.logDir -Value “otrodatastore” }

En donde en la parte de -Value pondremos el nombre del datastore a cambiar.

Un saludo !!

Copy/Paste en PowerShell

Copy/Paste en PowerShell

Hay veces (tampoco muchas), y mejor por seguridad, que necesitamos hacer “copy/paste” desde nuestro equipo a la consola de una máquina virtual en el entorno de vpshere.

Como NO es recomendable por seguridad según la “hardening guide” de Vmware, vamos a ver una línea de powershell que nos sirve para listar todas las máquinas que están infringiendo esta politica, es decir, que tienen activado para poder hacer “copy/paste”.

Get-VM | Get-AdvancedSetting -Name “isolation.tools.paste.disable” | where {$_.value –eq “false”} | Select Entity, Name, Value

Lo vemos por ejemplo en la siguiente imagen:

listado las que estan activas para poder hacer copy paste

En la imagen superior vemos una máquina que incumple, ya que el valor que devuelve es “false”.

copy paste

En la imagen superior vemos como dicha máquina tiene un valor de false y agregadas las dos líneas necesarias para activar o desactivar copy/paste.

El resto de máquinas, de forma predeterminada, tienen desactivada la posibilidad, por eso no aparecen.

Cambiar a TRUE

Podriamos lanzar otra linea de comando para asegurar que todas las máquinas estan imposibilitadas para hacer copy/paste:

Get-VM | New-AdvancedSetting -Name “isolation.tools.paste.disable” -value $true

Un saludo !!

 

 

Vmware Tools Error

Vmware Tools Error

Nos aparece el siguiente error al instalar las vmware tools en una máquina nueva, y realizándolo de la manera normal, (boton derecho, guest, install/Upgrade VMware tools“).

error que da

Podriamos ir a la web de vmware y descargar las tools para instalarlas, en este caso en un sistema operativo windows, el problema es que el sistema operativo no tiene red, por tanto no las podemos descargar directamente para instalar, y no podemos hacer un \\ip-nombre en otro equipo donde esté descargado.

Las tools desde la web de vmware vienen en formato .zip ,  para poder realizar esta instalación tenemos dos opciones:

  • Conseguir una .iso de las tools
  • Configurar COPY/PASTE para pegar el fichero dentro de la máquina virtual (aunque hay un problema, luego comento).

Conseguir una .iso de las tools

https://packages.vmware.com/tools/esx/index.html

Desde aqui buscamos la versión de nuestro esxi (con el update correcto), y tenemos la descarga en formato .exe y en formato .iso

desde donde se baja iso

Subimos por ejemplo la .iso a un datastore, y luego como siempre, vamos a propiedades de la máquina virtual y buscamos el fichero .iso (en el caso de windows veremos una carpeta “windows” en formato .iso).

Permitir copy/paste para copiar dentro de la máquina virtual

Esta es una opción que tenemos como otras muchas de la HARDENING (Recomendaciones de Seguridad) , (adjunto link).

https://www.vmware.com/security/hardening-guides.html

Se trata de editar (con la máquina virtual parada), las propiedades de la máquina virtual , pestaña OPCIONES, en la parte de “avanzado” vamos a “general”, y a la derecha vemos PARAMETROS DE CONFIGURACION, ahí hay que añadir dos líneas para permitir el copy/paste, son las siguientes:

copy paste

El problema es que, aunque hagamos esta configuración, al no tener las vmware tools instaladas (que es el objetivo), ésta opción no va a funcionar. (Lo pongo por si se nos habia ocurrido, saber que no es posible).

Asi pues, la mejor opción y mas sencilla, es conseguir una .iso de las tools.

Un saludo !!

 

Ballooning

Ballooning

En este mini artículo vamos a explicar qué significan unos contadores que nos aparecen al ejecutar el comando ESXTOP en un esxi, en el apartado de MEMORIA.

Ballooning es un técnica que tiene vmware para tratar en todo momento de tener la memoria necesaria tanto para el host como para las máquinas virtuales, yo le llamo “técnica de soliradidad” , ya que se hace una compartición de memoria cuando hace falta, ventaja importantísima frente a un sistema físico, en donde no tenemos mas remedio que conformarnos con la memoria que tenemos.

En un entorno virtual en donde hay muchas máquinas, no en todo momento se está utilizando todo lo asignado a las máquinas, por eso, lo que no se esté  utilizando , el sistema lo aprovecha para darselo al que le hace falta.

Veamos la siguiente imagen:

MCTLMAX

MCTLMAX

En esta columna veremos una cantidad fija, esta cantidad es la “memoria máxima” que el vmkernel puede reclamar, por defecto es el 65%, aunque puede aumentarse via configuración.

Si hacemos el cálculo, esa cantidad la coje de realizar el 65% de la memoria asignada a la máquina virtual (10.335), es decir, la memoria que le hemos puesto a la máquina virtual, 10g. MEMSZ.

MCTLSZ

En la imagen superior y sobre la columna MCTLSZ , lo que vemos es la cantidad que “actualmente” está reclamada.

MCTLTGT

En la columna de al lado MCTLTGT, vemos la cantidad “que va a ser reclamada”, es decir, no confundamos con MCTLSZ que es la cantidad ya reclamada.

¿Que pasa si MCTLTGT es mayor que MCTLSZ , o si MCTLTGT es menor ?

MCTLTGT mayor = El balón se INFLA, por tanto………..= MAS MEMORIA PARA RECLAMAR.

MCTLTGT menor = El balon se DESINFLA, por tanto….= no hace falta reclamar mas

Entendiendo mejor el proceso

Supongamos que el esxi (host) no tiene suficiente memoria física y hay alguna máquina que necesita mas memoria.

Veamos esta imagen:

infalado 1

Hay una máquina que no está utilizando toda su memoria, por tanto partimos de que el globo está desinflado, pero como tiene libre se infla.

baloning 2

El hypervisor sabe que hay memoria libre en esa máquina , y aporta esa RAM a otro máquina que la necesite. Por tanto la maquina virtual lo que hace es darle la memoria al host para que la utilize.

desinflado

Una vez que hay mas memoria fisica disponible, se desinflaran los globos de las máquinas, ya que no es necesario.

Las tools

Todo este proceso no ocurre si no tenemos instaladas las tools, por tanto hay que asegurarse de instalarlas, e incluso con las tools instaladas no nos garantizamos que hayamos marcado la opción del driver de ballooning, si seleccionamos “instalacion completa” de las tools, garantizamos que el driver esté.

MCTL interrogante

Una manera de saber si está o no el driver instalado en las máquinas virtuales, es fijarnos en la columna de MCTL?, ahí pondrá Y si está y N si no está.

Es una buena funcionalidad, pero es uso prolongado puede indicar problemas, ya que el sistema tiene un trabajo extra, debemos analizar estos contadores y tenerlos controlados para tomar la decisión de ajustar la memoria necesaria en las máquinas, o aumentar la ram fisica de los host. Asimismo podriamos utilizar reservas para asegurar ram en nuestras máquinas críticas, no obstante también con un control, ya que perderemos failover en el cluster de HA.

Como consejo, observar estos valores, un uso continuado de ballooning puede llevar a otros problemas con swaping y latencias altas, que, por supuesto podremos ver en otros contadores que nos da esxtop.

Un saludo.

 

 

 

 

AppVolumes despliegue

AppVolumes despliegue

¿Qué es appvolumes?

Nos va a permitir desplegar rápidamente o actualizar aplicaciones en entornos de escritorios virtuales vdi y aplicaciones publicadas.

Todo muy rápido en segundos, prácticamente instantáneo al usuario se le presentan las aplicaciones para empezar a trabajar con ellas.

Las aplicaciones se almacenan en discos virtuales de solo lectura, que pulsando en asignación se asignan a usuarios o grupos de usuarios, o a servidores de aplicaciones.

Para que nos hagamos una idea es algo parecido al despliegue de “thinapps” con Citrix, en donde se instala una aplicación en un disco virtual y luego se presenta ese disco (se queda asociado en la máquina virtual).

Configuración de AppVolumes

Podemos descargarlo en la parte de la suite de Horizon View. Una vez descargado ejecutamos el instalador, y debemos primeramente configurar e instalar el  “manager”,  nos aparece lo siguiente:

2

Pulsando en Get Started vamos a seguir un asistente rellenando lo necesario para realizar la configuración el manager.

3

Lo primero es “registrarse con el dominio”, para ello como vemos en la imagen superior, introducimos los datos de nombre de dominio, ip del dc, usuarios, password, en security pulsamos en el desplegable y seleccionamos LDAP normal (insecure), o sino configuramos Secure LDAP. En port lo podemos dejar en blanco. Seguidamente pulsamos en “register”.

4.1

Una vez registrado ya vemos nuestro dominio, el nombre netbios y la columna del tipo de seguridad LDAP.

Después definimos los grupos de directorio activo responsables de administrar App Volumes Manager.

Definimos por ejemplo al administrador del dominio.

5

Una vez que hemos seleccionado el grupo , nos aparece asi como vemos mas abajo:

6

 

En la siguiente pantalla tenemos que configurar el registro con el servidor VCENTER, y un par de apartado “mount local” y “mount on host”. Adjunto pantallazo con explicación:

7

El siguiente apartado consistirá en la configuración de las “rutas” donde se almacenaran los “AppStacks” y “writable volumes”. Nosotros lo que tenemos que hacer es seleccionar que datastores para cada cosa.

9

Lo siguiente será la importacion de estos volúmenes, se puede realizar en background o inmediatamente:

10

Ya con los datastores seleccionados y reconocidos por el manager, lo que debemos hacer es seleccionar un host del desplegable con sus credenciales para poder crear un directorio con las plantillas y con un apartado para los volumenes writables.

11

NOTA: (Recordemos marcar los check, ya que sino cuando tengamos que desplegar una appstack no vamos a poder , debido a que no hay plantillas).

Una vez que damos a “upload”, ya nos aparecerá la pantalla para importar los volumenes y plantillas.

12

Después vamos a encontrarnos una serie de opciones avanzadas, que de momento no hace falta cambiar.

13

Vamos a ver en nuestro datastore seleccionado, la infraestructura de carpetas que se ha creado durante la importación de las plantilla y lo que será el apartado para los volumenes writables:

13-1

Creación de una AppStack

A partir de este momento ya podemos crear una aplicacion appstack, para ello vamos a tener bien definido en la interface mediante pestañas, “appstacks”, “writables”, “assignments”, “applications…”.

Al dar a crear, le ponemos un nombre, seleccionamos el storage, y ya podemos ver el path , asi como la plantilla que vamos a utilizar (es un disco de un determinado tamaño).

14

Después confirmamos la creación de la appstack, en la imagen hemos desplegado una aplicación de winrar.

15

Después en la pestaña de “appstacks”, podemos ver en la esquina superior derecha los botones, para CREAR una nueva, IMPORT, para importar alguna , o hacer un rescan.

Mas abajo tenemos el status (en la imagen está sin aprovisionar), fecha de creación , nos explica lo que tenemos que hacer (aprovisionar), por tanto lo siguiente será aprovisiónar de esa aplicación a alguien.

16

 

Siempre que se esté haciendo algo, es decir, haya alguna tarea en proceso, podemos verla en la parte de “pending actions”:

17

Ahora tenemos que seleccionar el equipo APROVISIONADOR, es decir, una máquina que tenemos dedicada a instalar la aplicación que después será aprovisionada a los usuarios concretos o grupos que la necesiten.

Esa máquina tiene que tener el AGENTE instalado, por tanto debemos instalarselo antes para poder encontrarlo, sino no nos aparecerá en la siguiente imagen:

NOTA: Cuidado con los puertos, no tendremos una buena conexion de la máquina con el agente con el manager si hemos cambiado el puerto. Podemos por defecto el 80 en lugar del 443.

 

18

19

Instalación de la aplicación

En la máquina destinada a instalar la aplicación, deberemos instalar la aplicación siguiendo los pasos.

20

En la máquina destinada a instalar la aplicación, cuando le hemos dado a aprovisionar, y a start provisioning, el sistema lo que hace es “asociar un disco” a la máquina virtual para que en ese disco se almacene la instalación que vamos a realizar.

21

Nos va a salir la siguiente pantalla en la máquina destinada a instalar aplicaciones, nos está diciendo que instalemos la aplicacion Y LUEGO, le demos a a ok.

22

23

24

Leemos lo que pone y llegará el momento de reiniciar, y donde ya nos diga que la aplicación la tenemos correctamente aprovisionada:

25

Muestro una imagen en donde se ve en el datastore el disco que se asocia , y el tamaño que tiene aprovisionado y el tamaño real al instalarse el winrar.:

26

Asignación a los usuarios o grupos de usuarios

Es muy sencillo, sólo tenemos que buscar el grupo de usuarios o  usuario individual al que queremos asignar la aplicación.

28

Creación de Volumenes Writables

Ahora desde la pestaña Writables procedemos a crear los volumenes writables.

30

 

Especificamos quíen tiene permiso para crear el volumen:

31

32

¿Quien tiene asignado que?

En la siguiente imagen y desde la pestaña “ASSIGNMENTS”, vemos quienes tienen asignado qué appstack.

33

Cuando creamos el volumen writable, debemos seleccionar el datastore donde están las plantillas.

 

34

35

36

 

Si exploramos el almacen de datos para observar el volumen writable, vemos que se han creado varios discos de tamaño idéntico.

37

Attachments

En la pestaña “attachments”, podemos encontrar en la columna “volume”, el nombre de la aplicación asignada y en qué datastore está el fichero, es decir, son los discos que se asocian a la máquina virtual que va a necesitar tener la aplicación disponible.

38

 

La instalación del agente

La instalación del agente en la máquina virtual cuya  misión es la de instalar aplicaciones, es trivial, lo único que debemos tener en cuenta es “el puerto”, por defecto es el 443, pero podemos cambiarlo al 80.

Debemos tener cuidado y hacerlo cuadrar con el puerto que está especificado en el manager.

error del agente con conexion al appmanager 2

Y aqui el error que dará si en el puerto tenemos algún tipo de problema:

error del agente con conexion al appmanager

1

Esto es todo,  de esta manera podemos asignar aplicaciones muy rápidamente a nuestros usuarios , van a tener la aplicación casi de forma instantánea (y sin necesidad de cerrar la sesión o reiniciar), todo ello se gestiona como hemos visto pulsando en el icono de App Volumes Manager.