Blog Virtualizacion

Configuración básica VMware Horizon 7

El otro día montamos el laboratorio básico para empezar a trabajar con VMware Horizon 7, hoy os quiero mostrar como hacer una configuración rápida de todo lo necesario para poder empezar a trabajar.

De momento sólo teníamos el Connection Server y habíamos configurado el vCenter:

Siguiente paso que deberemos realizar.

Definir Pairing Password

Necesitaremos configurar la contraseña para configurar nuestros Security Servers:

Introducimos la contraseña dos veces:

Instalación Security Server

Como podéis apreciar no hay ninguno instalado, como ya hablamos en anteriores entradas usaremos HORIZON 2:

Como vimos anteriormente, se utiliza el mismo ejecutable que para instalar el Connection Server.

Introducimos la IP del Connection Server:

Introducimos una contraseña para Pairing Password:

Nos dará los valores predefinidos para el Security Server:

Si tenemos claro que sólo va a ser Security Server, podemos configurar automáticamente el firewall de Windows:

Comienza el proceso de instalación:

Una vez terminado y arrancados los servicios podremos comprobar que se ha agregado correctamente:

Revisamos en consola:

Si vamos a la URL anteriormente mostrada en la instalación tendremos un nuevo portal, que será el de acceso de los clientes:

Si pulsamos sobre VMware Horizon HTML Access veremos que hay acceso HTML:

En este punto a un no hemos definido ni aplicaciones ni escritorios con los que trabajar.

Instalar View Composer Horizon 7

Ahora vamos a instalar el View Composer en el vCenter. Yo utilizaré el W2012 de HORIZON 3:

Lanzamos la ejecución (necesario .NET 3.5, que podéis añadir como Feature):

Aceptamos las condiciones:

Lo dejamos por defecto:

He usado SQL Express 2017

Crear Granja en Horizon 7

Ahora vamos a crear nuestra primera granja. Vamos a la sección en la consola del Connection Server:

Vamos a elegir Automated Farm:

El vCenter que tenemos definido, en este caso:

Le damos un nombre:

Ahora configuramos como se llamarán las máquinas generadas:

Pulsamos Next:

Seleccionamos cada apartado:

Pulsamos Next:

Instalar RDS en Windows Server 2016

Deberemos tener una máquina Windows Server 2016 (no funciona con W2012 en Horizon 7) con el ROLE de Remote Desktop Services:

Con el role añadido de Remote Desktop Session Host:

Dar permisos a usuarios en aplicaciones/escritorio en VMware Horizon 7

Podemos definir los usuarios que tendrán acceso a los recursos compartidos, ya sean Escritorios o Aplicaciones:

Elegís un usuario o grupo predefinido en directorio activo:

La entrada Configuración básica VMware Horizon 7 aparece primero en VMware Blog.

Modificar Scratch Location en VMware 6.5

Hoy me he encontrado con un error al intentar desmontar un storage que ya había liberado de máquinas virtuales y que quería pasar a VMFS 6. El vCenter se encontraba en la versión 6.5U1. Disponía de otro storage donde mover las máquinas.

En el momento de intentar desmontar el storage para poder eliminarlo me encuentro con el siguiente error (este es uno de los problemas que os podéis encontrar, no la única razón):

“Datastore Name xxxx VMFS uuid xxxxxx está en uso. No se puede desmontar el volumen….”

Esto se debe a que realmente residen ficheros de un ESXi que se están utilizando. Habrá que modificarlos para que apunten a la nueva ubicación. Los pasos que tenemos tenemos que seguir son estos:

Nos conectamos vía web al host ESXi
Pulsamos en Almacenamiento

Seleccionamos un storage donde que queramos cambiar el fichero y hacemos un Browser
Creamos un directorio que identifique el ESXi:

.locker-NombreESXi

Cerramos el explorador

Ahora pulsamos en Administrar –> Sistema –> Configuración avanzada

Buscamos ScratchConfig.CurrentScratchLocation y vemos donde está ahora actualmente.
La forma más sencilla de saber qué UUID o ruta debemos introducir, es pulsar sobre el storage:

Editamos el valor y lo cambiamos con /vmfs/volumes/DatastoreUUID/.locker-NombreESXi
Reinicia el host y ya no tendremos esos errores

La entrada Modificar Scratch Location en VMware 6.5 aparece primero en VMware Blog.

Vembu BRD backup para VMware

Hoy os quiero presentar un software multiplataforma que podremos usar para realizar copias de seguridad tanto en VMware, Hyper-V y en Workstation por ejemplo.

El proceso de instalación es bastante fácil. Podremos usar un datastore local o de red. La gestión es web y dispone de un postgrepsql por debajo.

La instalación se realiza mediante un EXE en un sistema Windows para la versión Vembu BRD.

Ejecutamos y pulsamos Siguiente:

Aceptamos la licencia:

Ahora podemos customizar el Storage y el usuario por defecto que es admin / admin. El puerto es 6060, tendremos que abrir la comunicación por el puerto 32004 :

Esperamos a que termine la instalación:

Pulsamos Finish

Arrancará el servidor:

Introducimos el usuario y ya tenemos la gestión. El primer paso es la hora:

Ahora introducimos un nombre. El del servidor de backup valdrá:

Pulsamos sobre VMware vSphere:

Introducimos los datos del vCenter:

Pulsamos en BACKUP:

Pulsamos sobre los ESXi o las máquinas virtuales que nos interesa:

Podemos Opcionalmente truncar logs:

Pulsamos sobre la programación:

Podemos configurar repositorios:

Le damos un nombre y pulsamos Save the backup

Existen opciones dentro de la aplicación de recovery, reports, diferentes menús de administración…que intentaremos mostrarlos para comprobar la aplicación.

La entrada Vembu BRD backup para VMware aparece primero en VMware Blog.

Instalación DataCore SANsymphony en VMware

Final de año, y vamos a hacer una entrada sobre un producto que es probable me toque pelearme continuamente en mi día a día, se trata de DataCore SANsymphony.

DataCore es una solución de almacenamiento que proporciona un alto rendimiento con unos costes ajustados.

Dispone de dos componentes, por una parte del Server y por otra Datacore Management Console (la interfaz de gestión)
Se instala sobre un servidor Windows 2012, 2012R2 o 2016
Utiliza los discos locales de nuestros ESXis para dar una solución de hiperconvergencia
El punto fuerte de una solución Datacore sobre otras es el rendimiento en IOPS (entrada/salida) sobre otras soluciones. Esto lo podéis comprobar Storage Performance que han analizado varias soluciones.

La idea principal es eliminar las cabinas de almacenamiento tradicionales, mejorar su rendimiento y abaratar costes.

Requisitos mínimos DataCore SANsymphony

Podéis revisar los requerimientos desde el siguiente enlace:

https://www.datacore.com/products/technical-information/sansymphony-prerequisites

Instalando laboratorio Datacore SANsymphony

Como en casi todas las entradas utilizaré mi laboratorio con mis Microserver HP Gen8 de 16GB de RAM. Para generar las máquinas y jugar con datacore no usaremos la Synology, sino que usaremos, por el propio concepto de datacore de los discos locales de 1TB que dispone cada servidor (dispongo también de 2 SSD que creo también me darán juego, pero esto ya para próximas entradas).

He tenido que desmontarlos y liberarlos para utilizarlos con Datacore. Para hacerlo más cómodo, genero las aplicaciones en los discos de 120GB SSD locales y el storage local de 1TB para crear la futura LUN.

Lo comentado, quito todas las dependencias del datastore, desmonto y elimino, para volver a generarlos:

Generamos dos máquinas Windows con los requisitos que hemos marcado anteriormente y copiamos el ejecutable de la instalación. Lanzamos el instalable en uno de los nodos.

La instalación verificará los requisitos cuando termine pulsamos Finish:

Dispondremos de un acceso directo al Wizard en el escritorio del servidor que abriremos. Pulsamos sobre SANSymphony y Next:

Ahora vamos a instalar High-Availabily Pairs, seleccionamos y pulsamos Next:

Pulsamos en New High-Availability Pair y Next:

Pulsamos Next:

Pulsamos Next si las verificaciones automáticas no dicen lo contrario:

Pulsamos Next:

Me toca agregar 3 tarjetas de red que no lo he hecho en la instalación (lo hago en caliente) y hacemos Re-run. Luego Next:

Ahora configuraremos las interfaces de red. Pulsamos Next:

Pulsamos Next:

Colocamos una IP estática para Ethernet 0, 1 y 2:

