Saltar al contenido

Creación de una iso personalizad de VMware vSphere 6.5 con ESXi-Customizer-PS

Para aquellos que tenemos Homelabs con HW que no esta certificado al 100% por VMware, es habitual tener que generar una iso personalizada en la que le “inyectamos” los drivers que necesitamos y que no vienen por defecto en nuestro ESXi.

Aprovechando que recientemente he actualizado mi Homelab a 6.5 he documentado el proceso.

 

Requisitos previos:

Tener la política de ejecución de scripts a un valor que nos permita ejecutar el que vamos a usar para generar la ISO. Puedes ver el estado de la política de ejecución y cambiarla siguiendo este artículo.

 

Una vez comprobado esto, el siguiente paso es descargar e instalar (si no lo tenemos ya), el PowerCli de VMware.

Descargar PowerCli de VMware

 

a continuación descargaremos el script que usaremos para generar la iso y que se llama “ESXi-Customizer-PS“, lo podéis encontrar aquí.

 

Generar la ISO:

Nos dirigimos al directorio donde tenemos descargado el script y lo ejecutamos

 

y voila, ya tendríamos nuestra ISO personalizada. En mi caso he incluido los drivers Realtek 8165 y sata xachi.

Jugando con el script:

 

El script tiene múltiples opciones que nos permitirán personalizar nuestra ISO. Con el comando Help podemos verlas, junto a una pequeña explicación de lo que hacen.

 

ECPS-25-Help

 

para mi las opciones más interesantes son:

  • -vxx: para especificar que versión de vSphere queremos generar
  • -pkgDir: nos permite incluir drivers .vib (útil cuando el driver que necesitamos no esta en el repositorio “oficial” de los creadores del script)
  • -vft: para conectar al depot de los creadores del scritp

 

Nota importante: aunque os sintáis tentados de usar los drivers de Linux, no lo hagáis VMware empaqueta los drivers de una manera distinta y no os va a funcionar.

Habilitar ejecución de scripts PowerShell y VMware-PowerCLI

Por fin he sacado algo de tiempo para actualizar mi homelab a VMware vSphere 6.5 y me he encontrado los problemas típicos de drivers , que me han requerido generar una ISO “customizada” para mis equipos.

 

La primera traba que os vais a encontrar (sobre todo si venís de una instalación limpia, tanto del homelab como de vuestro puesto de trabajo), es que Windows10 por defecto no restringe la posibilidad de ejecutar scripts PowerShell.

 

Podemos consultar el estado de la política de ejecución mediante el comando Get-ExecutionPolicy

 

Ver política de ejecuión

 

que como podéis ver es Restricted.

Las opciones que podemos elegir al cambiar la política serán:

  • Restricted: Por defecto y la más restrictiva
  • AllSigned: requiere que los scripts estén firmados por una fuente de confianza y pide confirmación antes
  • RemoteSigned: al nivel anterior le suma la posibilidad de ejecutar scripts no firmados, siempre y cuando estén desbloqueados mediante el comando Unblock-File
  • Unrestricted: puede ejecutar scripts sin firmar y muestra advertencias
  • Bypass: puede ejecutar cualquier cosas y no muestra advertencias
  • Undefined: no hay política definida y se aplica la default

Las buenas practicas nos dices que deberíamos coger el valor más restrictivo posible. En mi caso y como en el Homelab estoy constantemente jugando y probando cosas distintas lo fije a Unrestricted.

Fijar política de ejecución a Unrestricted

finalmente comprobamos el estado de la política:

Ver política de ejecuión

 

con esto y la PowerCli de VMware (se descarga de la sección tools de vSphere), podremos ejecutar nuestros scripts para VMware.

 

Espero que os resulte de utilidad

World tour across Huawei Data Center Solution

Que Huawei es una de las compañías con mayor potencial de crecimiento e innovación en el mundo Enterprise IT & IP (en otros sectores como el Telco es casi una dictadura), es algo que muy poca gente se cuestiona hoy en día. Cuentan con un portfolio que seguramente será la envidia de muchos competidores y pueden presumir de contar con Data Center de primer nivel basados en su tecnología.

 

Este vídeo es un pequeño recorrido por algunos de ellos.

 

Espero que os guste.

 

 

 

Cisco y el extraño caso de la señal de reloj

