Esta semana veremos las diferencias entre la virtualización basada en hipervisor y la virtualización basada en host.

La virtualización basada en hipervisor (también denominada Bare-Metal), como por ejemplo vSphere™ ESXi, Microsoft Hyper-V o Citrix XenServer, está instalada en un servidor físico sin la necesidad de que exista un sistema operativo (Windows o Linux) instalado previamente.

No obstante, la virtualización basada en host, como por ejemplo VMware Server, VMware Workstation o VMware Fusion, necesita previamente un sistema operativo instalado, ya sea Microsoft Windows, Mac OS o Linux.

Hay varias razones por las que un cliente elegiría el software de virtualización basado en hipervisor, como por ejemplo vSphere™ ESXi, en lugar de un software de virtualización basado en host, como por ejemplo VMware Server.

• Primero, con el software de virtualización basado en hipervisor, es posible actualizar las máquinas virtuales que se albergan en los servidores físicos sin ningún tipo de downtime.
• Segundo, es muy probable que la empresa ya esté virtualizando varios servidores físicos y quiera tener la opción de tener una gestión centralizada.
• Por último, un hipervisor baremetal siempre ofrece una mayor confiabilidad y rendimiento al no precisar de un sistema operativo Host, con lo cual se elimina un posible punto de fallo.

Aunque la virtualización basada en hipervisor ofrece un mayor rendimiento, es la virtualización basada en host la que ofrece una compatibilidad con el hardware mucho más amplia, es decir, si puedes instalar Windows o Linux en tu servidor físico entonces podrás instalar la solución de virtualización basada en host.

Por consiguiente, una de las mayores diferencias de la solución de virtualización basada en hipervisor y la solución de virtualización basada en host – aparte de las obvias ya mencionadas – , es que esta última tiende a tener una lista de hardware certificado mucha más amplia.

Sin embargo, la virtualización basada en hipervisor tiene un mayor rendimiento, mayor fiabilidad y estabilidad, mayor escalabilidad y mucha más funcionalidad. Para ver más información sobre los tres factores más importantes a la hora de elegir un hipervisor para el software de virtualización entra en este enlace:

Asimismo, y a diferencia de las versiones anteriores a VMware vSphere™ ESXi,  las variables memoria reservada y memoria configurada (Reserved Memory y Configured Memory) afectan al incremento o reducción del memory overhead, el cual es una “penalización” a nivel de la capa de memoria que todos tenemos que pagar por el simple hecho de virtualizar nuestro servidor físico. Esta penalización se mide en megas de memoria RAM y son megas de memoria que dejamos de ver y de usar en nuestro servidor físico.

Como consecuencia de este “impuesto revolucionario” que existía por el simple hecho de virtualizar nuestro servidor, VMware vSphere™ ESXi 5 usa una nueva funcionalidad llamada VMX swap con la que es posible reducir el memory overhead de tus máquinas virtuales. Puedes ver un video tutorial sobre el Memory Overcommit en VMware vSphere 5 en este enlace.

Básicamente, con esta nueva tecnología llamada VMX swap, el tamaño del memory overhead se crea en un fichero swap con lo que este espacio de memoria puede llegar a ser reutilizado por el hipervisor. Esta técnica posibilita un aumento en el ratio de consolidación de VMware vSphere™ 5 con respecto a versiones anteriores para soluciones de virtualización basados en hipervisor.

¿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 Ferran Serafini y hoy os enseñaré a instalar un Ubuntu 10.04 LTS paravirtualizado partiendo de una instalación HVM para nuestro entorno XenServer.

XenServer ya viene preparado para instalar Ubuntu. El método que voy a usar en este post quizá no es el más sencillo y rápido pero podremos ver muchos puntos interesantes y sobretodo la diferencia entre HVM y PV.

Lanzamos “New VM” usando el template “Other Install Media”. La llamaremos Ubuntu-HVM

La seleccionamos de nuestro repositorio de Isos donde previamente hemos descargado la ISO.

De CPU/Memoria se  puede poner lo que uno quiera, por ejemplo 2 CPUs i 512 MB de Ram. Posteriormente creamos su disco duro virtual

Finalizamos la configuración de la máquina virtual y arrancamos la máquina virtual siguiendo el asistente de instalación de una Ubuntu normal.

