Hola soy Miguel Ángel Alonso y aquí estoy contigo una semana más para volver a hablar del maravilloso mundo de la virtualización de sistemas. Cabe reseñar que a partir de hoy, voy a escribir todos los lunes en lugar del martes que es como lo he estado haciendo lo estos 2 últimos años.
Dada esta pequeña puntualización, voy a hablar te y como bien indica el enunciado del post, de una maravillosa herramienta que he encontrado para customizar las imágenes iso de nuestros ESXi y que nos va a facilitar mucho la vida en los despliegues posteriores de nuestros Hypervisores. Básicamente es un Image Builder de VMware, sólo que simplificado y hecho más fácil.
El software lo vais a poder descargar de manera gratuita desde aquí y en su página encontrarás información más que suficiente para el manejo del programa.
Para que quede más claro voy a mostrarte un ejemplo de como añadir los drivers Broadcom de mis ESXi a la imagen base del Hypervisor y su correspondiente creación.
Una vez arranquemos el Esxi Customizer 2.7.bat vas aencontarte con un entorno como este, en el que deberás seguir tres sencillos pasos. En este Screenshot se muestra el primero y en el que debemos localizar la imagen ISO original de nuestros ESXi 5.
Siguiendo el asistente, voy a dar la ruta donde tengo el fichero .vib de mis Broadcom para añadir lo a mi imagen ISO de mi Hypervisor.
Aquí te muestro que a parte de .vib, también podemos añadir ficheros comprimidos.tgz en el que podemos incluir una serie de drivers específicos para tu entorno. Tambíen existe la posibilidad de interactuar con Bundles Offline directamente como los de HP o Dell por poneros algunos de ellos como ejemplo.
Como tercer y último paso deberás de introducir la ruta donde vas a guardar la imagen ISO de tus ESXi una vez la customizes a tu gusto. En mi caso la voy a dejar en Mis Documentos y finalmente ejecutaré la opción de run para que comience con dicho proceso.
Por ultimo, nos pedirá confirmación antes de añadir nuestro .vib a la imagen final y después de unos minutos, tendrás creada tu imagen y lista para poder instalarla en tu entorno.
Bueno! Espero haber te contado algo de tu interés y te emplazo hasta el próximo lunes donde seguiremos hablando de este maravilloso y apasionante mundo de la virtualización de servidores. Hasta la semana que viene!
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.
A mediados de marzo salió una actualización de vSphere 5, que si bien no trae mejoras destacables, si resuelve problemas de “infancia” de la versión 5.
Cuando hablamos de actualizar un host ESXi, siempre nos viene a la cabeza vCenter Update Manager (VUM). El cual nos simplifica la actualización desde su consola integrada con vCenter Server.
Pero todavía hay muchas instalaciones sin VUM. Por eso repasaremos los mecanismos de actualización “a mano”.
Disponemos de tres mecanismos de actualización “oficiales”: vCLI, PowerCLI y localmente.
Primero descargamos de VMware el archivo update-from-esxi5.0-5.0_update01.zip
vCLI (desde vMA)
1. vicfg-hostops –server host01 –username root –password pass –operation enter
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Cada virtual switch, es una representación lógica vía software de un switch físico de capa dos. Los tres tipos de virtual switch que puedes crear en un servidor ESXi 5 son los siguientes:
1. Internal switch only. Este switch es usado únicamente para conectar, vía red, las máquinas virtuales instaladas en el mismo servidor VMware ESXi, las cuales no necesitan conexión con el mundo exterior.
2. Virtual switch con un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network (gestión)y puertos VMkernel con el mundo exterior, o dicho de otro modo, con otros servidores y máquinas virtuales de nuestro entorno virtual.
3. Virtual switch con más de un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network y puertos VMkernel con el mundo exterior con una funcionalidad adicional, como es el balanceo de carga y redundancia a fallos en los componentes de red.
Las políticas de seguridad y de traffic shaping son configuradas a nivel de port group y vSwitch. Una configuración incorrecta del traffic shaping afectaría no sólo al tráfico de las máquinas virtuales sino también al tráfico en general.
En vSphere™ ESXi 5, una tarjeta mapeada a un switch virtual puede ser configurada para trasmitir y recibir tramas “Jumbo Frame”. El MTU (Maximum Transmision Unit) de un ”Jumbo Frame” es de 9000. VMware ESXi 5 también soporta “Jumbo Frames”, tanto en los VSS como en los VDS.
Ahora, también es posible activar desde la GUI de los VSS el uso de los mismos. La configuración de “Jumbo Frames” es considerada una mejor práctica para las redes de tipo iSCSI, vMotion y Fault Tolerance. Los tres tipos de virtual switch pueden soportar hasta un total de 4088 puertos por switch virtual estándar.
Para los tres tipos de virtual switch, no existen colisiones de red en el tráfico interno. Asimismo la dirección MAC de los adaptadores de red conectados a los virtual switches no será usada en ningún momento de forma interna.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, en el post de hoy veremos que son la vApps y para que se utilizan.
Esta nueva funcionalidad, añadida en la versión 6.0 de XenServer se define como un grupo lógico, de una o más máquinas virtuales, que pueden ser gestionadas como una entidad agrupada. De este modo podemos arrancar/parar/exportar… un conjunto entero de máquinas virtuales como si de una sola se tratara.
Las máquinas virtuales de una vApp no residen necesariamente en un único host, sinó que se utilizan las mismas reglas de distribución que tenga el Pool.
Esta funcionalidad también permite al administrador asignar un orden de arranque de las máquinas virtuales que forman el vApp y un tiempo de espera (delay) para que arranque dicha máquina virtual. De este modo en caso de por ejemplo una caída del entorno (corte eléctrico, error hardware, etc) las máquinas virtuales del vApp se levantarían en el orden establecido, por ejemplo primero los backends de base de datos, las aplicaciones y luego los frontends web, etc.
Vamos a crear nuestra vApp de prueba
Utiliando XenCenter, seleccionamos una máquina virtual para nuestra nueva vApp y con el botón derecho, “Assign to vApp -> New vApp”. Le damos un nombre y seleccionamos las máquinas que queramos añadir al vApp. Una vez seleccionadas todas las máquinas, configuramos la “VM Startup Sequence”
Básicamente tenemos dos opciones por máquina virtual, establecer el orden secuencial de arranque y el tiempo que dejamos que el sistema espero hasta arrancar la siguiente máquina virtual. No existen unos valores estandares para el delay, puedes tunearlos en función de lo que tarde tu entorno en arrancar las máquinas virtuales. Para los que hayáis configurado clusters de Xen con HeartBeat, esta parte me recueda mucho a la configuración de Constraints, cierto?
Mediante Xapi, tenemos la entidad “appilance” que utilizaremos para gestionar las vApps desde consola como si fueran una sola máquina virtual:
Bueno, esto es todo por hoy, espero que como siempre te haya parecido interesante y te haya podido ayudar para tu dia a dia con XenServer. Saludos
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Esta semana, en el blog de virtualización y cloud computing en español, os explicare a ver los detalles de los metadatos en los volumenes VMFS via comando con vmkfstool en tu entorno VMware vSphere
Hasta el próximo martes, donde os mostraré otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.
En unos meses estará disponible el curso oficial vSphere 5 Optimize & Scale.
Este es el nombre que VMware le ha dado a la segunda parte del vSphere 5 ICM, un curso que empieza donde el vSphere 5 ICM finaliza.
Os describo parte de su contenido:
Configuración de la vMA.
Trabajando con los comandos esxcli y vicli.
Configuración de syslog server.
Configuración de Switches Distribuidos.
Comandos CLI para la configuración de red.
IPv6, SNMP, NetQueue, DirectPath I/O, PVLAN y Network I/O Control.
Configuración de sniffers de red.
Análisis de problemas de rendimiento en redes.
Configuración de policy-driven storage.
VAAI y VASA.
Configuración Storage DRS y Storage I/O Control.
Análisis de problemas de rendimiento en almacenamiento.
Host Profiles y vCenter Server Linked Mode.
Análisis de rendimiento de CPU y Memoria.
Configuración de DPM, Auto Deploy y Image Builder.
Introducción a PowerCLI.
Resolución de problemas en clusters.
Tendrá una duración de 5 días completos, como vSphere 5 ICM, con un 50% del tiempo de teoría y un 50% del tiempo de laboratorios.
Este curso prepara para la obtención de la certificación VCAP5-DCA.
El nombre definitivo del curso aún puede cambiar, pero el contenido está definido.
¿Qué diferencia existe entre el ICM, el FastTrack y este nuevo curso?
En una escala de contenidos del 0 al 10, podríamos reflejar el contenido de cada curso como:
¿Qué os parece? ¿Os lo vais a perder? Tanto ICM como FastTrack empiezan de 0, y Optimize & Scale empiezan donde acaba ICM.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, buenas tardes. Soy José Mª Gris y estamos en crónica de alcance entre presentaciones de Office 365 y las nuevas generaciones de HP y Dell.
Hoy vamos a salirnos un poco del ecosistema para hablar de Windows Intune, que no tiene nada que ver con office 365. Windows Intune es una suite que nos ayuda a administrar y proteger nuestros equipos a través de una combinación de servicios en nube de Windows y actualización de licencias (Technet)
Con las licencias de Intune, nos vendrá por cada una de ellas una licencia de Windows 7 Business, que podremos utilizar (o no, si tenemos nuestro xp funcionando todavia). Desde una consola en browser podremos ir descubriendo nuestros equipos, conociendo de primera mano el inventario hardware y software de cada uno de ellos.
Interesante la funcionalidad de Bitlocker que asegura la confidencialidad de nuestra información en nuestro portátil, bloqueando antes de arrancar el SO.
Estos equipos podremos crear unas políticas basada en WSUS para sus actualizaciones y mantenimiento, a la vez que les podremos incorporar y gestionar los agentes de Endpoint Protection. Todo este sistema nos gestionará una serie de Alertas que nos indicarán el estado general de nuestro parque.
Podremos crear unas directivas de Firewalls de los SOs, actualizaciones y estado del malware. Igualmente podremos generar una serie de informes con una profundidad importante.
Por último, contiene la funcionalidad de asistencia remota desde nuestro helpdesk a los usuarios. El precio del que dispongo en este momento es de 11$ por equipo/mes. Hay que hacer números.
Hasta la semana que viene. Take care
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hoy, en la sección de XenServer continuaremos con la configuración de nuestro Disaster Recovery utilizando las herramientas que incluye XenServer.
La semana pasada vimos como exportar los metadatos de nuestras máquinas virtuales a un Storage Repository y hoy continuaremos con la automatización de esta tarea y veremos cómo podemos exportarla a un fichero local.
Para poder automatizar el proceso de exportación es necesario disponer de como mínimo un XenServer 5.0. A partir de esta versión, podemos seguir los siguientes pasos.
Abrimos la xsconsole de un servidor de nuestro pool y accedemos a la sección “Backup, Restore and Update” y entramos en “Schedule Virtual Machine Metadata”
Seleccionamos la periodicidad que queremos aplicar a nuestro pool (por ejemplo: “Weekly”)
En este momento ya tendremos automatizado el backup de nuestros metadatos, ahora veremos como guardar los metadatos de las máquinas virtuales en ficheros “planos” para su posterior importación en el entorno de Disaster Recovery.
El comando siguiente, nos va a generar N ficheros metadata.bck1, metadata.bck2… metadata.bckN en función del número de máquinas virtuales que tengamos:
Con esto, me despido por hoy. Espero como siempre, haber podido explicarte algo nuevo que sea útil para tu entorno XenServer. Saludos
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Esta semana, en el blog de virtualización y cloud computing en español, os explicare a monitorizar un entorno VMware vSphere en busca de cuellos de botella con una herramienta espectacular de monitorizacion llamada VMturbo que ademas es gratuita. ¿Qué mas puedes pedir, eh?
Hasta el próximo lunes, donde os mostraré otro video tutorial relacionado con la virtualización y la nueva versión de VMware vSphere 5.
¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
Hola amigos, soy Florián Murillo y aquí estoy, como cada viernes.
La semana pasada, Cisco presentó novedades en su arquitectura de Datacenter, concretamente en los servidores Cisco UCS. Parece raro hablar de servidores y Cisco en la misma frase pero, en los últimos años, la visión global de Cisco les ha permitido hacerse un hueco en este mercado tan competitivo, donde tenían una experiencia y cultura nula, pero con una visión global muy clara y recursos para llevarla adelante.
Las novedades son de amplio espectro. Van desde la integración de los Cisco UCS formato rack (clase C) con los Cisco UCS formato blade (clase B), hasta nuevos Cisco Nexus 3000 con latencias de microsegundos.
Pero de todas las novedades, algunas marcarán una tendencia a seguir por la competencia, son las siguientes:
Cisco UCS VIC 1280
Es un módulo de red para Cisco UCS clase B que proporciona una conectividad de 2x40Gbps. Posiblemente la primera solución de esta velocidad para este tipo de productos, aunque se esperan novedades de otros fabricantes para dentro de muy pocos días.
Cisco UCS 2204XP
Módulo de red para los chasis de blades de Cisco UCS con 4x40Gbps. Es una necesidad si utilizamos el Cisco UCS VIC 1280. Con este módulo tenemos un ancho de banda por chasis de 160Gbps !!!
Cisco UCS B200 M3
Servidor blade con los recién presentados procesadores Intel E5-2600 con 2 sockets, 8 cores/socket y con hyperthreading.
En definitiva potencia, potencia y potencia. Quien pensaba que Cisco, al desconocer el mercado de servidores, no podría seguir el ritmo de la competencia, se equivocaban… yo el primero.
¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.