Hace unos días el mundo IT (en su parte de sistemas, porque la verdad no he percibido que los desarrolladores estén muy preocupados por este tema 😉 ) se sobresaltaba con un comunicado de Cisco (podéis leerlo aquí), donde reconocía que determinados equipos de gran popularidad (ASA, algunos Nexus…) estaban afectados por un problema en la señal de reloj, que podía derivar a la indisponibilidad de los sistemas.

 

 

El problema afectaba a equipos con fecha de fabricación anterior al  16 de Noviembre de 2016 y Cisco ofrecía a aquellos clientes con garantía la sustitución de los equipos. Quedando fuera aquellos clientes que no contasen con soporte, lo cual teniendo en cuenta que estos equipos se venden por defecto con un único año de garantía podía poner en apuros a aquellos clientes que por algún motivo no hubiesen renovado.

 

Lo realmente grave del asunto (aparte de la respuesta adecuada o no de Cisco) es que el fallo se localiza en los chips AtomC2000 de Intel (que esta evitando pronunciarse) que equipan numerosas marcas.

 

Los chips afectados serían los C2308, C2338, C2350, C2358, C2508, C2518, C2530, C2538, C2550, C2558, C2718, C2730, C2738, C2750, y C2758.

 

 

vExpert 2017

En el día de ayer se hacía publica la lista de galardonados en 2017 con el vEXPERT de Vmware y he tenido el honor de repetir en ella un año más.

 

 

He de decir que es un galardón que me hace especial ilusión por lo que supone en cuanto a reconocimiento del trabajo realizado en la comunidad, además se trata de una renovación, lo que implica que seguimos en la brecha y que el trabajo realizado compartiendo conocimiento y experiencias deja sus frutos.

Muchas gracias a todos los que habéis hecho posible esta renovación y espero seguir contando con vuestras visitas, comentarios, retwiteos, críticas, etc.

Podéis consultar la lista completa de vEXPERTS aquí

Gracias  !!

Crear un USB de VMware ESXi6.5

Utilizar un USB para arrancar nuestro VMware es una de esas cosas que tenemos que hacer habitualmente y aunque no es una labor complicada, aquí os dejo una pequeña guía de como hacerlo.

Paso 1: obviamente descargar la imagen iso que queramos “flasear” en nuestro usb

Paso 2: Descargar una utilidad para grabar la iso, yo por ejemplo uso Rufus, que puedes descargar de aquí.

Rufus

 

Paso 3: creamos nuestro CD siguiendo los pasos de las imágenes siguientes:

 

Rufus_Esxi1

como podéis ver, seleccionamos Fat32 como sistema de archivos, y tamaño de cluster por defecto. Pulsamos sobre el icono señalado con la flecha para seleccionar la iso y clickamos sobre empezar

Rufus_Selección ISO

 

y voila!!!, ya tenemos nuestro usb listo para usar

OpenStack Newton for Dummies – Introducción – Newton Networking for Dummies (II)

OpenStack Newton Networking for Dummies – Introducción – Decisiones de Networking (II)

Como pudimos ver en la primera entrega OpenStack está formado para varias componentes que interactúan entre si para ofrecer el resultado final de IaaS y lógicamente esto no sería posible sin la correcta gestión del networking.

Las consideraciones acerca del networking en una plataforma cloud tan potente (y compleja) como OpenStacj pueden ser muchas, pero en este punto nos limitaremos a decidir entre el tipo de despliegue que realizaremos, siendo las opciones:

 

  • Network Provider
  • Self Service Network

 

La opción de Netowrk provider es la más sencilla de todas y básicamente trabajara a nivel 2 (Layer 2), realizando funciones de bridging y switching para conectar la red virtual con la física. Por supuesto tendremos disponible las funciones de segmentación en vLans.

 

OpenStack Network Provider

<imagen cortesía del proyecto OpenStack>

La siguiente opción es la más completa y nos permitirá incorporar a nuestro juego de herramientas la capa 3 (Layer 3), lo que nos permitirá realizar el autoservicio de redes con “overlay” en la segmentación, lo que nos posibilitará por ejemplo el uso de vXlan.

Simplificando podemos decir que la conexión entre las redes virtuales y físicas se realizará usando NAT.

 

OpenStack_SelfService_Network

 

¿Qué opción es preferible?

Pues depende mucho de nuestro entorno. Si hacemos caso al principio Kiss lo lógico sería optar por un diseño Networkk Provider salvo que preveamos necesitar funcionalidades de Self Service.