Pulsamos Next:

Empieza el proceso. Al terminar pulsamos Next:

Aceptamos los términos y pulsamos Next:

Introducimos contraseña y pulsamos Next:

Ahora vamos a configurar el segundo nodo. Yo he metido los nombres en el fichero hosts, pero lo ideal es que estén en dominio:

Comienza el proceso (hay que eliminar el Firewall de Windows de la ecuación o abrir puertos para no tener problemas):

Pulsamos Next :

Pulsamos Next:

Configuraremos como en el nodo 1 los 3 interfaces:

Pulsamos Next:

Nos advierte que se generarán un nuevo Server Group:

Pulsamos Next lo dejamos por defect:

Nos dará un resumen:

Yo he tenido que añadir un pequeño disco a cada host porque es requisito para la instalación tener discos sin formato (quería mostrar como montar el disco de la LUN a posteriori por no extenderme más con ésta), aunque luego usaré los de 1TB para generar la LUN y pulsamos Re-Run:

Al terminar el equipo donde hemos lanzado la instalación DATACORE1, en este caso, se reinicia:

Con esto ya tendríamos la instalación, abrimos la consola, y como se me ha pasado necesitamos instalar Microsoft Visual C++ 2015 que descargamos e instalamos:

https://www.microsoft.com/es-ES/download/details.aspx?id=48145

En próximas entradas os enseñamos a configurar la consola:

** NOTA **: A mí el nodo 2 no se ha instalado (entiendo que lo debía haber hecho), así que he tenido que lanzar el Wizard en él y añadirlo al Server Group

La entrada Instalación DataCore en VMware aparece primero en VMware Blog.

Actualizar VMware ESXi a 6.5

Hoy os quiero explicar como actualizar VMware ESXi a la versión 6.5.

Lo primero que debemos hacer es bajar de MyVmware la última versión del Hypervisor ESXi (los HP Gen8 Microserver no son compatibles con 6.5, hay que bajar una personalizada) y cargarla en nuestro datacenter.

Vamos a la consola web Menú –> Update Manager –> Importar imagen ESXi:

Subimos la imagen:

Ahora nos colocamos sobre ella y creamos una línea base:

Le damos un nombre significativo:

Vamos a la vista Hosts y pulsamos sobre el que queremos actualizar. En la pestaña Update Manager –> Asociar línea base

Seleccionamos:

Ahora pulsamos Corregir:

Upgrade Baseline –> Siguiente:

Seleccionamos el host:

Aceptamos:

Dejamos que Apague las máquinas en el proceso:

Y con esto comenzaría el proceso de actualización si no lo hemos programado en pasos anteriores:

La entrada Actualizar VMware ESXi a 6.5 aparece primero en VMware Blog.

Configuración Datacore SANSymphony con VMware

Seguimos con las configuraciones que nos vamos a encontrar en un Datacore utilizando como base VMware.

Queremos explicaros los paso a paso que hay que dar para realizar una instalación funcional de Datacore SANSymphony en VMware, este caso versión 6.5

Partimos de la anterior entrada, donde ya teníamos los datacore instalados:

Instalación DataCore en VMware

Como ya habíamos comentado anteriormente, queremos realizar una LUN en modo Mirroring donde el hardware son dos discos de 1TB instalados cada uno en un host ESXi.

Habría que seguir los checks que nos marca la pestaña GETTING STARTED y completarlos.

Añadir PATH del ESXi a los DATACORE Servers

Hemos añadido tres tarjetas así que nos debemos asegurar que existen las rutas a los datacores desde cada esxi. Normalmente si va bien la instalación se autogeneran, pero sino hay que añadirlos. Esto se hace seleccionando el ESXi desde la consola de vCenter –> pestaña Configurar –> Almacenamiento –> Adaptadores de almacenamiento –> iSCSI Software Adapter –> pestaña Destinos –> Detección dinámica –> Agregar

Después de agregar pulsamos un refresco para que vuelva revisar los enlaces:

Añadir DATACORE Server a Server Group

En un primer momento dispondremos de un solo servidor de Datacore. Para añadir un segundo nodo pulsamos en la sección Datacore Servers con el botón derecho –> Add Datacore Server:

Simplemente introducimos el nombre o IP del Datacore y pulsamos Add, en unos segundos lo tendremos añadido:

Registrar un nuevo usuario

Una buena práctica, si van a existir diferentes perfiles en la organización, es agregar un usuario que no tenga Full Privileges. Desde Home –> Users o Getting Started –> Register User

Pulsamos Register User y le damos un nombre, al cual podremos unir un Virtual Disk:

Registrar vCenter en DATACORE

En la sección Hosts pulsamos botón derecho y pulsamos Register VMware Center:

Ahora introducimos las credenciales:

Y nos mostrará las máquinas virtuales y ESXi:

Registrar Host ESXi en DATACORE

Otra forma a parte del vCenter es registrar los hosts esxi. Mismos pasos que antes pero pulsamos Register Host:

Ahora introducimos las credenciales y listo:

Creo que me quedaré con esta opción porque es más clara la vista.

Crear Disk Pool en DATACORE

Uno de los primeros pasos es crear un Disk Pool. Lo generaremos desde el datacore –> Disk Pool –> Create Disk Pool:

Cambiaremos los valores como en la imagen, aunque yo lo dejo por defecto a 128MB porque es una prueba (el Sector size si es posible pondríamos 4k, pero si no tenemos nuestra plataforma en VMware 6.5 dejarlo en 512B)

Hay que crear al menos un pool disk.

Crear Virtual Disk en DATACORE

Una vez que tenemos el Pool, crearemos un Virtual Disk. En Getting Started –> Create virtual disks

Le damos el tamaño y el nombre (lo haremos de momento en modo Single, en otra entrada haremos un Mirrored), pulsamos Next:

Pulsamos Next

Pulsamos Finish:

Ahora tenemos que darle acceso a los servidores, así que desde Virtual Disks de sección Hosts del Datacore1 :

Pulsamos Next:

Elegimos Round Robin y Create VMFS datastore:

Crear Disk Group DATACORE

Para generar un Disk Group nos colocamos en el virtual disk –> botón derecho Create Group:

Serve Virtual Disks to Hosts DATACORE

Seguimos con los pasos y vamos a añadir un Virtual Disk a un Host concreto.

Elegimos el Datacore:

Elegimos el Virtual Disk:

Pulsamos Finish para que elija automáticamente:

Arrancar parar servicio de DATACORE

Por si lo necesitáis, para parar o arrancar el servicio de Datacore vais a la sección Datacore Server Actions y podéis hacerlo desde el menú:

La entrada Configuración Datacore con VMware aparece primero en VMware Blog.

Instalar Openshift, Kubernetes y Dockers en VMware Workstation

Os explicamos como generar un laboratorio de Openshift, Kubernetes y Dockers sobre Centos 7 y VMware Workstation. La idea es que una vez montado, ser capaz de levantar un servicio simple, como un WordPress con una base de datos MariaDB.

Antes de nada, explicaremos qué es Openshift y Kubernetes, ya que de Dockers ya hemos hablado alguna vez. Creo que esta imagen define muy bien lo que es cada cosa, pero vamos a las definiciones más genéricas ya que queremos realizar un manual de instalación:

¿Qué son Openshift y Kubernetes?

Desarrollado por RedHat con tecnología OpenSource, es una de las soluciones PAAS más importantes del mercado. Utiliza tanto Dockers como Kubernetes, actuando Openshift como integrador.

Kubernetes es la solución de orquestación que utiliza Openshift, un poderoso sistema de administración y desarrollo de clústeres de contenedores.

Si vais a la página oficial podréis curiosar de una forma gratuita con Openshift.

La evolución de la tecnología de contenedores sobre una infraestructura tradicional o virtual:

Instalación Openshift en Centos 7 sobre VMware Workstation

Esta vez no voy a utilizar mi laboratorio tradicional, sino que lo voy a crear sobre mi portátil MSI con 48GB de RAM e procesador i7.

A continuación, os coloco los requerimientos mínimos, así que no me queda otra que hacerlo así porque mis servidores no tienen más de 16GB cada uno:

Generaremos 3 máquinas Centos 7, una para el Master y dos Nodos.

Pasos previos a realizar en todos los nodos salvo que se indique:

