Experiencias con vCloud Director 5.1 – Instalación.

Desde que decidí usar vCD para el HomeLAB, no he tenido mucho tiempo para trabajar con las vApp internas. He dedicado tiempo a conocer el funcionamiento de vCD antes de depender de el por completo. Como ya escribí anteriormente, inicialmente comencé usando el  Appliance destinado a pruebas que ofrece VMware, luego (después de algunos problemas) realice una nueva instalación usando CentOS6 como sistema operativo para vCloud aunque este no este soportado, pero que mas da, esto es un LAB! Y aprovechando que necesitaba una maquina con SQL para View Composer instale SQL Server 2008 R2. Estos son los pasos para preparar CentOS y luego instalar vCloud.

  • Instalar CentOS (minimal install)
  • Actualizar todos los paquetes!
  • Instalar los prerrequisitos para vCD

alsa-lib compat-libcom_err libXtst which libICE libSM libXt redhat-lsb

  • Deshabilitar el firewall de CentOS, créanme, esto al inicio me hizo pensar que cometí un error mientras instalaba ya que no nos deja conectar al portal web.
  • Configuración de red, vCD necesita 2 direcciones IP. normalmente he visto que usan una interface tipo alias (que depende de la misma interface física). Yo aquí mejor le agregue una vNIC a la VM.
  • Instalar VMtools.
  • Copiar el RPM de vCD (yo lo hice usando WinSCP).

Para este punto deberíamos tener una VM con CentOS funcional, si se desea se puede crear un TEMPLATE para salvaguardar lo que hemos trabajado. Instalando vCloud Luego de copiar el RPM instalar de vCD debemos darle permisos de ejecución, esto lo conseguiremos haciéndole un chmod +x al instalador.

Como se puede ver al final de la imagen, le decimos NO a la petición de ejecutar el script al momento de terminar la instalación, esto es debido a que necesitamos realizar algunos pasos para poder continuar, el script en cuestión lo podremos encontrar luego en /opt/vmware/vcloud-director/bin/configure y ejecutarlo.

Creando los Certificados.

Esta es la razón de porque no ejecutamos el script desde la consola de instalación cuando no los pidió en el paso anterior, debemos crear un archivo .KS en el cual se encuentran los certificados para el acceso HTTPS y la consola.

Para crear el certificado https:

/opt/vmware/vcloud-director/jre/bin/keytool -keystore certificates.ks \ -storetype JCEKS -storepass passwd -genkey -keyalg RSA -alias http

Para crear el certificado de consoleproxy:

/opt/vmware/vcloud-director/jre/bin/keytool -storetype JCEKS -storepass passwd \ -keystore certificates.ks –list

El archivo creado se llama certificates.ks y necesitamos tenerlo en un lugar accesible a la configuración de vCloud, este archive lo he movido a /opt/vmware/vcloud-director/ y asignado los siguientes permisos (chmod 755 /opt/vmware/vcloud-director/ certificates.ks), también debemos entregar este archivo al usuario vcloud (chown vcloud:vcloud certificates.ks).

Configurando vCloud Director.

Ya tenemos lo necesario para iniciar la configuración de vCD, ahora ejecutaremos el script /opt/vmware/vcloud-director/bin/configure  y este nos pedirá información que la deberíamos tener a mano.

  1. Nos pedirá las direcciones IP configuradas cuando creamos la VM con CentOS, 1 es para el acceso HTTP y la otra es para el consoleproxy.
  2. Nos pedirá la ubicación del archivo con los certificados y la contraseña que usamos al momento de crear este archivo (en este caso fue passwd).
  3. Nos pedirá un servidor syslog.
  4. Nos pedirá la base de datos que usara vCloud, en mi caso ha sido MS SQL.

Si la conexión con la DB es exitosa en la consola nos mostrara información de lo que se esta realizando en la DB, al terminar nos pedirá si deseamos iniciar el servicio de vCloud, responderemos que si. Si hemos realizado algún paso de manera errónea y necesitamos recolectar información para determinar el problema, el lugar indicado es cell.log y esta ubicado en el directorio logs de la instalación de vCD (tail -f /opt/vmware/vcloud-director/logs/cell.log). En este punto ya tenemos instalado vCloud.

Aun nos faltaría configurarlos y es algo que ya he realizado en mi LAB, mas adelante realizare un post con esta información pero realizando los pasos usando AutoLAB. Nota: Gracias a varios artículos en blogs de personas que ya han realizado esta instalación el proceso fue menos doloroso en especial http://blog.tsugliani.fr/featured/create-your-own-virtual-vcloud-lab-part-1/ de la cual espero la parte2.

