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.

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.

Regalo para año nuevo de Veeam – Dream LAB!

Como siempre, Veeam nos sorprende  (hace varios días ya..) con el anuncio de un dream lab…

Solo tienen que registrarse y automáticamente estarán participando en el sorteo de lo siguiente:

  • TWO HP ProLiant ML 310e G8 Servers
  • NETGEAR ReadyNAS storage system with 4 SSDs drives
  • HP V1410-16G Ethernet switch
  • TechNet Plus subscription for 1 year
  • Online course, books and test from
    VMware Education Services or Microsoft Learning
  • …and a MICROSOFT SURFACE!

Si, una Microsoft Surface también……

vCloud Director en el LAB.

Hace alrededor de 2 meses comencé a jugar con vCloud y para esto utilice el vApp que aparece en internet (si se busca bien..), lo primero es que este vApp este destinado a POC y no tiene ningún crecimiento. Para un LAB eso esta mas que bien, todo fue muy fácil ya que viene con un Oracle instalado y todo listo para configurarse en el primer inicio de la VM.

Con los problemas eléctricos que sufrimos en mi país no era extraño que la VM de vCD presentara problemas en la DB, de un momento a otro este dejo de conectar con el vCenter y desplegaba un mensaje diciendo “None of the cells have a vCenter proxy service running”.

Buscando en internet encontré varios artículos, uno de ellos de Jason Boche (http://www.boche.net/blog/index.php/2011/12/16/vcloud-director-and-vcenter-proxy-service-failure/ ) donde con ayuda de VMware Support pudo solventar este error usando un script que elimina datos de la DB que sufrieron corrupción al momento de vCD apagarse repentinamente. Lo primero es que esto no funciono en el vApp, seguí buscando en Internet pero nada surgió que me ayudara a recuperar el cell de vCD. Así que después de varias semanas sin poder jugar con vCD he decidido eliminar el vApp e instalar una VM con CentOS6 para realizar la instalación (como recomienda VMware).

En lo adelante recopilare información de los pasos a realizar para tener vCD funcionando en CentOS6.