Deshabilitamos Selinux
- vi /etc/selinux/config
- Dejamos el valor SELINUX en Disabled y Targeted
Deshabilitamos Iptables
- systemctl disable firewalld
- systemctl stop firewalld
Lanzamos la instalación de los paquetes necesarios
- yum install centos-release-openshift-origin
- yum install wget git net-tools bind-utils iptables-services bridge-utils bash-completion origin-clients docker pyOpenSSL
Modificamos el fichero /etc/hosts (sino tendréis que instalar BIND)
- - Añadimos las IPs y nombres de los hosts. En mi caso:
    - 192.168.28.133 node2 node2.openshift.maquinasvirtuales.eu
    - 192.168.28.132 node1 node1.openshift.maquinasvirtuales.eu
    - 192.168.28.134 master master.openshift.maquinasvirtuales.eu
Editamos el fichero en todos los nodos vi /etc/sysconfig/docker:
- OPTIONS=’ –selinux-enabled –log-driver=json-file –log-opt max-size=50m’
Sólo en el master lanzamos esto:
- yum install -y origin-master origin-pod origin-sdn-ovs origin-dockerregistry
Sólo en el master. Editamos el fichero vi /etc/origin/master/master-config.yaml:
- - corsAllowedOrigins:
    – //127\.0\.0\.1(:|$)
    – //192\.168\.28\.134:8443$
    – //localhost(:|$)
    – kubernetes.default
    – kubernetes.default.svc.cluster.local
    – kubernetes
    – openshift.default
    – openshift.default.svc
    – 172.30.0.1
    – openshift.default.svc.cluster.local
    – kubernetes.default.svc
    – openshift
  - Agregamos schedulerConfigFile: “/etc/origin/master/scheduler.json”
  - Agregamos networkPluginName: “redhat/openshift-ovs-multitenant”
  - Agregamos routingConfig: subdomain: openshift.maquinasvirtuales.eu
Creamos fichero sólo en el master con vi /etc/origin/master/scheduler.json
- {
  “apiVersion”: “v1”,
  “kind”: “Policy”,
  “predicates”: [
  {
  “name”: “MatchNodeSelector”
  },
  {
  “name”: “PodFitsResources”
  },
  {
  “name”: “PodFitsPorts”
  },
  {
  “name”: “NoDiskConflict”
  },
  {
  “name”: “NoVolumeZoneConflict”
  },
  {
  “name”: “MaxEBSVolumeCount”
  },
  {
  “name”: “MaxGCEPDVolumeCount”
  },
  {
  “argument”: {
  “serviceAffinity”: {
  “labels”: [
  “region”
  ] }
  },
  “name”: “Region”
  }
  ],
  “priorities”: [
  {
  “name”: “LeastRequestedPriority”,
  “weight”: 1
  },
  {
  “name”: “SelectorSpreadPriority”,
  “weight”: 1
  },
  {
  “argument”: {
  “serviceAntiAffinity”: {
  “label”: “zone”
  }
  },
  “name”: “Zone”,
  “weight”: 2
  }
  ] }
Arrancamos el servicio del master:
- systemctl enable origin-master
- systemctl start origin-master
Generamos en el master el fichero config:
- mkdir .kube
- ln -s /etc/origin/master/admin.kubeconfig .kube/config
- Comprobamos:
  - [root@master ~]# oc login -u system:admin
    Logged into “https://192.168.28.134:8443” as “system:admin” using existing credentials.You have access to the following projects and can switch between them with ‘oc project <projectname>’:* default
    kube-public
    kube-system
    openshift
    openshift-infra
    openshift-nodeUsing project “default”.
Instalamos sólo en los nodos:
- yum install -y origin-node origin-pod origin-sdn-ovs origin-dockerregistry
Creamos en el master los directorios y el enlace simbólico:
- mkdir /etc/origin/node1.openshift.maquinasvirtuales.eu
- mkdir /etc/origin/node2.openshift.maquinasvirtuales.eu
- ln -s /etc/origin/ openshift.local.config
- Lanzamos los comandos:
  - oc adm create-node-config –node-dir=’/etc/origin/node2.openshift.maquinasvirtuales.eu/’ –dns-domain=’openshift.maquinasvirtuales.eu’ –dns-ip=’192.168.28.134′ –hostnames=’node2.openshift.maquinasvirtuales.eu’ –master=’https://192.168.28.134:8443′ –network-plugin=’redhat/openshift-ovs-multitenant’ –node=’node2.openshift.maquinasvirtuales.eu’
    Generating node credentials …
    Created node config for node2.openshift.maquinasvirtuales.eu in /etc/origin/node2.openshift.maquinasvirtuales.eu/
  - oc adm create-node-config –node-dir=’/etc/origin/node1.openshift.maquinasvirtuales.eu/’ –dns-domain=’openshift.maquinasvirtuales.eu’ –dns-ip=’192.168.28.134′ –hostnames=’node1.openshift.maquinasvirtuales.eu’ –master=’https://192.168.28.134:8443′ –network-plugin=’redhat/openshift-ovs-multitenant’ –node=’node1.openshift.maquinasvirtuales.eu’
    Generating node credentials …
    Created node config for node1.openshift.maquinasvirtuales.eu in /etc/origin/node1.openshift.maquinasvirtuales.eu/