vSphere Web Client con problemas de syncronizacion de reloj.

Desde hace varios días estoy usando más el Web Client, esto es gracias a que lo desplegué en el servidor en OVH, a su vez, este ve la instancia de Web Client instalada en el vCenter local en casa. Me ha fascinado la manera tan fácil que SSO remplaza a Linked-Mode, con simplemente entrar al vCSA en OVH que es accesible desde internet puedo ver los recursos del vCenter en casa.

Pero, el día de hoy intentando disfrutar las ventajas de Web Client me encuentro con un error de sincronización de reloj el cual alega que los servidores que conforman la estructura de vSphere no tienen la misma hora. Para mi sorpresa mientras buscaba información sobre esto el problema despareció solo.

Synchronizing Clocks on the vSphere Network.

Protegiendo las VM de mis ambientes virtuales.

Desde hace casi 2 años, hago backup de Maquinas Virtuales (VM) usando Veeam (http://www.veeam.com) y ha sido la mejor experiencia. Ahora intentare plasmar aquí el escenario donde Veeam B&R (Backup and Replication) respalda las VM importantes de mi LAB, algunos se preguntaran porque hacer backup de VM de un LAB, la respuesta es que luego de montarse un LAB que poco a poco gran parte de este se va convirtiendo en “producción” es muy lioso volver a configurar todo de la noche a la mañana y mucho mas cuando ha tomado meses llegar al estado actual.

Hace varios días re-instale todo el vCloud Director donde inicialmente este era funcional usando el Appliance de VMware el cual luego de un corte de luz dejo de funcionar, esta es historia para otro post pero la relación que tiene aquí es que el SQL y el CentOS donde esta instalado vCloud le hago backup con Veeam ya que no quiero perder (nuevamente) todo lo que he configurado allí.

El Veeam B&R instalado en casa cuenta con una licencia NFR, con esta licencia (Gracias Veeam!!!) puedo disfrutar de todas las funcionalidades de B&R, una de las mas importantes es agendar los backup, la versión gratuita no dispone de esta funcionalidad. Ha sido sorpréndete la diferencia entre la versión paga y la versión gratis de este software ya que en la versión gratuita solo se puede hacer Quick Migration y backup con VeeamZIP.

En estos momentos tengo 2 instalaciones de Veeam B&R, una en Casa y la otra en OVH (https://arielantigua.com/weblog/2012/12/15/ovh-dedicate-server-vmware-esxi/), la versión en OVH tiene licenciamiento gratuito así que solo podre hacer backup en demanda, ahora mismo el inconveniente es tener 2 consolas del mismo producto. Buscando un poco en la pagina de Veeam veo que tienen una herramienta la cual esta incluida en el paquete que se descarga pero por razones desconocidas nunca le preste atención a la finalidad de dicha aplicación, acabo de encontrarle la finalidad, con esta aplicación podremos administrar varias instalaciones de B&R desde una consola central.

 

Veeam B&R Enterprise Manager e un componente opcional destinado a ambientes en empresas grandes con multiples servidores de backup. Este componente puede ser instalado en una maquina física o virtual, si se desea, se puede instalar en una maquina con B&R ya instalado. http://www.veeam.com/vmware-backup/help-center/hyperv/index.html?enterprise_manager.htm

Video de Introduccion:

http://www.veeam.com/university/emeu.swf

OVH Dedicate Server + VMware ESXi.

Desde hace meses he estado investigando un proveedor de servidores dedicados en el cual pueda instalar VMware ESXi, la mayoría lo ofrecen, pero a un precio que no puedo pagar. OVH, por lo que he podido ver, ha estado ofreciendo ESXi en su “Supported OS List” desde hace mucho tiempo pero el problema en el pasado con OVH es su restricción de la localidad física del cliente.

Para ordenar en OVH debes ser residente de UK, España, Canadá y otro mas que ahora no recuerdo, la buena noticia es que cuando me puse en contacto con OVH Canadá me informaron que brindan servicio a todo público en el portal http://ovh.us (este seria el equivalente a http://ovh.ca ). Luego solo quedaba verificar la disponibilidad de ESXi como OS disponible para instalación, aunque en la lista inicial no aparece ESXi, se puede instalar con cualquier OS y mas adelante hacer una reinstalación. En el portal con opciones de reinstalación, tendremos disponible ESXi4.1 y ESXi5.0 (en beta?).

Las especificaciones del servidor están aceptables y con relación al precio es una ganga.

El único problema que veo con la forma de instalación de ESXi en OVH es que la consola esta expuesta a Internet, además debemos solicitar un FailOver IP para utilizar un router allí (en mi casa he usado Vyatta) y así poder hacer NAT. Los FailOver IP son ruteados al IP asignado inicialmente al Servidor Dedicado.

Para realizar esa configuración solo se debe seguir los pasos en http://help.ovh.ie/BridgeClient pero antes debemos crear la VM que será el router y tomar la MAC de la interface que estará en el mismo VMkernel con conectividad a Internet, esta MAC la debemos agregar al FailOver IP en el portal de manejo para que pueda ser usada, al parecer OVH filtra esto como modo de protección a los demás clientes (eso lei…).

En Vyatta he tenido que agregar en rc.local una ruta para que el Gateway sea alcanzable desde la VM con Vyatta, si pueden notar el FailOver IP es un /32 y no esta en L2 con el Gateway, por eso primero debemos hacer que el Gateway sea alcanzable usando eth0 o la interface de la VM conectada al vSwitch donde esta el VMkernel de nuestro ESXi.

Aquí un ejemplo de una configuración similar – http://www.vyatta.org/node/4133

Otro problema que debo solventar es el inconveniente para mantener la comunicación entre el ESXi en OVH y el vCenter en mi casa, luego de agregar el ESXi este se desconecta luego de pasar 90 segundos ya que el ESXi no tiene forma de responder al vCenter.

La manera para resolver esto será la siguiente: Hacer una conexión VPN entre el vyatta en OVH y el vyatta en casa para asi rutear pa conectividad, luego debemos crear un segundo VMkernel con una dirección del lado interno del vyatta la cual esta alcanzable directamente desde la red interna en casa ya que están siendo ruteadas en el túnel VPN, aquí la duda era como hacer que este VMkernel sea usado para responder a 172.22.35.0/26 desde 10.45.11.9 (este es el segundo VMkernel), la respuesta?  Static route. Leyendo el KB: 2001426, podemos ver que es soportado usar Gateways adicionales en el VMkernel port. To configure a second gateway for the management network:

  1. Open a console to the ESX or ESXi host. For more information, see Unable to connect to an ESX host using Secure Shell (SSH) (1003807) or Using Tech Support Mode in ESXi 4.1 (1017910).
  2. Run this command: esxcfg-route -a For example, to add a route to 192.168.100.0 network through 192.168.0.1, run one of these command:
    • esxcfg-route -a 192.168.100.0/24 192.168.0.1
    • esxcfg-route -a 192.168.100.0 255.255.255.0 192.168.0.1

Luego de realizar estos pasos y tener listo el VPN el VMkernel  con el IP 10.45.11.9 sera alcanzable desde mi vCenter en casa y lo mas importante el ESXi en OVH podrá responder al vCenter y mantener el Keep Alive contento. KB: 2002056

Ahora solo falta crear una VM con Veeam para respaldar en el espacio FTP que ofrece OVH como complemento del servicio.

Esto es solo el inicio!!! Por ejemplo: AutoLAB ¿?

Project Nee.

VMware HOL

 

Hoy he recibido la invitación a Project Nee (VMware HOL). Muy emocionado por probar esta infraestructura inmediatamente intente realizar los pasos descritos en el correo que recibí pero al parecer en esos momentos el portal tenia problemas y no podía acceder. Unos momentos mas tarde intente entrar y todo respondió como debe ser y pude conseguir la contraseña de mi cuenta.

Que podemos hacer en esta plataforma?

Por el momento podemos usar LABs predefinidos por VMware y con tan solo hacer click en <enroll> somos re direccionados a una sección donde lanzamos estos LABs y podemos probar funcionalidades como Distributed Switch (vDS)vCloud Networking and Security (vCNS) y otros LABs que ya están o se estarán agregando próximamente.

Algo que pude notar es que casi no se usa (o no se usa?) el vSphere Client y todo es administrado vía el Web Client, esto confirma que próximamente el Cliente de Windows pasara a un segundo plano o desaparece.

Los LABs están siendo agrupados en Cloud Infrastructure, Cloud Operations & End-User Computing, al final se puede apreciar una sección Transcript donde se almacenan los LABs realizados por el usuario. Actualmente mi interés esta en la sección Cloud Infrastructure, allí inmediatamente me llamo la atención el HOL-INF-07 (vCloud Networking and Security (vCNS)).

Seguire explorando el portal y posteare información de algunos LABs dependiendo que interesante sean.