A modo de consejo personal, prefiero poner la swap en la primera partición del disco, de modo que el sistema este instalado en la ultima partición, así, en el momento que haga falta extender el disco de la maquina virtual por falta de espacio, simplemente haciendo un resize2fs redimensionariamos la partición.

Otro dato muy importante es que pygrub no soporta ahun EXT4, por lo tanto la particion /boot tiene que ser EXT3.

Ya tenemos nuestra Ubuntu 10.04 HVM. Ahora vamos a paravirtualizarla. Para ello, entramos como root y nos “guardamos” algunos datos que necesitaremos para la parametrización siguiente.

Las nuevas versiones de Ubuntu vienen ya con el nuevo grub-pc, accedemos al fichero /boot/grub/grub.cfg y localizamos las siguientes líneas ya que este no es “leíble” para pygrub:

### BEGIN /etc/grub.d/10_linux ###

menuentry ‘Ubuntu, with Linux 2.6.32-33-server’ –class ubuntu –class gnu-linux –class gnu –class os {

recordfail

insmod ext2

set root=’(hd0,1)’

search –no-floppy –fs-uuid –set 115a8cea-b9ac-4ecc-bc2e-3f172630cdc8

linux    /boot/vmlinuz-2.6.32-33-server root=UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro   quiet

initrd   /boot/initrd.img-2.6.32-33-server

Ejecutamos la siguiente línea para especificar que la consola virtual de la maquina sera hvc0 y no tty1 para que podamos usar la consola de la maquina virtual de XenCenter.

sed -e “s/tty1/hvc0/ig” /etc/init/tty1.conf | sudo bash -c ‘cat > /etc/init/hvc0.conf’

Apagamos la máquina virtual.

El siguiente, totalmente opcional, consiste clonar la máquina virtual. Para no confundirnos, la renombramos el clon a Ubuntu-PV.

En el domain0 ejecutamos lo siguiente:

# xe vm-list name-label=Ubuntu-PV

uuid ( RO)           : fce7a414-4475-4875-0af0-632b4a8d6d03

Localizando así el uuid nuestra máquina virtual

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-policy=”"

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-params:”"

Con esto habremos eliminado los parámetros que interpreta XenServer para arrancar la máquina virtual como HVM.

Añadimos ahora los parámetros que vimos en el grub para arrancar  de forma paravirtualizada:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-args=”root= UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro quiet console=hvc0 xencons=hvc0″

Utilizaremos pygrub para arrancar la máquina virtual:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader=pygrub

Como pygrub no es compatible con las nuevas versiones de grub, especificamos el kernel y el ramdisk directamente.

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader-args=”–kernel=/boot/vmlinuz-2.6.32-33-server –ramdisk=/boot/initrd.img-2.6.32-33-server”

Esta configuración del PV-bootloader-args hay que modificarla cada vez que se cambie/actualice el Kernel de la máquina virtual.

Con esto, arrancamos nuestra máquina virtual y ya la tenemos totalmente paravirtualizada. Vera un incremento de rendimiento muy interesante y estarás aprovechando toda la potencia de Xen. Ahora solo falta instalar las XenTools y convertir como template.

Eso es todo por hoy, espero como siempre, haberte enseñado algo útil para hacerte tu día a día con XenServer más sencillo y eficaz.

¿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. Las novedades aparecidas en la versión 1.4 (incluyo la 1.4a) de Cisco Nexus 1000V son importantes y a continuación detallaré las más destacadas desde mi punto de vista:

Cisco vPath: Es una novedad de la versión 1.4 y, su sola presencia, justifica la nueva versión.

Se integra con los VEM, por tanto se instala en todos los host que participan del switch distribuido.

Su misión es interceptar el tráfico, interrogar a los Virtual Service Nodes y ejecutar las políticas definidas. Los Virtual Service Nodes existentes en este momento son: Cisco vWAAS, el Cisco VSG y el Cisco ASA 1000V.

Class-Based Weighted Fair Queueing (CBWFQ): Es la respuesta de Cisco al Network Resources Pool de los switches distribuidos de VMware.

Las características destacadas de CBWFQ son:

• La estrategia de colas permite que una clase de tráfico no impida otros tráficos.
• Respeta el ancho de banda garantizado para cada clase de  tráfico.
• Optimiza la utilización del ancho de banda.

Dispone de varios protocolos ya definidos: vMotion, FT-Logging, iSCSI, NFS, ESX Management, N1K Control, N1K Packet y N1K Management.

Compatibilidad con vSphere 5: En la versión 1.4a de Cisco Nexus 1000V nos encontramos con soporte para vSphere 5, es importante, en especial si pensamos en migraciones futuras de arquitecturas existentes.

El resto son mejoras de funcionalidades ya existentes, algunas de ellas muy demandadas a nivel de seguridad. Por ejemplo la posibilidad de poner ACLs en el interfaz de gestión del switch distribuido, ya que el firewall de ESXi no lo contempla.

¿Qué nos depara el futuro de Cisco Nexus 1000V?

Apertura a nuevas plataformas de virtualización, VXLAN y otras sutilezas que llegarán pronto… Pero de eso hablaremos mas adelante.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo. Gracias.

¿Hola, que tal? Soy Jose Mª Gris y como cada miércoles estoy aquí con vosotros para hablar del ecosistema.

Je, viendo el título del post trae a la mente lo de “El sentido de la vida” de Monty Python, gran película, pero no, no va por ahí. O quizás sí, veremos.

Lo cierto es que a partir del post de Cloudarray he recibido varios mails sobre él. Algunos de vosotros se han ofrecido para los tests que estoy pensando hacer, compañeros que en persona me han dado su opinión o sus ganas de “poner la mano” sobre el producto.

Pero todos en algún momento me han expresado “¿Hasta donde llega en performance?”, y si no llega, que sentido va a tener un producto así.

Reconozco que bastantes ratos he pasado pensando en ello. Cuando más o menos lo tenía controlado he tenido la suerte de cenar con mi buen amigo Said Boukhizou, TAM para el sur de Europa de Datacore (otro día os lo presentaré con más tiempo) y fue una gran oportunidad de contrastar ideas.

Cloudarray es un sistema de almacenamiento en Cloud. Gestiona de forma sencilla la interface del target iSCSI por un lado para simplificarlo, y por otro lado los proveedores de storage en la cloud. ¿Y que hace en medio? Pues monta un Proxy-caché en local, que va enviando los datos a la nube.

Bien, eso ya nos da una idea de por donde van a estar los límites que nos vamos a encontrar en primer lugar. En el momento que el caché esté lleno, el rendimiento va a ser más lento y nuestro gozo en un pozo.

Claro (como dice Said) que en el fondo en tu instalación también tienes bloques que no son tan “calientes”, que son bastante o muy “cold”. Esa temperatura viene dada por el nivel de utilización que hacemos de estos bloques. Entramos en el concepto de “Tiering” de nuestros recursos de SAN.

En estos momento, lo óptimo es tener:

• Tier 1.  Recursos SDS y a poder ser en un canal ultra rápido de acceso.
• Tier 2.  Resusrsos SAS con acceso FC
• Tier 3.  Recursos “Near SAS” o “SATA”
• Tier 4.  Recursos “Cloud” como CloudArray.

Si a esto le sumas la nueva funcionalidad de Datacore de hacer “Autotiering”, tienes el cuadro completo.

No hay nada bueno ni malo, sencillamente hay que tener lo adecuado para cada caso. Tier 4 nos puede servir para  aquellos accesos que nos interese tener de forma “cold”, mientras que en nuestro Tier 1 o Tier 2 tendremos lo que se hace un uso intensivo.

Bueno, pues ya tenemos una información de partida para nuestros test J, que no es poco.

Continuaremos informando. “Stay tuned”. Take care.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigo, hoy vamos a ver un repaso de las posibilidades disponibles de almacenamiento que tenemos para Citrix XenServer.

Veremos sus pros y sus contras para determinar cual puede ser nuestra mejor opción.

Las opciones que tenemos para un SR son:

Veamos las propiedades de cada una de estas tecnologías.

Local Storage: Por defecto XenServer utiliza los discos locales para poder almacenar máquinas virtuales. Utiliza LVM implementando el formato VHD para los VDIs. VHD permite que los discos sean sparse y que el espacio se vaya reservando en función del crecimiento de los discos de las máquinas virtuales. En las versiones 5.6  y 6.0 se implementa también thin provisioning, para el uso de escritorios vdi con XenDesktop. Fundamentalmente la ventaja principal es que según el Host físico y el tipo de disco, ofrecen un rendimiento superior, sobretodo si se usa discos en estado sólido. El problema es que no pueden ser compartidos como recurso de cluster y las máquinas virtuales instaladas en un disco de un host en local, no serán accesibles por los otros hosts del Pool.

Rápido y optimización de espacio. Pero no puede ser compartido por otros hosts.

NFS: XenServer soporta NFS3 por TCP/IP y permite crear SRs implementando VHD por lo tanto también son óptimos en cuanto a la optimización de espacio. A diferencia del disco local NFS es montado como recurso compartido del Pool y cualquier host puede acceder los VDIs almacenados en este tipo de recurso. Lo bueno también del NFS es lo estándar que es en el mundo UNIX/Linux, que por lo tanto hay multitud de appliances que permiten su gestión simplificada y no hace falta obligatoriamente disponer de una cabina de discos para trabajar en un entorno cluster.

Optimiza el espacio de disco “sparse”, gestión simplificada. Hay que vigilar que no sobrepase el espacio que hemos asignado, pues las VM crecen.

iSCSI: La utilización de iSCSI en XenServer permite  una implementación de los discos compartidos muy eficiente a nivel de red a bajo coste. Para ello hemos de configurar nuestra cabina de disco para presentar las LUNs que posteriormente se utilizaran como SRs. Una vez configurado se presenta al sistema como LVM donde los diferentes VIDs tendran un volumen lógico asociado. Los VDIs no pueden ser “sparse” y siempre ocuparan el espacio que hayamos definido en la creación del disco. Parecido a los discos tick de VMware.

Muy óptimo a nivel de red y por lo tanto muy buen rendimiento de disco para las máquinas virtuales. Se desaprovecha espacio al no ser discos dinámicos y a su vez ofrece mejor control del disco usado/libre.

Fibre Channel: Funciona en XenServer de forma parecida que iSCSI y disco local,  los discos son VHD corriendo sobre volúmenes lógicos LVM. Hay que disponer de HBAs compatibles con XenServer como Qlogic, Emulex, etc.

Alto rendimiento y optimización de espacio. Hay que tener HBAs compatibles con XenServer.

StorageLink: Sin duda la mejor opción si dispones de un licenciamiento Enterprise o Premium y tu cabina es Citrix Ready o si usas NexentaStor como appliance. StorageLink se define como la capa de interoperabilidad nativa entre XenServer y nuestra cabina de discos. Por lo tanto nos permite realizar clones súper rápidos, snapshots, thin provisioning en la propia cabina desde XenCenter.

Pensado como la solución más avanzada, es la mejor opción si necesitas un entorno de muchas máquinas y funcionalidades extra más allá del alojamiento de VDIs

Conclusiones: Principalmente, en mi modesta opinión, depende del presupuesto destinado y a la dimensión del entorno. Si estas usando una infraestructura de 4-6 nodos con unas 40 VM, un storage iSCSI contra una cabina de discos, funciona perfectamente. Si tienes de 2-3 servidores y no tienes cabina de discos, con una buena maquina sirviendo NFS funcionaría perfectamente. Y si tienes de 50 a 100 Hosts, con XenDesktop, muchos templates y una buena cabina, sin duda StorageLink.

¿Qué tecnología de almacenamiento utilizas en tus entornos?

Eso es todo por hoy amigo, espero como siempre que haya podido aportarte un granito de arena a tus conocimientos sobre la virtualización de servidores con XenServer.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola de nuevo! Soy Miguel Ángel Alonso y aquí estoy como cada martes para contaros algo nuevo sobre el genial mundo de la virtualización de servidores.

En el día de hoy vamos  a hablar de un documento importantísimo para aquellos que desarrollamos escritorios virtualizados en nuestra labor del día  a día, y de  cómo podemos sacar el máximo rendimiento a nuestro entorno con el menor esfuerzo posible.

Está a la vista que a  VMware le gustan este tipo de documentos (white paper) y las mejores prácticas sobre VMware View 5.

Con el reciente lanzamiento de VMware vista 5 durante el  VMworld 2011en Las Vegas, han sido introducidas muchas nuevas características y mejoras para este producto.

El documento (White Paper) muestra las diferencias entre VMware View 4.5 y 5 y no sólo por el lado del mero producto en sí, sino también desde el punto de vista de la plataforma central de virtualización (vSphere), ya que la comparación se hizo con VMware View 5 ejecutándose en vSphere 5 y View 4.5 sobre vSphere 4.1, ya que no es posible ejecutar View 5 en vSphere 4.1 .

Para generar una  carga real de trabajo a la solución de software, se utilizó VMware View Planner, que es un generador de carga de trabajo muy similar a VSI Login (artículo escrito por mí el 25 de enero de este año).

Simula  a un usuario de oficina habitual, que está utilizando las aplicaciones de oficina básicas como MS Word, PowerPoint, Outlook, navegación por las páginas PDF, navegación por páginas Web y viendo un video.

Una sección muy interesante es la sección de prácticas recomendadas donde verás los ajustes necesarios que deben hacerse del lado de la VM maestra o Gold (un sistema XP o Win 7) y también sobre la/s GPOs del Directorio Activo, mediante la deformación del Protocolo de PCoIP y otros componentes para lograr el mejor rendimiento posible.

También en este documento encontrarás la comparación entre diferentes protocolos: ICA, RDP v 7.0 y PCoIP en diferentes entornos. LAN, WAN y  WAN tipo extrema. La WAN extrema es la WAN con alta latencia y ancho de banda muy reducido.

LAN: Abundante ancho de banda disponible con casi ninguna latencia.

WAN: El ancho de banda es limitado (2 Mbps) y hay 100 ms de latencia ida y vuelta.

WAN extrema: El ancho de banda es severamente limitado (300 kbps) y hay 100 ms de latencia en la ida y la vuelta.

En resumen, el artículo nos va enseñar cómo mejorar nuestro entorno para conseguir unos resultados espectaculares con VMware View trabajando en nuestro entorno VDI disminuyendo el tiempo de respuesta, el consumo de ancho de banda, CPU y Memoria.

Podéis descargar el artículo aquí. A mi modo de entender es un artículo imprescindible para todos aquellos que nos movemos o dedicamos al mundo de la virtualización de escritorio y más en concreto con VMware View.

Aquí os dejo algunos de los resultados más importantes de los test realizados, una vez hemos aplicado las mejores prácticas del documento.

Hasta aquí por hoy, espero haberos contado algo de vuestro interés y os emplazo hasta la semana que viene con un nuevo tema sobre el mundo de la virtualización de servidores. Hasta la semana que viene!

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Esta semana, en el blog de virtualización y cloud computing, te enseñare a instalar un servidor VMware vSphere ESXi 5 con la utilidad VMware Update Manager 5.

Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y el cloud compuitng en español: ¿Cómo instalar vSphere ESXi 5 con VMware Update Manager? Espero que te guste.

Nos vemos el próximo lunes con un próximo episodio donde te enseñare, otro video tutorial sobre la virtualización y el cloud computing en español.

¿Crees que este videopost le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.

Hola amigos, soy Florián Murillo. Estamos en un entorno muy cambiante, tanto que lo DICHO este mes puede quedar obsoleto el mes próximo… Por ese motivo, durante las próximas semanas, desarrollaré el estado ACTUAL de las tecnologías Cisco relacionadas con el Virtual Networking.

¿Qué es Virtual Networking?

Es la virtualización de la capa de acceso de switches; aquellos switches donde están conectados los servidores que también vamos a virtualizar.

O lo que es lo mismo: Los switches virtuales donde están conectados los servidores (ahora virtuales).

Se esquematiza en la figura siguiente:

Esto es lo que hace que los responsables de configurar los switches físicos a los que se conectarán los hosts ESX/ESXi deban pensar en estos hosts como switches, ya que en realidad están conectados a switches (virtuales).

Características únicas de los switches virtuales:

1. Los switches virtuales no se pueden apilar entre ellos, solo podemos conectar a un switch virtual interfaces físicos del host, las vNICs de las VMs y los puertos de servicio del kernel (vmk y vswif).
2. Los switches virtuales no tienen spannning-tree (STP), por tanto recordar deactivar STP en los puertos de los switches físicos donde se conectan los hosts ESX.
3. Los switches son de nivel 2 (L2), es decir, requieren “ayuda” externa para encaminar tráfico entre VLANs.

Cisco entra en el Virtual Networking con la llegada de vSphere 4 y concretamente utilizando la vNetwork Appliance API.

El switch virtual distribuido (dvSwitch) es un elemento básico para la implantación de grandes infraestructuras virtuales y, por extensión, para el despliegue de soluciones IaaS bajo el modelo de cloud computing. El elemento diferencial es su arquitectura. Las configuraciones se despliegan automáticamente a todos los hosts que participan en el dvSwitch, sin necesidad de repetir el cambio host por host, como ocurre con el vSwitch clásico de VMware.

El dvSwitch aporta funcionalidades nuevas respecto a los vSwitches, que podemos resumir en Seguridad, QoS, Gestión y Arquitectura abierta.

Cisco basa su arquitectura de Virtual Networking en Cisco Nexus 1000V, que incorpora características adicionales respecto dvSwitch.

Desde su aparición en el 2009, han aparecido productos que extienden las funcionalidades de Cisco Nexus 1000V, como son:

• Cisco Virtual WAAS
  • Solución de aceleración WAN y balanceo.
• Cisco Virtual Security Gateway
  • Solución de firewall por zonas, de forma que tengamos varios servicios de clientes diferentes en el mismo segmento de red y poder definir que se puede ver y por quien…
• Cisco ASA 1000V (que describimos la semana pasada)
  • Firewall perimetral y de filtrado entre VMs dentro de una zona.

Estos elementos se complementan con funcionalidades y soluciones clave:

• Cisco Nexus vPath
• Cisco Virtual Network Management System

En los próximos post, hablaremos de las novedades que nos aporta cada producto, empezando por la base: Cisco Nexus 1000V y Cisco Nexus vPath. ¿Qué opináis de la estrategia de Cisco en el tema Virtual Networking?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de abajo. Gracias por el apoyo.

Hola, amigos soy Ferran Serafini y hoy vamos a montar un entorno Citrix XenServer con almacenamiento compartido con FreeNAS.

Como sabéis aparte de FreeNAS hay muchos appliances destinados a ofrecer almacenamiento compartido de forma fácil, pero por su robustez y fácil configuración, he elegido FreeNAS, es muy útil para montar entornos de desarrollo o bien por si no podemos optar a una cabina de discos por presupuesto, en tiempo récord.

También permite la exportación a través de NFS o CIFS, pero en este caso vamos a presentar los discos mediante el protocolo ISCSI.

Primero de todo, nos descargamos la iso de FreeNAS en aquí. La arrancamos en modo (live) y la instalamos. Es muy sencillo. Podemos ver los pasos de la instalación aquí

Ahora es el momento de acceder a su página de administración

Vamos a configurar una LUN para ser servida a través de ISCSI para luego añadirla a nuestros servidores XenServer en 7 pasos.

1. Configuración Base
2. Extender Dispositivo (“LUN”)
3. Configurar Iniciador
4. Configurar Portal
5. Configurar Destinos
6. Destino / Disco
7. Iniciar ISCSI

Configuración Base

Primeramente configuramos el Nombre Base en la parte global de la configuración de ISCSI.

Nombre Base -> iqn.2011-03.fsmlab.org.istgt

Extender Dispositivo (“LUN”)

Configuramos el disco que vamos a servir como LUN en Extender Dispositivo

Configurar Iniciador

Ahora configuramos el inciador, vamos a permitir acceso para todos.

Configurar Portal

Para permitir el acceso a una IP o bien a cualquier IP del servidor FreeNAS hay que definir como mínimo un portal. Por defecto:

Portal -> 0.0.0.0:3260

Configurar Destinos

Para poder servir esta LUN, tenemos que definir que destinos vamos a presentar dicha LUN. Configuramos el destino con el/los IQN de nuestros XenServer:

Para ver el IQN de un servidor hacemos:

cat /etc/iscsi/initiatorname.iscsi

Disco/Destino

Tenemos que establecer la relación entre el destino y el disco (Extensión).

Iniciar ISCSI

Ahora ya solo falta arrancar el servicio desde Servicios-> Control de Servicios -> ISCSI = ON

Ya tenemos la parte de disco compartido finalizada, solamente hay que añadir esta LUN a nuestro Pool.

Pues esto es todo por hoy, espero como siempre que te haya parecido interesante y haberte podido ayudar en tus pasos por el mundo de la virtualización. Un saludo

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Esta semana, en el blog de virtualización y cloud computing, te enseñare a instalar y actualizar las VMware tools y hardware virtual dentro de tus máquinas virtuales con VMware Update Manager en la nueva versión de VMware vSphere 5.

Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y el cloud compuitng en español: ¿Cómo instalar VMtools y el hardware virtual de tus máquinas virtuales? Espero que te guste.

Nos vemos el próximo lunes con un próximo episodio donde vereomos otro video tutorial sobre la virtualización y el cloud computing en español.

¿Crees que este video tutorial sobre la virtualización con VMware vSphere le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.