- scp /etc/origin/node1.openshift.maquinasvirtuales.eu/* root@192.168.28.132:/etc/origin/node/
- scp /etc/origin/node2.openshift.maquinasvirtuales.eu/* root@192.168.28.133:/etc/origin/node/
Ahora en los nodos vi /etc/origin/node/node-config.yaml
- kubeletArguments:
  node-labels:
  – region=primary
  – zone=west
Arrancamos servicios en los nodos:
- systemctl enable docker
- systemctl start docker
- systemctl enable origin-node
- systemctl start origin-node
Descargamos en los nodos las imágenes de los dockers que necesitamos:
- docker pull openshift/origin-sti-builder
- docker pull openshift/origin-deployer
- docker pull openshift/origin-docker-registry
- docker pull openshift/origin-haproxy-router
- docker pull openshift/origin-pod
En el master creamos una cuenta de servicio:
- oc create serviceaccount registry -n default
- oadm policy add-scc-to-user privileged system:serviceaccount:default:registry
- oadm registry –service-account=registry –mount-host=/opt/openshift-registry (ignorar el error)
- oc create route passthrough –service docker-registry -n default
- [root@master ~]# oc get svc
  NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  docker-registry 172.30.135.46 <none> 5000/TCP 1m
  kubernetes 172.30.0.1 <none> 443/TCP,53/UDP,53/TCP 42m
- [root@master ~]# oc get route
  NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
  docker-registry docker-registry-default.openshift.maquinasvirtuales.eu docker-registry 5000-tcp passthrough None
- oc adm ca create-server-cert –signer-cert=/etc/origin/master/ca.crt –signer-key=/etc/origin/master/ca.key –signer-serial=/etc/origin/master/ca.serial.txt –hostnames=”172.30.135.46,docker-registry-default.openshift.maquinasvirtuales.eu” –cert=/etc/origin/master/registry.crt –key=/etc/origin/master/registry.key
- oc secrets new registry-certificates /etc/origin/master/registry.crt /etc/origin/master/registry.key -n default
- oc secrets add registry registry-certificates -n default
- oc secrets add registry registry-certificates -n default
- oc env dc/docker-registry REGISTRY_HTTP_TLS_CERTIFICATE=/etc/secrets/registry.crt REGISTRY_HTTP_TLS_KEY=/etc/secrets/registry.key -n default
- oc patch dc/docker-registry –api-version=v1 -p ‘{“spec”:{“template”:{“spec”:{“containers”:[{“name”:”registry”,”livenessProbe”:{“httpGet”:{“scheme”:”HTTPS”}}}]}}}}’ -n default
- oc patch dc/docker-registry –api-version=v1 -p ‘{“spec”:{“template”:{“spec”:{“containers”:[{“name”:”registry”,”readinessProbe”:{“httpGet”:{“scheme”:”HTTPS”}}}]}}}}’ -n default
- oc volume dc/docker-registry –add –type=secret –secret-name=registry-certificates -m /etc/secrets -n default
- oc create serviceaccount router -n default
- oadm policy add-scc-to-user hostnetwork system:serviceaccount:default:router
- oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:default:router
- oadm router router –replicas=1 –service-account=router
Bajamos algunos stream y los copiamos en la carpeta, y los cargamos:

for f in image-streams/image-streams-centos7.json; do cat $f | oc create -n openshift -f -; done
for f in db-templates/*.json; do cat $f | oc create -n openshift -f -; done
for f in quickstart-templates/*.json; do cat $f | oc create -n openshift -f -; done

Comprobamos en el master que todo funciona:
- [root@master ~]# oc get po -o wide
  NAME READY STATUS RESTARTS AGE IP NODE
  docker-registry-1-77m5m 1/1 Running 0 13m 10.128.0.2 node1.openshift.maquinasvirtuales.eu
  docker-registry-3-deploy 1/1 Running 0 4m 10.129.0.5 node2.openshift.maquinasvirtuales.eu
  docker-registry-3-g4qk9 0/1 Running 6 4m 10.129.0.6 node2.openshift.maquinasvirtuales.eu
  router-1-8g2nr 1/1 Running 0 2m 192.168.28.132 node1.openshift.maquinasvirtuales.eu
Podemos entrar en la gestión web mediante la URL https://IP_MASTER:8443:

Yo me logueo con root del master:

En otro momento utilizaremos Openshift y daremos unos cuantos comandos.

La entrada Instalar Openshift, Kubernetes y Dockers en VMware Workstation aparece primero en VMware Blog.

Instalar laboratorio Citrix XenApp 7.9 sobre VMware Workstation

Vuelvo a utilizar como en la anterior entrada sobre Openshift mi portátil MSI para realizar un laboratorio completo de otro tipo de Infraestructura. Hoy vamos a instalar Citrix XenApp en su versión 7.9. Así que empezaremos como cada siempre explicando en qué consiste el software que vamos a probar, qué hace, requerimientos que tiene y componentes (también explicaremos brevemente qué hace cada uno).

Objetivo, explicar la tecnología, su instalación y terminar con la publicación de una aplicación.

¿Qué es XenApp?

Así como VMware se podría decir que es la solución líder en virtualización en general, en mi opinión, Citrix XenApp es la solución más potente en la virtualización de aplicaciones, proporcionando aplicaciones Windows como servicios seguros. Al centralizar el control y la seguridad, TI puede movilizar la empresa a la vez que reduce los costos.

Componentes XenApp

Citrix XenApp está compuesto de varios componentes que se centran en diferentes funciones que ahora explicaremos:

Delivery Controller: Es el componente de administración principal de los sitios de XenApp o XenDesktop, en un entorno productivo debería existir más de uno. Está compuesto por varios servicios, que comunicándose con el hypervisor, se puedan realizar múltiples acciones (distribuir aplicaciones o escritorios, autenticar o administrar los accesos, optimizar la carga de las conexiones…).
Base de datos o Database: Se necesita como mínimo una base de datos SQL para almacenar sesiones y configuraciones.
Citrix Studio: Se trata de la consola de administración desde donde se pueden publicar y administrar tanto aplicaciones como escritorios.
Citrix Director: Si se quieren resolver problemas, necesitaréis analizar los datos que recoge este componente y actuar sobre las alertas de la plataforma. Es una consola web de monitorización de la infraestructura.
Servidor de Licencias o Citrix License Server: Creo que está claro, administra las licencias conectándose con el controller.
Citrix StoreFront: Autentica a los usuarios en los sitios. Se podría decir, como su propio nombre indica, que es el frontal web de las aplicaciones o escritorios. Como la tienda a la que accede un usuario para ver qué tiene publicado.
VDA o Virtual Delivery Agent: Se instala en cada máquina que se va a utilizar en la infraestructura para proporcionar aplicaciones o escritorios.
Citrix Receiver: Es el agente que se instala en los dispositivos de los usuarios para poder acceder a la ejecución de aplicaciones y escritorios.

Adicionalmente existen otros servicios o componentes que yo no voy a utilizar como Provisioning Service, NetScaler Gateway o Citrix CloudBridge.

Si queréis ver los requerimientos de máquina podéis hacerlo desde este ENLACE.

Instalación Citrix XenApp

Como vais a poder ver, voy a intentar simplificar al máximo. Creamos cuatro máquinas para nuestro laboratorio, ya que no va a ser un entorno Productivo, nos vale con esto:

NEGUDC1: Controlador de dominio que reutilizaré para otros laboratorios y que XenApp tiene dependencia.
CTX01: En una sola máquina Citrix Director y Studio, Delivery Controller, StoreFront, Database y License Server
CTX02: La dejaremos de momento en StandBy, pero nos servirá para replicar componentes en otros momentos del laboratorio.
CTXVDA01: VDA

Integraciones con Directorio Activo

Lo primero que haremos será generar el controlador de dominio si no lo tenemos, añadir los servidores al dominio y generar un grupo y usuarios para trabajar con ellos:

Generamos un grupo y un par de usuarios que metemos en dicho grupo, GPCITRIX y USERCITRIX01 – USERCITRIX02

Instalación Delivery Controller y otros componentes

Mapeamos en la máquina que llevará el role la ISO que deberemos haber descargado previamente de Citrix. Como podéis ver, desde la misma ISO disponemos la posibilidad de instalar también XenDesktop. Para esta entrada nos centraremos en XenApp, así que pulsamos Iniciar:

Pulsamos en Delivery Controller:

Decimos que SI:

Aceptamos las condiciones y pulsamos Siguiente:

Dejamos marcados todos los componentes:

Marcamos todo y Siguiente:

Como usaremos el FW de Windows dejamos en Automático:

Pulsamos Instalar:

La máquina pedirá reiniciarse:

El proceso tardará unos 30 minutos:

Aquí podéis elegir lo que queráis:

Pulsamos Finalizar:

Y arranca Citrix Studio. Pulsamos en Entregar aplicaciones y escritorios a los usuarios para configurar el Site nuevo:

Le damos un nombre y Siguiente:

Dejamos todo por defecto, pulsamos Siguiente:

Ahora introducimos las licencias si las tenemos, sino usaremos el periodo de gracia de 30 días temporalmente:

Como de momento no me interesa conectarme a un gestor de máquinas virtuales, ponemos Sin administración de máquinas:

Dejo de momento desmarcadas las dos casillas:

Pulsamos Finalizar:

Antes de agregar el servidor que va a publicar las aplicaciones, lo vamos a instalar:

Instalación Citrix VDA

Mapeamos otra vez la ISO pero en servidor para VDA, que en este caso se llama CTXVDA01

Elegimos la segunda opción, Habilitar conexiones con una máquina de servidor (no voy a usar vCenter ni otra plataforma de momento):

Pulsamos Siguiente:

Introducimos manualmente el DC, probamos y Agregamos:

Agregamos todo y pulsamos Siguiente:

Pulsamos Siguiente:

Pulsamos Instalar:

Esperamos a que termine, se reinicia en medio de la instalación:

Pulsamos Siguiente:

Pulsamos Finalizar y vuelve a Reiniciarse:

Crear catálogo de máquinas

Añadimos la máquina al catálogo desde el Citrix Studio:

Pulsamos Siguiente:

Elegimos SO de Servidor y pulsamos Siguiente:

Pulsamos Siguiente:

Agregamos el servidor VDA y siguiente:

Ponemos un nombre al catálogo y pulsamos Finalizar:

Ya tenemos el servidor en el catálogo:

Crear grupo de entrega

Añadimos un Grupo de entrega:

Pulsamos Siguiente:

Modificamos el valor a 1 y pulsamos Siguiente:

Agregamos nuestro grupo de DA creado al principio:

Como esto es un LAB vamos a agregar una aplicación como la Calculadora desde el menú Inicio:

De momento no me interesan los escritorios:

Damos un nombre al Grupo de Entrega y pulsamos Finalizar:

Acceso por Storefront

Ahora accederemos al portal web para ver si vemos la aplicación (http://ctx01.negu.local/Citrix/StoreWeb/). Pulsamos Detectar Receiver (deberemos tenerlo instalado previamente)

Ahora podemos descargarlo o decir que ya está instalado:

Ahora introducimos las credenciales de uno de los usuarios del grupo configurado:

Vamos a aplicaciones y veremos la aplicación publicada:

Bajará el fichero ICA y ya tenemos la aplicación corriendo en Citrix XenApp:

Podéis comprobar en Citrix Studio que existe la sesión:

Seguiremos en otras entradas…

La entrada Instalar laboratorio Citrix XenApp 7.9 aparece primero en VMware Blog.

Citrix Storefront no muestra aplicaciones publicadas

El otro día estuvimos montando una infraestructura XenApp 7 en VMware Workstation. Un problema que me ha dado el laboratorio es que en ciertos momentos, no siempre, las aplicaciones al entrar en Citrix Storefront no se me presentaban.

Apareciendo el siguiente mensaje “No hay aplicaciones ni escritorios disponibles para usted en este momento”:

Si os fijáis, a parte de las aplicaciones, no salen los menús que las acompañan:

Confieso que al principio creía que era por algún problema con los servicios del sistema, y esto teniendo todo en una máquina, no es difícil de comprobar. Aunque realmente se había convertido en un problema aleatorio. Así que revisando todas las configuraciones, que estaban sin cambiar desde que lo generé, encontré la solución. Abrimos Citrix Storefront:

Ahora nos colocamos en Almacenes –> seleccionamos el que tenemos –> pulsamos Administrar Delivery Controllers:

Pulsamos Modificar:

Modificamos el valor a HTTP 80 (salvo que vayáis a usar HTTPS)

Y con esto resolvemos el problema. Esto está escrito en el KB de Citrix:

https://support.citrix.com/article/CTX200583

La entrada Citrix Storefront no muestra aplicaciones publicadas aparece primero en VMware Blog.

Instalación WSUS en Windows 2016

Seguimos mejorando nuestro laboratorio con un servidor que nos permita centralizar nuestros parches para máquinas Windows. Lo haremos con WSUS, que es la forma más rápida y cómoda de hacerlo.

Antes de nada, vamos a ver qué requisitos necesitamos para montarlo.

Requerimientos mínimos WSUS de hardware y software

Los requisitos mínimos para instalar este rol y permitir que funcione de forma correcta son:

Espacio en disco duro de mínimo 10 GB.

Adaptador de red de mínimo 100 Mbps.

En cuanto a memoria lo recomendado es tener 2 GB más de las requeridas por el servidor.

Procesador x64 de 1.4 Ghz o mayor.

Propuesta de hardware y software

Máquina virtual Windows Server 2016 Standard
C: para sistema operativo de 50GB
D: para los DATOS (descarga de actualizaciones) de unos 100GB
4GB de RAM
4 vCPUs

Como “no todo es oro lo que reluce”, hay que tener claro que no estamos hablando de SCCM como producto sino de WSUS que trabaja con Windows Update, con lo que tiene sus limitaciones.

WSUS únicamente está destinado a la distribución de paquetes oficiales de Microsoft, por lo tanto, no se podrá emplear en la actualización de aplicaciones de terceros directamente (veremos que podemos hacerlo con otra aplicación) como puedan ser Java, Flash Player o incluso para la actualización de las bases de datos y firmas de virus de ningún antivirus. Tampoco permite el despliegue de ningún tipo de software, ni de terceros ni tampoco propio de Microsoft.

Instalación de WSUS en Windows 2016

En nuestra máquina virtual vamos a generar una unidad D: y dentro de ella una carpeta WSUS:

Añadimos el role “Windows Server Update Services”:

Pulsamos Next:

Marcamos “Active Directory Domain Services” y “DNS Server”. Pulsamos Next

Seleccionamos WID Connectivity (se encarga de instalar la base de datos de WID) y WSUS Services (gestiona los servicios de WSUS)

Dejaremos las descargas en D:\Datos\WSUS

Pulsamos Next

Dejamos los valores por defecto

Marcamos la casilla para que se reinicie si lo necesita y pulsamos Install y esperamos a que termine

Post-Instalación WSUS

Desde el Server Manager veremos una alerta que nos pide lanzar un proceso de Post-Instalación:

Pulsamos sobre “Launch Post-Installation tasks”

El proceso tarda un par de minutos

A continuación, explicamos el procedimiento de descarga del catálogo:

Abrimos “Windows Server Update Services Configuration”

Desmarcamos “Yes, I would…” y pulsamos Next

Marcamos “Synchronize from Microsoft Update”

No hay proxy de conexión así que lo dejamos sin rellenar

Lanzamos la conexión, este proceso tarda muchos minutos

Pulsamos Next

Marcamos English y Spanish, por si se instala software o SO en esos idiomas

En este momento elegimos centrarnos en los productos en los que vamos a dar soporte (W2012R2, W2016 y SQL Server 2014, por ejemplo), se puede cambiar más adelante

Dejaremos por defecto Critical Updates, Security Updates y Definition Updates

Aunque el cliente va a definir el proceso de actualizaciones de forma manual, dejaremos una sincronización automática del catálogo de parches en el servidor, para que el proceso de actualización sea más rápido

Lanzamos la primera sincronización al terminar de configurar

Podemos ver el proceso desde la consola

En otras entradas os enseñaré a lanzar las actualizaciones sobre las máquinas o como poder lanzar Java y otras aplicaciones con WSUS.

La entrada Instalación WSUS en Windows 2016 aparece primero en VMware Blog.

Crear Sysprep en VMware para Linux y Windows

Una forma de ahorrar tiempo y optimizar vuestras plantillas es utilizar el Administrador de especificaciones de personalización. ¿Por qué nos va a ahorrar tiempo y disgustos? Si os habéis peleado algo con sistemas operativos Windows, por ejemplo, normalmente van integrados en un directorio activo, llevan una licencia específica, se generan con un nombre concreto, etc.

Todo eso, son minutos de tu tiempo que puedes optimizar ya desde la generación de la máquina y olvidarte de un trabajo laborioso si vas a hacer muchas máquinas con la misma plantilla virtual.

Hoy os quiero mostrar como podemos realizar este trabajo, utilizando lo que nos dan los sistemas operativos, para Windows la herramienta Sysprep y para Linux lo haremos con lo que nos da Centos en mi caso.

Aunque lo podemos realizar directamente al generar la máquina desde plantilla, os lo enseño desde la consola. Abrimos nuestra consola de vcenter y nos vamos a Inicio –> Administrador de especificaciones de personalización:

Pulsamos el botón de Crear una nueva especificación:

Crear Sysprep Windows en VMware vCenter

Elegimos Windows, y como no tenemos un fichero personalizado le damos nombre y no marcamos la casilla:

Damos los datos que queremos que existan, ejemplo, de nuestra empresa:

Marcamos que se le de a Windows el nombre de la máquina virtual:

Si disponéis de licencias es el momento de colocarlas:

Introducir la contraseña de administrador y dejamos que arranque una vez automáticamente:

Elegimos zona horaria:

Ahora introducimos un comando para el primer arranque. Por ejemplo, que se actualice directamente al iniciar sesión:

Aquí podéis elegir la red. Yo esto lo dejo por defecto:

Ponemos una cuenta de dominio si queremos que se integre directamente:

Esta es la parte más importante con una plantilla Windows, que es generar un SID nuevo, para luego no tener problemas con directorio activo o las licencias:

Con esto ya tendríamos todo preparado:

Crear Sysprep Linux en VMware vCenter

Ahora intentaremos crear una personalización para máquina centos. Elegimos Linux en el asistente:

Dejamos que le ponga el nombre de la máquina virtual:

Elegimos zona horaria:

Ahora la red:

Los DNS:

Pulsamos Finalizar:

Ya veis que la parte Linux es muy limitada de momento.

La entrada Crear Sysprep en VMware para Linux y Windows aparece primero en VMware Blog.

Añadir VMware vCenter en Citrix XenDesktop

Seguimos con el laboratorio de Xendesktop, y vamos a enseñaros como realizar la conexión de la infraestructura Citrix con nuestro VMware vCenter para poder generar un pool de máquinas virtuales que nos permitan tener unos escritorios compartidos.

Lo primero que haré es generar una carpeta en el vCenter para el pool:

Ahora vamos a generar unos permisos de acceso siguiendo las pautas que marca Citrix. Podría hacer la conexión con el usuario administrador con todos los permisos, pero quiero hacerlo bien:

https://support.citrix.com/article/CTX214389

Creo una función nueva:

Vamos añadiendo permisos en los diferentes grupos:

Podéis crear un grupo y luego añadir un usuario de servicio para darle esos permisos:

Podéis hacerlo localmente o hacerlo con un usuario de dominio:

Agregáis el usuario al grupo:

Ahora simplemente le dais al usuario o grupo la función que habéis configurado:

Ahora vamos al servidor que tiene los roles y abrimos Citrix Studio –> Alojamiento –> Agregar conexión y recursos:

Introducimos los datos de nuestro vCenter:

Deberemos confiar en el certificado:

Es posible que no confíe en el certificado si la red no es la misma. Para ello tendríais que exportar el certificado en formato DER, llevarlo al DC, dar doble clic sobre él, importarlo como Local Machine a Trusted People.

Como nosotros no tenemos ese problemas proseguimos:

Seleccionamos las ubicaciones:

Damos un nombre y seleccionamos la red que nos interesa:

Pulsamos Finalizar:

Hay requisito de comunicaciones, el puerto 443 entre vCenter y DC

Con esto ya tendríamos la conexión preparada para crear escritorios

La entrada Añadir VMware vCenter en Citrix XenDesktop aparece primero en VMware Blog.

Instalar Java u otro software en WSUS

Como ya comentamos el otro día en la instalación de WSUS, WSUS no permite crear paquetes de terceros como Java, que vamos a utilizar como ejemplo. Para poder distribuir este tipo de software deberemos utilizar una aplicación que lo complemente.

Si vamos a usar Java para el ejemplo, el primer paso que debemos hacer es descargar los instalables OFFLINE de Java:

http://www.java.com/en/download/manual.jsp

Como ya vimos teníamos una unidad para los parches en WSUS, así que dejamos el paquete en el servidor d:\DATOS\JAVA

Ahora vamos a la página de la que vamos a descargar la herramienta:

https://wsuspackagepublisher.codeplex.com/

Pulsamos en Download para descargar la aplicación (sólo hacer este paso y el siguiente si existe versión nueva)

La copiamos en el WSUS descomprimida, en la carpeta D:\RemoteMsiManager

Ahora debemos extraer el UUID de la nueva actualización. Nos podemos instalar la versión en nuestro equipo (o hacerlo en desarrollo) y extraerla por powershell con el siguiente comando.

get–wmiobject –class Win32_Product

Para que no nos genere errores de certificados, deberemos acceder a Wsus Package Publisher. Nos conectamos al WSUS local. Una vez conectados, abrimos el menú Tools  Certificate

Ygeneramos un certificado. Después reiniciamos el equipo

Volvemos a abrir Wsus Package Publisher. Ahora vamos al menú Updates -> Create an Update…

Seleccionamos la nueva versión de Java. Será un EXE que hemos descargado previamente y copiado en D:\DATOS\JAVA

Al no ser un MSI, no se auto-rellenan los campos, y deberemos hacerlo nosotros.
Necesitaremos añadir el valor 0 para un resultado Succeeded después de la instalación.
A su vez ingresaremos para una instalación silenciosa, que no se reinicie automáticamente y desinstalar versiones antiguas “AUTO_UPDATE=Disable INSTALL_SILENT=Enable REBOOT=Disable REMOVEOUTOFDATEJRES=1”
Pulsamos Next

Dejamos MSI Product installed
Ahora tenemos que crear una regla a nivel de paquete. Activamos Edit this group y pulsamos Add Rule

Introducimos el dato del UUID que hemos extraído de la versión de Java

Una vez generado, pulsamos Next

Haremos una regla para que se sepa que es Instalable. De la misma forma que anteriormente agregamos una regla de Package

Pulsamos Next

Publicamos

Esperamos a que se genere

Ahora dispondremos del paquete creado y deberemos aprobarlo

Aquí tendremos que ver a qué servidores se lo vamos a instalar, ya que el proceso de instalación será automático

Serie de post ya creados:

La entrada Instalar Java u otro software en WSUS aparece primero en VMware Blog.

Post-Instalación con WSUS

Seguimos el ciclo, de momento, de la Instalación de WSUS sobre Windows 2016. Os enseño un poco qué políticas hay que crear para que vuestro laboratorio o red trabaje con WSUS una vez ya instalado.

Abrimos Windows Server Update Services desde las herramientas administrativas del servidor WSUS

En la consola Update Services pulsamos sobre Options  Computers

Modificamos la opción a “Use Group Policy or registry settings on computers” (si queremos gestionar todo por DA). “Use the Update Services console” es la opción que usaremos para poder gestionar los equipos en esta infraestructura, ya que nos permite crear una organización más rápida (ya que no se prevé crecer demasiado al ser un laboratorio)

Ahora vamos a Computers  All Computers y pulsamos botón derecho Add Computer Group…

Definimos un nombre

Iremos al DC (Controlador de Dominio) y vamos a definir una política. Para ello abrimos Group Policy Management

Creamos una nueva unidad organizativa donde moveremos posteriormente los servidores

Movemos los servidores a la unidad organizativa dentro de SERVIDORES que les corresponda

Pulsamos botón derecho sobre la nueva unidad organizativa donde ya tenemos los servidores. Pulsamos en “Crear un GPO en este dominio y vincularlo aquí…”

Le damos un nombre significativo

En la nueva política, botón derecho  Editar

Ahora tenemos que desplegar el árbol: Computer Configuration  Policies  Administrative Templates  Windows Components  Windows Update

Pulsamos sobre Configure Automatic Updates, botón derecho  Editar

Aquí definiríamos si queremos que las actualizaciones se autoinstalen o no.

Otra política a modificar es donde se encuentra el servidor de actualizaciones para la intranet

Editamos con el botón derecho y añadimos: http://nuestro-servidor-wsus:8530

Por último, habilitamos la política Enable client-side targeting. Editamos la política con el botón derecho

Habilitamos la política

Adicionalmente para hacer revisión de las actualizaciones pendientes añadiremos Microsoft Report Viewer: http://www.microsoft.com/es-es/download/details.aspx?id=35747
Microsoft® System CLR Types for Microsoft® SQL Server® 2012: https://www.microsoft.com/en-us/download/confirmation.aspx?id=29065

Serie de post ya creados:

La entrada Post-Instalación con WSUS aparece primero en VMware Blog.

Configurar actualizaciones en WSUS

Hoy os explicamos como debéis realizar la configuración de las diferentes aplicaciones que descargue WSUS, existe la posibilidad de Aprobarlas o Declinarlas. Esto último es algo muy normal, ya que en vuestro laboratorio igual os da lo mismo, es raro que os rompa un parche algo, pero si lo lanzáis en una organización un poco grande, seguro que hay algún KB que no os interesa instalar.

Comprobar clientes WSUS

Antes de empezar a aprobar o declinar parches, tendréis que revisar que lo aplicado por GPO y el servicio de Windows Update está todo en línea:

Comprobar que el equipo cliente está en la OU correspondiente donde trabaja WSUS
Nos conectamos a un cliente y abrimos una consola de comandos. Lanzamos “gpresult /r” (podemos forzar las políticas con “gpupdate /force”)
Para el servicio, ingresaremos el siguiente comando para inicializar Windows Update: “wuauctl.exe /reportnow /detectnow”
Se puede comprobar que todo está correcto revisando la clave de registro: https://msdn.microsoft.com/en-us/library/dd939844(v=ws.10).aspx

Aprobar una actualización en WSUS

Los parches para que se apliquen, y puedan verlos los equipos deben ser aprobados desde la consola de WSUS.

Nos colocamos en Updates, dentro de la consola Update Services. Los parches que no están instalados y son necesarios estarán en amarillo. Pulsamos sobre ellos.

La alerta nos muestra la cantidad del parque que dispone del parche e incluso cuales son las máquinas que lo necesitan. Pulsamos botón derecho y aprobamos el parche (habrá tener cuidado si el parche afecta a la compatibilidad del software antes de aprobarlo)

Aprobamos sobre los servidores que nos interesa

Pulsamos Close

Como tenemos la política en manual. Vamos a uno de los servidores por RDP que lo necesitan (el propio KB nos dice quien lo necesita en el report). Nos aseguramos que no da servicio antes de parchear (recomendable hacer un SNAPSHOT en APAGADO del servidor mediante la consola de VCENTER).

Desde el panel de control vamos a Windows Update y chequeamos

Veremos el KB que hemos aprobado. Pulsamos Install updates

Una vez instalado, reiniciado o lo que haga falta para instalar el KB correspondiente. Comprobamos desde la consola de WSUS que se ha instalado correctamente (refrescamos)

Declinar una actualización en WSUS

Es posible que, por problemas con la infraestructura, tengamos que eliminar de la línea base una actualización.

Desde la consola del WSUS deberemos declinar el paquete que da problemas. Ese KB ya no aparecerá para instalarse en los clientes.

Serie de post ya creados:

La entrada Configurar actualizaciones en WSUS aparece primero en VMware Blog.

Laboratorio VMware Integrated Containers

En otras entradas ya hemos hablado de containers o dockers. En esta ocasión vamos a utilizar VMware Integrated Containers, que es la solución de VMware para implementar dockers en un entorno virtualizado. Para la instalación utilizaré mi habitual laboratorio con 2 ESXi 6.5 con vCenter 6.5 (HP Microservers de 16GB de RAM).

Así que necesitaremos el software que bajaremos desde el siguiente enlace con vuestra cuenta VMware:

https://my.vmware.com/web/vmware/details?downloadGroup=VIC130&productId=707&rPId=20855

Esta versión es un OVA de unos 3.2GB, y que la terminología lo determina abreviadamente como VIC.

Los requisitos para desplegar este OVA versión 1.3 son:

vCenter Server 6.0 or 6.5
ESXi 6.0 or 6.5 para todos los hosts
2 vCPUs
8GB RAM
80GB libres de disco

Instalación VMware Integrated Containers

Vamos a nuestra consola de vCenter y pulsamos botón derecho en el clúster –> Implementar plantilla desde OVF:

Elegimos carpeta si la tenemos:

Elegimos el ESXi:

Pulsamos Siguiente:

Aceptamos el contrato:

Elegimos el storage y el tipo de aprovisionamiento (voy a dejar el de por defecto)

Elegimos la red:

Introducimos la contraseña de root y habilitamos SSH para poder gestionar el appliance:

Podéis colocar una ip o dejar que el DHCP trabaje dejando los datos en blanco (yo ya tengo dhcp y dominio así que va ir en blanco):

Os dejo como rellenarlo:

Dejamos los puertos por defecto:

Dejamos por defecto:

Modificamos la contraseña del usuario por defecto vic:

Pulsamos Finalizar

Esperamos a que termine:

Post-Instalación VMware Integrated Containers

Arrancamos la máquina y revisamos en la consola que ha arrancado:

Accedemos a la url que nos indica https://192.168.2.219:9443/ e introducimos los datos de nuestro vcenter:

Ya tenemos todo listo, pulsamos OPEN:

Y tenemos acceso a la gestión:

En las siguientes entradas crearemos contenedores y os explicaré como gestionarlos a través del propio vCenter con la instalación del plugin.

La entrada Laboratorio VMware Integrated Containers aparece primero en VMware Blog.

Instalar Plugin VIC para vCenter Server Appliance

El otro día empezamos a instalar nuestro laboratorio de Dockers con la solución de VMware vSphere Integrated Containers. Uno de los pasos casi obligatorios, que no necesarios, es instalar el plugin de VIC en nuestro vCenter.

Como yo tengo el appliance, utilizaré la instalación en el appliance para ilustrarlo. Para que veáis que no es nada complicado, voy a lanzar la instalación desde mi Samsung Galaxy Note 8, con una aplicación que me permite hacer SSH.

Acordaros que hay que moverse en versión 6.0 o superior para realizarlo tanto en el vCenter como en los ESXi. En mi caso estoy en la versión 6.5

Instalando Plugin VMware VIC en Appliance

Lo primero que tenemos que hacer es comprobar que nuestro vCenter tiene SSH habilitado, y por supuesto, saber la contraseña de root. Así que lo comprobamos desde Inicio –> Administración –> Implementación –> Configuración del sistema –> Nodos –> Pulsamos sobre el vCenter –> Pestaña Administrar:

Una opción que no vamos a utilizar es subir directamente el fichero tar.gz del plugin desde la gestión de VIC (https://IP_VIC:9443)

Una vez todo comprobado, nos conectamos SSH a nuestro vCenter Server Appliance y lanzamos bash con el comando shell:

Lo que haremos ahora es generar dos variables que nos sirvan para simplificar la instalación. Lanzamos estos dos comandos:

Escribimos la dirección de nuestro vSphere Integrated Containers:

export VIC_ADDRESS=<i>vic_appliance_address</i>

El archivo tar.gz de nuestra versión vSphere Integrated Containers Engine:

export VIC_BUNDLE=vic_v1.3.0.tar.gz

Usaremos el comando CURL de la siguiente forma:

curl -kL https://${VIC_ADDRESS}:9443/files/${VIC_BUNDLE} -o ${VIC_BUNDLE}

instalar-plugin-vic-para-vcenter-server-appliance-3

Esto nos ha proporcionado el paquete, así que ahora tenemos que descomprimirlo:

tar -zxf ${VIC_BUNDLE}

Ahora navegamos hasta el directorio /vic/ui/VCSA, y lanzamos el fichero que permitirá la instalación

cd vic/ui/VCSA

./install.sh

Nos pedirá la IP de nuestro vCenter, y usuario/contraseña de administrador. Le decimos que SI en el certificado, esperamos a que el proceso termine:

Ahora para completar la instalación vamos a parar y arrancar los servicios para que la interfaz gráfica se “entere” de que hay un nuevo plugin:

Para el cliente HTML5.

service-control --stop vsphere-ui

service-control --start vsphere-ui

Para la versión FLASH.

service-control --stop vsphere-client

service-control --start vsphere-client

Ahora podemos comprobar que está instalado:

Si hacéis click sobre él, al menos en mi caso, pero no tengo aún terminado de configurar mi Appliance VIC, seguiremos en otras entradas:

Entradas laboratorio VMware Integrated Containers:

La entrada Instalar Plugin VIC para vCenter Server Appliance aparece primero en VMware Blog.

Migrar en VMware los VMkernel a switch distribuido

Esta entrada la voy a hacer porque no me había dado cuenta que para lanzar Containers, la red tiene que ir sobre VMware vSphere Distributed Switch (VDS). Es un cambio significativo en el laboratorio, pero que tenía paralizado desde hace tiempo.

Así que vamos a explicar, de una manera “fácil y corta” en qué consiste un Switch Distribuido. Para ello, lo más fácil es explicar que diferencia fundamental hay entre un vSwitch Estándar y uno Distribuido.

La diferencia fundamental es que un switch estándar sólo funciona en un host esxi concreto. Yo no puedo compartir ese switch generado con otros hosts esxi. ¿Qué pasa con eso? Pues que cada vez que instalas un ESXi, tienes que replicar ese switch en todos los hosts que quieras añadir.
Por contra, un switch distribuido está pensado para ser flexible y evitar ese problema. Simplemente se lo tenemos que presentar a los hosts que nos interese para replicar la configuración. Digamos, que desde un punto de vista, es mucho más autónomo con respecto a switch estándar. Para ello se generan grupos dentro de DSwitch que se van presentando a los hosts que nos interesan. Facilita tareas más tediosas como introducir un hosts a un clúster.
Eso no quiere decir que un switch distribuido sea totalmente diferente a uno estándar, podemos configurar interfaces VMkernel (para gestión de tráfico entre los hosts), necesita adaptadores físicos para conectar la infraestructura virtual con la física, proporciona acceso a las máquinas virtuales a la red…
Adicionalmente, sobre un switch distribuido se pueden hacer gestiones extra que no tenemos en un switch estándar, como son control del tráfico o la seguridad.
Los grupos se gestionan desde el vCenter, por lo que todos los hosts deben estar dentro de la gestión del mismo. Con esto se asegura que un switch distribuido accede a la misma red física de todos los hosts, independientemente del que sea.

Así que partimos de la foto actual, que es como están configurados los 2 ESXi de mi laboratorio:

2 vSwitchs
3 VMKernel (Management Network, iSCSI y vMotion)

CREAR VSPHERE DISTRIBUTED SWITCH (VDS)

Entramos a la gestión de nuestro vCenter, apartado Redes. Pulsamos botón derecho sobre el centro de datos –> Distributed Switch –> Nuevo Distributed Switch…

Le damos un nombre:

Utilizaremos la última versión:

Lo dejamos de momento por defecto:

Y finalizar. Ya tenemos un grupo y switch distribuido creado, ahora hay que configurar y generar también otros grupos:

En mi caso, he generado tres DGroups nuevos y he renombrado el generado para poder migrar mis VMKernel (ahora no tengo tantos adaptadores físicos, pero es como lo haré cuando compre las tarjetas apropiadas):

Agregar hosts y VMKernel a VMware Distributed Switch (VDS)

Ahora vamos a agregar la parte “menos dolorosa” (dejamos iSCSI a parte) a nuestro DSwitch. Llevaremos los hosts, la Management Network y el vMotion al switch distribuido. Este proceso no es limpio porque no tengo mas que dos interfaces, cosa que voy a cambiar en breve, pero funciona.

Empezamos pulsando botón derecho sobre DSwitch –> Agregar y administrar hosts

Elegimos Agregar hosts:

Añadimos los hosts:

Seleccionamos los tres checks porque quiero migrar también las máquinas virtuales:

Seleccionamos el interfaz que me interesa (vmnic1 en mis hosts es para iSCSI, así que lo descarto) y pulsamos Asignar vínculo superior:

Asignación automática:

Repetimos lo mismo para el otro host:

Asignamos a cada interfaz el grupo correspondiente:

Revisamos que no tenga impacto en nuestro infraestructura:

Seleccionamos todas las máquinas virtuales pulsando CTRL y hacemos clic sobre Asignar grupo de puertos:

Seleccionamos el DGroup de las máquinas virtuales

Y pulsamos Finalizar:

Migrar VMKernel iSCSI a VMware Distributed Switch (VDS)

Para migrar mis adaptadores iSCSI a VDS primero he liberado de máquinas virtuales la LUN correspondiente. Una vez hecho. desde la configuración de red de cada ESXi voy eliminando el adaptador iSCSI:

Para ello vamos a Configurar –> Almacenamiento –> Enlaces de puertos y eliminamos:

Decimos que SI:

Repetimos el proceso en todos los esxi:

Seleccionamos Administrar redes de host:

Agregamos los hosts:

Lo dejamos por defecto:

Asignamos vínculo superior para la interfaz de iSCSI:

Lo mismo con el VMkernel, asignamos grupo de puertos:

Analizamos el impacto:

Pulsamos Finalizar:

Ahora tendremos que ir a la sección Almacenamiento de la configuración del ESXi y pulsamos Añadir enlace en el adaptador ISCSI

Elegimos el DSwitch al que hemos asignado el interfaz de iSCSI

Ahora tenemos que reescanear los adaptadores:

Pulsamos Aceptar:

Ya podemos eliminar el vSwitch antiguo:

Yo tengo que activar Jumbo Frames para que trabaje con la Synology. Así que, si pulsáis botón derecho Configuración –> Editar configuración, podéis modificar la MTU del DSwitch.

Y así ya podemos ver nuestro almacenamiento iSCSI a través de un switch distribuido

Entradas laboratorio VMware Integrated Containers:

La entrada Migrar en VMware los VMkernel a switch distribuido aparece primero en VMware Blog.

Instalar driver ESXi tarjeta dual ethernet HP Microserver Gen8

Después de un buen tiempo, voy a hacer unas modificaciones a mis dos HP Microservers Gen8. Ya que no les puedo ampliar la memoria, los voy a dotar de interfaces de red. Para ello he encontrado una tarjeta Intel 82576 Gigabit Dual Port Network Connection a buen precio en Amazon. Tenía que ser PCIe 2.0 – 16x y tener adaptador de perfil bajo, a parte de ser Gigabit para completar las especificaciones.

A su vez, como me he quedado sin bocas en el switch para estos “inventos”, he comprado un D-Link Gigabit sin gestión, ya que ya tengo uno gestionable donde haré las modificaciones y pondré en la VLAN que corresponda.

Precio total, unos 47€ cada tarjeta y unos 30€ el switch.

Os dejo la referencia:

Aunque leí que las tarjetas eran compatibles, el ESXi no ha sido capaz de detectarlas por si solas (cosas de ser un sistema un poco “capado”). Así que le tendremos que ayudar un poco. Vamos a la página de compatibilidad y descargamos el driver para nuestra versión de ESXi.

ENLACE DESCARGA ESXi 6.5 U1: https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=9660.

Una vez que lo tenemos descargado lo descomprimimos y manos a la obra.

Instalar archivo VIB en VMware ESXi

Como no podía ser un siguiente-siguiente con un EXE, los amigos de VMware disponen de sus propios ficheros para sus controladores, llamándose VIB (vSphere Installation Bundle).

En mi caso venía en un .ZIP con los siguientes ficheros:

En la carpeta DOC te da unos ficheros TXT con los README de lo que vas a instalar.
Los drivers en formato VIB y ZIP para hacer offline desde consola (con el Update Manager no he visto como hacerlo en la versión 6.5U1, cosa que en las antiguas se hacía con una Baseline)
En la carpeta SOURCE, el driver en bruto

Instalación VIB desde consola del ESXi

Es el método que yo usaría. Pondría el esxi en mantenimiento primero:

vim-cmd hostsvc/maintenance_mode_enter

Lo más cómodo es subir el fichero VIB o ZIP con un programa tipo Filezilla (tiene que ir a la carpeta de los datastores, elegís uno /vmfs/volumes):

Podéis hacerlo de dos formas según el fichero que uséis. Utilizamos ahora Putty, por ejemplo, para conectaros SSH:

esxcli software vib install -d "/vmfs/volumes/UUID_VUESTRO_STORAGE/NombreDriver.zip"

esxcli software vib install -v "/vmfs/volumes/UUID_VUESTRO_STORAGE/NombreDriver.vib"

Si quisiéramos actualizar el paquete sería algo así:

esxcli software vib update -d "/vmfs/volumes/UUID_VUESTRO_STORAGE/NombreDriver.zip"

En ambos procesos tendréis que reiniciar el ESXi. Una vez arrancado todo, podéis comprobar que vemos la nueva tarjeta y sus dos Interfaces:

La entrada Instalar driver ESXi tarjeta dual ethernet HP Microserver Gen8 aparece primero en VMware Blog.

Configuracion VMware Virtual Container Host

Seguimos con el laboratorio de dockers sobre VMware. En la anterior entrada instalamos el plugin VIC (al final de la entrada tenéis todas las entradas relacionadas) en nuestro laboratorio VMware Integrated Containers. Así que vamos a la versión HTML5 de nuestro vCenter para trabajar con el plugin, a la sección Accesos directos.

Pulsamos sobre vSphere Integrated Containers:

Ahora pulsamos sobre la pestaña Virtual Container Hosts –> New Virtual Container Host:

Comentar que si usáis Chrome puede daros este error, es mejor hacerlo con Firefox, que no os generará el error:

Ahora damos un nombre al VCH y daremos un prefijo/sufijo como identificar a nuestro futuros dockers. Como veréis lo podemos hacer con nombres o Containers ID. A la hora de trabajar, probablemente uséis los IDS (identificador único del docker o contenedor) que los nombres, pero como hay que elegir uno, voy a usar los nombres para no liar a nadie:

Elijo el clúster para este trabajo, y no limito de momento los recursos:

Ahora elegiremos el almacenamiento adecuado, aunque tengo SSDs, de momento lo dejo en la Synology para mis pruebas. Utilizo una carpeta previamente creada, sino la generará.Un dato importante es que tenéis que tener claro el espacio que le vais a dar a los dockers, daros cuenta que eso no podréis modificarlo a posteriori para éste VCH, así que según con qué queráis jugar, os podéis quedar cortos (una de las gracias de trabajar con dockers es el poco espacio que ocupan). Yo lo subo a 16GB, pero con el valor por defecto de 8GB podría ser suficiente:

Ahora nos encontramos con la sección Networks vamos a explicar con un par de gráficos descriptivos que podéis ayudar en la ayuda de VMware los puertos y el comportamiento de los dockers en cuanto a la red:

Antes del siguiente paso, tener claro que no os aparecerán redes si vuestro DSwitch tiene el bloqueo de puertos automático habilitado:

Así que seguimos con los pasos. Dejaré la interfaz de mi red, aunque podría generarles otra para ellos, esto es un primer acercamiento a los dockers en VMware:

No voy a dejar la seguridad por defecto, de momento lo deshabilito porque esto es un LAB, ya le daremos más adelante una vuelta:

Lo dejo así:

De momento le doy permisos a mi usuario administrador de vSphere:

Y FINISH:

Primer fallo al generar. Tengo que corregir alguna cosa. Necesito generar un interfaz nuevo para docker que llamaré DDockerBridge y abrir el firewall al puerto TCP-2377:

Genero en mi DSwitch un nuevo Grupo de puertos distribuido llamado DDockerBridge:

Abrimos el puerto TCP-2377 para cada ESXi o deshabilitamos con el comando “esxcli network firewall set --enabled false“:

Con todo corregido…ya podemos generar nuestro primer VCH:

Si queremos comprobar el estado pulsamos sobre el enlace generado a la derecha con la IP. Introducimos las credenciales que hemos configurado anteriormente:

Y veremos su estado:

Para terminar vamos a la gestión vSphere Integrated Container y agregamos el VCH:

Introducimos los datos del VCH recién generado:

Aceptamos el certificado:

Y ya lo tenemos para poder generar dockers en otras entradas:

Entradas laboratorio VMware Integrated Containers:

La entrada Configuracion VMware Virtual Container Host aparece primero en VMware Blog.