¿Qué opciones pueden hacer recomendable un diseño Self Service?

 

Pues hay varias cosas que pueden hacer necesario este tipo de despliegue. La primera de ellas es que seamos muy grandes y preveamos necesitar más de 4096 vLans, por lo que necesitaremos hacer uso de cosas como las vXlan, la segunda sería que necesitásemos el uso de funcionalidades como Balanceador o Firewall como servicio (LBaaS/FWaaS)

 

y vosotros, ¿por qué opción optaríais para vuestro cloud?

OpenStack Newton for Dummies – Introducción(I)

OpenStack Newton for Dummies – Introducción(I)

Cloud Conputing es un nuevo paradigma de computación y aunque no es objeto de este artículo explicar que es, o que variantes podemos encontrar, si indicaremos que estas son:

  • SAAS: software as service
  • IAAS: infraestructura as service
  • PAAS: platform as service.

OpenStack

OpenStack es un proyecto apoyado por importantes actores del mundo Cloud (NASA, RackSpace, Huawei, DELL, CISCO, Intel y un largo etc. que puedes ver aquí), que encajaría en la categoría de IAAS, siendo la alternativa comercial más cercana y conocida el servicio AWS (Amazon Web Service) de Amazón. Newton es la última versión disponible de este software.

¿Es realmente una alternativa a Amazon AWS?, bueno hay que matizar que Amazon comercializa un “producto” soportado por su propia implementación de la nube, por tanto OpenStack sería el software que nos permitiría montar un servicio cloud equiparable a Amazon ( lógicamente condicionado por nuestra infraestructura, conectividad, etc.). OpenStack es realmente potente y la mayoría de grandes actores y competidores en el mundo Cloud lo usan.

Explicarlo todo en un artículo sería realmente complicado, por lo que voy a optar por estructurarlo en varios entregas más pequeñas que vayan cubriendo los aspectos principales.

Arquitectura de OpenStack:

Como imaginaréis está formado por un número significativo de componentes, que se reparten las distintas funciones y entre las que podemos encontrar:

  • Controller: es el nodo de control de nuestra plataforma y por tanto deberá estar conectado a la red de gestión de la misma
  • Compute Node: son los nodos que alojan la capacidad de computo en si misma (Hypervisor)
  • Block Storage: es una componente opcional y permite servir almacenamiento de bloque a la plataforma
  • Object Storage Node: son nodos de almacenamiento en forma de objetos. Es una componente opcional

 

Esas componentes se integrarán para dar soporte desde a arquitecturas pequeñas, como a los más complejos despliegues para ISPs.

 

Para nuestro Homelab, podemos partir de los siguientes parámetros básicos:

<imagen cortesía del proyecto OpenStack>

Sistemas Operativos Soportados

Podemos instalarlo en cualquiera distribución Linux, aunque sin duda para una prueba de concepto Ubuntu es la mejor opción, por similitud en los ciclos de desarrollo (disponibilidad de versiones). Centos es otra muy buena opción para probar OpenStack si nos encontramos más comodos con un RedHat Like flavor.

Hypervisores soportados:

OpenStack, soporta un número importante de Hypervisores (con distinto grado de funcionalidades), Xen, XenServer/XCP, KVM, UML, Hyper-V y VMware, siendo hoy por hoy KVM el preferido de la comunidad.

En la siguiente url, podéis encontrar la mátriz de compatibilidad y funciones soportadas por cada uno de los hypervisores.

https://wiki.openstack.org/wiki/HypervisorSupportMatrix

 

Vente para Dublín Pepe!!

De los creadores de vente para UK Pepe!!,  hoy os traigo vente a para Dublín (Irlanda) Pepe!!.

 

Hace poco encontré este mapa de la ciudad de Dublín con la ubicación de las empresas tecnológicas y es realmente espectacular. No puede uno dejar de tener cierta envidia de las posibilidades que supone contar con un Hub tecnológico así en su ciudad y preguntarse, porque no ha sido posible conseguir algo similar en una ciudad española.

 

Hace unos años tuvimos en la ciudad de Málaga, una iniciativa encaminada a atraer empresas tecnológicas (Málaga Valley) que surgió a raíz de un estudio que identificaba a Málaga y Ankara como lugares con las características necesarias para poder reproducir un ecosistema como Silicón Valley, lamentablemente esta iniciativa no termina cuajar o al menos no al ritmo que nos gustaría.