¿ Por qué instalar VMware ESXi sobre VMware Player?

Quizás …

 

… te estés preparando una certificación de VSphere y necesitas un entorno de aprendizaje.

… eres sysadmin y quieres un entorno de pruebas.

… vas a realizar una actualización en breve de tu entorno VSphere 3.X/4.X y quieres conocer la nueva versión.

… por gusto.

El entorno usado para la instalación es un PC con las siguientes características:

 

CPU: AMD Phenom(tm) 9650 Quad-Core Processor

RAM: 8 GB DDR2 (800MHZ)

SO: Ubuntu 11.10 versión Desktop

Kernel: Linux nas 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 17:23:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

El proceso de instalación es fácil y sin complicaciones a diferencia de versiones anteriores. Enumerándolas son las siguientes:

1. Descarga de VMware player en su versión 4.0.2

Enlace de descarga

2.Instalar VMware Player

Desde un terminal ejecutar instalador:

# ./VMware-Player-4.0.2-591240.x86_64.bundle

Por defecto, aceptas licencias y demás preguntas finalizando con la siguiente salida:

Extracting VMware Installer…done.

3.Descargar la iso de ESXi5

Enlace de descarga

Recuerda que para la descarga  se te proporcionará una licencia gratutita  que necesitarás después de pasar el tiempo de pruebas (60 días), apúntala …

4. Creación de la máquina virtual ESXi en VMware Player

Desde el menú de VMware Player utiliza la opción de crear nueva máquina virtual (Create New Virtual Machine). El wizard pedirá una serie de detalles de la configuración de la nueva máquina entre ellas destaco:

Instalación desde iso apuntando al fichero que nos hemos descargado en el punto 3, el tipo de Sistema Operativo "Other" que por defecto al leer la iso lo rellena como "Custom (VMware ESXi 5)":

Una vez finalizada la creación de la máquina virtual, ántes de arrancarla, aconsejo ajustar la siguiente configuración Hardware (a título informativo):

CPU: 2 cores y activar la opción de "Virtualize Intel VT-x/EPT o AMD-v/RVI".

RAM: 2GB ( o más)

RED: Modo Bridge (para que coja la primera IP por DHCP)

Las "Best Practices" para parametrizar tu instalación la puedes encontrar aquí.

5. Instalador de ESXi

El primer arranque se producirá desde CD ( iso en la máquina virtual) que cargará el instalador de ESXi. La información que solicita es trivial y se completa en menos de 4 minutos … dejo a continuación unos pantallazos del proceso de instalación:

ESXi 5 Menú de arranque del instalador

ESXi 5 arranque de la instalación

ESXi 5 Cargando ...

ESXi 5 Mensaje de Bienvenida

ESXi 5 Disco de Instalación

ESXi 5 Confirmar la instalación

ESXi 5 Finalización de la intalación

Después del reinicio, al final del primer arranque,  informará de la IP que tiene el nuevo Host creado con ESXi 5.

Para conectarse desde una máquina Windows puedes acceder a través de un navegador a la IP de la máquina virtual ESXi 5 y desde allí descargar el cliente de administración de VSphere e instalarlo …

ESXi 5 Cliente VSphere

Se me ocurren muchas posibilidades con esta instalación por ejemplo:

- Instalar un vcenter en una máquina virtual o física para gestionar un clúster de ESXi.

- Duplicar ésta máquina virtual, cambiándole la IP y el  Hostname, según la posibilidades de tu equipo se podrían replicar varias veces …

- Usar un almacenamiento externo tipo iSCSI (físico o virtual) descrito en posts anteriores para convertirlo en un Datastore vmfs, con multipath, balanceo round robin, …. recordar que VMware certifica los targets de almacenamiento SCST.

- Todas las posibilidades para aprender en tu entorno de pruebas ….

Se ha creado el proyecto QUADSTOR como solución  que proporciona almacenamiento virtualizado. Con base en FreeBSD, añade una interfaz gráfica  web para la administración sencilla de almacenamiento. Basado en el proyecto IET portado por ellos mismos a FreeBSD, permite crear lunes (VDISKs) y ofrecerlas por fibra o iSCSI con características propias de almacenamiento enterprise actual: deduplicación, thin provisioning, soporte VAAI (vStorage APIs for Array Integration) para VSphere 5, además de proporcionar CIFS y NFS.

El proyecto se encuentra en la actualidad en fase beta y se puede usar en universidad y empresa libremente, pero … ni se puede distribuir, ni realizar ingeniería inversa previo a su consentimiento.

Mantener varios centenares de equipos de una red es una labor tediosa donde las haya. Los comportamientos impredecibles de los equipos que corren Windows, su mantenimiento, con la responsabilidad del buen funcionamiento de aplicaciones particulares y de los grupos de trabajo, hace necesario por parte de la Administración de Sistemas tener que adquirir algún software de coste elevado para su administración centralizada que permita:

- Actuar en remoto sobre un ordenador concreto

- Inventario automático de hardware y software

- Mantenimiento e Instalación centralizada de software

- Copias de seguridad en caso que haya que reinstalar el Sistema Operativo

… citando las  más importantes. Aunque algunas funciones básicas si pueden ser realizadas desde el Dominio Activo que además de encargarse de la autenticación en la red, dispone de un grupo de GPOs a través de las cuales se pueden automatizar muchas tareas de forma centralizada. No siendo suficiente se necesita ese nivel que aportan las herramientas referidas que unifican en una consola de administración todas las tareas de mantenimiento software y soporte.

Después de leer unos artículos en la web de mi amigo Javi relacionados con un software licenciado parcialmente bajo GPL, integrador de varios proyectos de gestión y mantenimiento de software ( puedes verlo aquí)   llamado OPSI, me puse manos a la obra hasta tenerlo operativo.

Aparte de las características citadas, se puede realizar prácticamente de todo ya que hablamos de un servidor Linux que accede a las tripas de todos los equipos Windows de la red. Una herramienta así en manos de alguien que le gusta la consola y el scripting le sacará todo el partido que se proponga. A fin de cuentas Opsi en su mayor parte es una adaptación de herramientas de distribución de software en Linux para redes Windows.

OPSI me llamó mucho la atención desde que hice la primera instalación en red de un Windows XP hasta ahora, realizando backups de los perfiles de usuarios en los equipos en red, formatea e instala el SO  junto con aquellos paquetes de software a elección, ubicación en la unidad organizativa del dominio para la ejecución de las GPOs correspondientes, todo de forma estable, cómoda y "automática" …  centralizado desde una misma consola.

Las pegas:

- Tiempo en la puesta a punto del servidor – al tratarse un proyecto alemán con soporte parcial en inglés/francés en su primera versión 4.0 tienen algunos problemas de codificación con los clientes y la adaptación a un entorno español da algún quebradero de cabeza, que ya están arreglando.

- No tiene soporte en castellano – Gran cantidad de dudas y problemas técnicos los he logrado resolver a través de su foro en alemán que además de no ser mi lengua materna ( no tengo ni idea), es el idioma con más volumen de información y en muchas ocasiones exclusiva. Así que a tirar de translator.

- La licencia parcial del código es GPL – dispone de una serie de módulos que no son gratuitos, que tras el concepto de cofundadores, no serán liberados hasta que no sean totalmente financiado por ellos, mientras tanto únicamente aquellos que hagan la donación estipulada podrán disfrutar de los módulos. Dispone de un periodo de evaluación para probar estos módulos antes de tener que pagarlos. Aún así, el precio es relativamente asequible comparándolo con aquellas soluciones equivalentes en el mercado.

En si las pegas son la excusa para conocer el producto al detalle … como siempre

Interesante review en Linux Magazine aquí.

Hoy me encontré con el siguiente problema en un entorno VSphere 4.1:

Tenía una LUN iSCSI mapeada directamente a un huésped con sistema Operativo Centos que hace las funciones de NAS, se trata de una forma de añadir un disco denominada "RAW Device Mapping" o RDM. Me dispongo a eliminar este servidor con la intención de convertir esta lun en un datastore VMFS para los hosts ESX de un clúster VSPHERE. Después de eliminar el disco RDM y la máquina virtual enganchada a éste, desde el wizard del cliente VSphere es imposible añadirlo como DataStore (Add Storage),  con el siguiente error:

Error: Call "HostDatastoreSystem.CreateVmfsDatastore"  for object; "datastoreSystem-143" on vCenter Server …… failed.

Después de googlear un poco encuentro con la solución en el siguiente blog:

http://vcpgeeks.blogspot.com/2010/03/while-adding-lun-to-esx-error-unable.html

Por lo que se ve, al añadir el disco previamente como RDM lo considera de tipo gpt y no como msdos. Lo muestro en las salidas por consola (ssh) siguientes:

[root@AGSS03 ~]# fdisk -l

Disk /dev/sdb: 73.4 GB, 73407868928 bytes
255 heads, 63 sectors/track, 8924 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         140     1124518+  83  Linux
/dev/sdb2             141         154      112455   fc  VMware VMKCORE
/dev/sdb3             155        8924    70445025    5  Extended
/dev/sdb5             155        8924    70444993+  fb  VMware VMFS

Disk /dev/sdc: 8392 MB, 8392802304 bytes
255 heads, 63 sectors/track, 1020 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         127     1020096   82  Linux swap / Solaris
/dev/sdc2             128         382     2048287+  83  Linux
/dev/sdc3             383        1020     5124735    5  Extended
/dev/sdc5             383        1020     5124703+  83  Linux

WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdd: 1800.3 GB, 1800324251648 bytes
255 heads, 63 sectors/track, 218876 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      218877  1758129151+  ee  EFI GPT

[root@AGSS03 ~]# parted /dev/sdd
GNU Parted 1.8.1
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print

Model: FSC FibreCAT_SX1 (scsi)
Disk /dev/sdd: 1800GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
1      17.4kB  1800GB  1800GB                     lvm

(parted)

 

 

 

Este problema se soluciona cambiando la tabla de partición de gpt a msdos, desde la utilidad parted con el comando "mklabel msdos":

[root@AGSS03 ~]# parted /dev/sdd
GNU Parted 1.8.1
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel msdos

Warning: The existing disk label on /dev/sdd will be destroyed and all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
New disk label type?  [gpt]? msdos
(parted) print

 

 

 

 

Model: FSC FibreCAT_SX1 (scsi)
Disk /dev/sdd: 1800GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End  Size  Type  File system  Flags

 

 

 

De esta forma ya es posible añadirlo como DataStore desde el wizard … bendito Google!

Éste procedimiento no servirá para ESXi ya que  no dispone de la utilidad parted, hay un procedimiento descrito por VMware usando la utilidad dd al final del siguiente artículo:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008886

Siguiendo con el artículo anterior que describía tecnologías para la implementación de un SAN de bajo coste, añado una interesante reseña sobre la solución de backups Backblaze. Esta empresa, formada por reputados empresarios, han hecho una propuesta de almacenamiento barato inusual, basado en un diseño del chassis de un servidor para rack de 4U con capacidad de albergar 45 discos SATA, conteniendo en total 67 teras  con un coste de 7,867$, saliendo el precio del tera a 117$.

Una comparativa del ahorro que supone esta solución:

Basada 100% en software libre:

Usada con éxito en entornos de producción, aunque tiene sus detractores que se basan en la no implementación de la especificación DIF T10 (de protocolo SCSI) o la falta de redundancia eléctrica (PSU), … hay un hilo interesante en GOOGLE GROUPS  sobre ello.

También encontré  inspiradoras modificaciones como ZFS o Alta disponibilidad.

Añado una entrada del Blog de StorageMojo que nos explica el porqué la diferencia de coste entre las soluciones SAN de los proveedores típicos de almacenamiento y la propuesta por BackBlaze, sin desperdicio …

Y por último animar a un  nuevo grupo  llamado OpenStoragePod que basados en ésta solución, investigan sobre diferentes alternativas hardware y software y cuya misión es:

“to challenge the server tax” on enterprise storage solutions

En tiempos de crisis proponemos “cocinar” una SAN a bajo precio con los siguientes ingredientes:

iSCSI

iSCSI   es una alternativa a la clásica SAN de fibra óptica, es económica su implementación ya  que no requiere de una infraestructura y tecnología adiccional Hardware de costosas HBAs y Switches de Fibra. Con sólo un switch ethernet ( o dos que aporten redundancia de acceso) y  con un servidor con tarjetas Ethernet de Gigabit junto con unos discos ya tendrías una SAN. Los initiators y targets  iSCSI en muchos sistemas operativos para servidores actuales es gratuito y ya vienen con la distribución, al igual que las soluciones de multicamino (multipath).

DISCOS

En la actualidad se diponen discos de buen precio y alta capacidad para una solución de rango medio (midrange). Un ejemplo podría ser 4 discos SATA de 3Gb/s ,  capacidad 2 TB,  64 MB de Caché y 7200 rpm  podrían salir a unos 500€. Proporcionando aproximadamente unos 6 TB en RAID software con MDADM (solución de servidores Linux de RAID software) , que nos da una media de 111 euros por Tera tolerante a fallo (RAID).

Preguntadle a vuestro proveedor de SAN cuanto saldría el TB en fibra …  

Haciendo justicia no es comparable una cabina de discos en fibra en cuanto a rendimiento debido a sus fenomenales características Hardware. Sus discos tienen un rendimiento mayor,  15.000 rpm frente a los 7200 rpm que tienen  los discos SATA, comparativamente  pueden  duplicar las I/Os y mejoras como gestión de colas o DIF T10 . En un entorno de alta capacidad frente a rendimiento, sería adecuado nuestra propuesta con discos SATA, en caso contario, incluir discos SAS  con una controladora  será una alternativa  más adecuada.

RAID

La tecnología RAID Hardware dejó de ser hace años exclusiva de entornos enterprise y cualquier placa de PC lleva integrado una controladora de discos SATA con soporte de RAID 0,1,5.  Por otro lado los resultados del RAID por software (MDADM, ZFS, …) y los gestores de volúmenes (Logical Volumen Manager – LVM ,Solaris Volumen Manager – SVM ,Veritas Volume Manager – VxVM, ZFS, …) demuestran ser alternativa eficaz que  complementan de forma segura y hacen flexible cualquier cambio posterior en el almacenamiento.

MULTIPATH

Una solución SAN en iSCSI necesitaría de un switch ethernet para conectar los Initiator/s con los Target/s. Un diseño en SAN de fibra típico sería redundar HBAs y Switches de fibra proporcionando multicamino (multipah) al sistema, se conseguiría de esta forma prevenir de cualquier fallo Hardware la continuidad de acceso a los discos. Esta tolerancia a fallos también es posible realizarse por analogía en iSCSI, redundando tarjetas  y switches ethernet, acompañado de un software multipath.

PROXY SAN/NAS

Cualquier sistema UNIX/Linux dispone de soporte para fibra e iSCSI, con una correcta configuración se podría realizar un redirección de los volúmnes (lunes) en fibra a traves de iSCSI sobre ethernet y combinar con  cualquier protocolo de compartición de ficheros como SMB o NFS. Ésto nos permitiría crear un servidor que centraliza el almacenamiento en el CPD redireccionándolo a ethernet sobre protocolos de bloques (iSCSI) o de ficheros (SMB,NFS).

También existen soluciones enterprise con esta funcionalidad  basadas en software abierto tales como NexentaStor,  OpenFiler o FreeNAS.

FS con reservas

El acceso de diferentes servidores a los mismos volúmes (típico en clústeres) necesitan tener un control de acceso y reservas de forma que haya coherencia en las modificaciones en el sistema de ficheros. Ésto se puede conseguir eligiendo un sistema de ficheros de tipo disco compartido (Share Disk File System)   como GFS (REDHAT) o VMFS (VMWARE).

Controladoras Activo/Activo Activo/Pasivo

Soluciones software tipo  IET en servidores linux  sobre las tarjetas ethernet del servidor  como Enterprise Target iSCSI proporcionará un comportamiento  análogo al  típico de  las controladoras de cabinas de discos  en fibra.

Soporte

El tema más delicado ya que el soporte SAN va en función de la interoperabilidad entre fabricantes destacando los elementos siguientes:

Sistema Operativo-Multipath- HBA-Drivers-Switch-Almacenamiento- Modos del multipath

Y debido a que el diseño de cada elemento en su totalidad  no se ajusta a los mismos estándares se necesita una certificación previa entre diferentes productos y marcas.

Esta situación cambia bastante en un entorno iSCSI siendo un protocolo/estandar bien definido con una implementación precisa, que crea un marco de interoperatibidad mucho mayor.

Aún así, hablamos  de la infrestructura que contiene los datos de una empresa, y si algo en su CPD debe de tener soporte es este almacén de datos. Por lo que el final de este diseño propuesto puede variar bastante  si no se quiere contratar soporte … incluyento por ejemplo  soluciones de backup, Alta disponibilidad (HA) con replicación síncrona entre dos cabinas de discos, … todo un tema a desarrollar y cuya implementación en producción es aconsejable que deba superar toda una fase de testeo intensivo  y planes robustos de contingencia.

Lo aconsejable es buscar soporte en alguna solución tipo Openfiler, siendo una de las soluciones más flexibles … aunque no olvidar que hay que mirar la interoperabilidad con lupa y como ejemplo  VMWARE no la certifica para sus servidores ESX ….

Por otro lado si se elige una implementación  de un target iSCSI sobre un sistema operativo, ésta solución  no tiene porqué dejar de ser soportada por la distribución, ejemplo de ellos son: RHEL que incluye desde la versión 5.3 soporte para esta característica integrando SCSI Target Framework proyecto integrado en la linea principal de desarrollo del Kernel y mantenido por el creador de IET, u OpenSolaris con el proyecto COMSTAR.

Ya disponemos en nuestro AA Labs de una VTL Open Source sobre FCP. Su implementación está basada en los trabajos previos sobre mhVTL y SCST.  Siguiendo con la configuración SAN del post anterior, hemos conseguido emular una librería modelo Storagetek SL700 y un drive SDL600 de Quantum:

Partiendo del escenario descrito en los post  SCST 2 y SCST 3, donde se compiló un kernel vanilla y se le añadió el proyecto SCST junto con los drivers de QLogic en modo target, configurado para que ofreciera a la SAN un disco virtual (VDISK). Se añade al servidor el proyecto mhVTL emulando una librería de cintas modelo Sun Storagetek SL700 con un drive SDLT600 de QUANTUM, encargándose el módulo SCST de ofrecerlas a través de la HBA QLogic QLA2340 en modo target.

El procedimiento de su implementación es el siguiente:

1.- Crear entorno previo SCST descrito en el  post SCST 2.

2.- Instalar proyecto mhVTL

3.- Configurar mhVTL

4.- Configurar SCST para dar visibilidad a los elementos de mhVTL por fibra.

2.- Instalar proyecto mhVTL

Si se ha realizado  la VTL Open Source sobre iSCSI, ya sabrás como instalarlo. Descarga de las fuentes mhvtl en formato tar.gz desde la web del proyecto. A continuación el procedimiento de instalación sería:

# useradd vtl
# passwd vtl
# mkdir /opt/mhvtl
# chown -Rf vtl:vtl /opt/mhvtl
# mkdir /etc/mhvtl
# chown -Rf vtl:vtl /etc/mhvtl
# cd /root/mhvtl-0.18-4
# make distclean
# cd kernel
# make
# make install
# cd ../
# make
# make install

3.- Configurar mhVTL

Edición del fichero /etc/mhvtl/device.conf  para definir en el proyecto mhVTL la librería y el drive:

# cat /etc/mhvtl/device.conf
VERSION: 4

# VPD page format:
# <page #> <Length> <x> <x+1>… <x+n>

# NOTE: The order of records is IMPORTANT…
# The 'Unit serial number:' should be last (except for VPD data)
# i.e.
# Order is : Vendor ID, Product ID, Product Rev and serial number finally
# Zero, one or more VPD entries.
#
# Each 'record' is sperated by one (or more) blank lines.
# Each 'record' starts at column 1

Library: 2 CHANNEL: 0 TARGET: 0 LUN: 0
Vendor identification: STK
Product identification: L700
Product revision level: 5500
Unit serial number: XYZZY

Drive: 1 CHANNEL: 0 TARGET: 1 LUN: 0
Library ID: 2 Slot: 1
Vendor identification: QUANTUM
Product identification: SDLT600
Product revision level: 5500
Unit serial number: ZF7584364
Max density: 0×46
VPD: b0 04 00 02 01 00

Definir el contenido de la librería en el fichero /etc/mhvtl/library_contents:

# cat /etc/mhvtl/library_contents
# Define how many tape drives you want in the vtl..
# The 'XYZZY_...' is the serial number assigned to
# this tape device.

Drive 1: ZF7584364

# Place holder for the robotic arm. Not really used.
Picker 1:

# Media Access Port
# (mailslots, Cartridge Access Port, <insert your favourate name here>)
# Again, define how many MAPs this vtl will contain.
MAP 1:
MAP 2:
MAP 3:
MAP 4:

# And the 'big' on, define your media and in which slot contains media.
# When the rc script is started, all media listed here will be created
# using the default media capacity.
Slot 1:    800843S3
Slot 2: 800844S3
Slot 3: 800845S3
Slot 4: 800846S3
Slot 5: 800847S3
Slot 6: 800848S3
Slot 7: 800849S3
Slot 8: 800850S3
Slot 9: 800851S3
Slot 10: 800852S3
Slot 11: 800853S3
Slot 12: 800854S3
Slot 13: 800855S3
Slot 14: 800856S3
Slot 15: 800857S3
Slot 16: 800858S3
Slot 17: 800859S3
Slot 18: 800860S3
Slot 19: 800861S3
Slot 20: 800862S3
Slot 21:
Slot 22:
Slot 23:
Slot 24:
Slot 25:
Slot 26:
Slot 27:
Slot 28:
Slot 29:
Slot 30:
Slot 31: CLN001L1
Slot 32: CLN002L1

4.- Configurar SCST para dar visibilidad a los elementos de mhVTL por fibra.

Levantar  servicio mhVTL:

/etc/init.d/mhvtl start

Comprobación:

# lsscsi
[2:0:0:0]    disk    ATA      WDC WD7500AACS-0 01.0  /dev/sda
[8:0:0:0]    mediumx STK      L700             5500  -
[8:0:1:0]    tape    QUANTUM  SDLT600          5500  -

Se observan el VDISK (procedente de prueba anterior) y la librería STK L700 junto con el drive QUANTUM SDLT600 creados por mhVTL.

Se configura para que los dispositivos sean visibles por la HBA:

# echo "add 8:0:1:0 1" > /proc/scsi_tgt/groups/Default/devices

# echo "add 8:0:0:0 2" > /proc/scsi_tgt/groups/Default/devices

Y se pone en modo target el host asociado como interfaz en sysfs:

# echo “1″ >/sys/class/scsi_host/host7/target_mode_enabled

Comprobación:

# cat /sys/class/scsi_host/host7/active_mode

Target

# cat /proc/scsi_tgt/scsi_tgt
Device (host:ch:id:lun or name)                             Device handler
2:0:0:0                                                     dev_disk
vm_disk                                                     vdisk_fileio
8:0:1:0                                                     dev_tape
8:0:0:0                                                     dev_changer

Desde el Host con W2k8 que opera en modo initiator se observan desde el administrador de dispositivos de la siguiente forma:

Se ha instalado la Utilidad OneCommand manager de Emulex con propósito de diagnóstico, la librería y el drive emulados se observan de la siguiente forma:

Para comprobar la conectividad del host con la VTL por fibra  se han usado las utilidades mtx en su versión para Windows:

Estado de la librería:

c:\mtx>mtx.exe -f 3:0:0:2 status
Storage Changer 3:0:0:2:1 Drives, 36 Slots ( 4 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = 800843S3

Storage Element 1:Empty
Storage Element 2:Full :VolumeTag=800844S3
Storage Element 3:Full :VolumeTag=800845S3
Storage Element 4:Full :VolumeTag=800846S3
Storage Element 5:Full :VolumeTag=800847S3
Storage Element 6:Full :VolumeTag=800848S3
Storage Element 7:Full :VolumeTag=800849S3
Storage Element 8:Full :VolumeTag=800850S3
Storage Element 9:Full :VolumeTag=800851S3
Storage Element 10:Full :VolumeTag=800852S3
Storage Element 11:Full :VolumeTag=800853S3
Storage Element 12:Full :VolumeTag=800854S3
Storage Element 13:Full :VolumeTag=800855S3
Storage Element 14:Full :VolumeTag=800856S3
Storage Element 15:Full :VolumeTag=800857S3
Storage Element 16:Full :VolumeTag=800858S3
Storage Element 17:Full :VolumeTag=800859S3
Storage Element 18:Full :VolumeTag=800860S3
Storage Element 19:Full :VolumeTag=800861S3
Storage Element 20:Full :VolumeTag=800862S3
Storage Element 21:Empty
Storage Element 22:Empty
Storage Element 23:Empty
Storage Element 24:Empty
Storage Element 25:Empty
Storage Element 26:Empty
Storage Element 27:Empty
Storage Element 28:Empty
Storage Element 29:Empty
Storage Element 30:Empty
Storage Element 31:Full :VolumeTag=CLN001L1
Storage Element 32:Full :VolumeTag=CLN002L1
Storage Element 33 IMPORT/EXPORT:Empty
Storage Element 34 IMPORT/EXPORT:Empty
Storage Element 35 IMPORT/EXPORT:Empty
Storage Element 36 IMPORT/EXPORT:Empty

Información de la librería:

c:\mtx>tapeinfo.exe -f 3:0:0:2
Product Type: Medium Changer
Vendor ID: 'STK     '
Product ID: 'L700            '
Revision: '5500'
Attached Changer API: No
SerialNumber: 'XYZZY     '
Ready: yes

Información del drive:

c:\mtx>tapeinfo.exe -f Tape0
Product Type: Tape Drive
Vendor ID: 'QUANTUM '
Product ID: 'SDLT600         '
Revision: '5500'
Attached Changer API: No
SerialNumber: 'ZF7584364 '
MinBlock: 4
MaxBlock: 1048576
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0×49
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0×10
DeCompType: 0×10
BOP: yes
Block Position: 0
Partition 0 Remaining Kbytes: 499
Partition 0 Size in Kbytes: 500
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0

Carga de cinta de Slot 1 a drive 0:

c:\mtx>mtx.exe -f 3:0:0:2 load 1 0
Loading media from Storage Element 1 into drive 0…done

Descarga de drive 0 a slot 1:

c:\mtx>mtx.exe -f 3:0:0:2 unload 1 0
Unloading drive 0 into Storage Element 1…done

Como se puede observar la librería virtual opera correctamente a las peticiones descritas a través de fibra. Queda para un próximo post estudiar el comportamiento de la librería administrada por un software típico de backup.

Fuentes:

Proyecto mhvtl

Proyecto SCST

Foros de nimsa

Blog nsrd.info

Entre administradores de entornos de almacenamiento en fibra es conocido el problema que hay con la compatibilidad entre dispositivos de proveedores diferentes. Por ejemplo, al añadir una cabina de discos  a una SAN y que no funcione con el failover (multipath) ya existente en el servidor porque no están en la matriz de interoperabilidad de los fabricantes. Dejaré en este post unas notas relativas a estos problemas.

Primeramente definiré Interoperabilidad:

La Interoperabilidad es la condición mediante la cual sistemas heterogéneos pueden intercambiar procesos o datos ( procedente de la Wikipedia ) o la capacidad de los productos de diferentes fabricantes puedan operar conjuntamente ( procedente de BNET).

En entornos de almacenamiento en fibra la Interoperabilidad es bastante compleja, cumpliéndose que si toda una red SAN no está en la lista de compatibilidad de hardware/software de los vendedores no operará de la forma esperada. Hace algunos años, el acceder a información de interoperatividad era un trabajo frustante debido a que no era pública por parte de la mayoría de fabricantes y por lástima en muchos casos usada de forma interesada comercialmente. En la actualidad se ha realizado un gran esfuerzo por la mayoría de ellos, creándose una tendencia cada vez más recia en comunicar esta información, al mismo tiempo que los grandes proveedores de soluciones de almacenamiento se ajustan a estándares para universalizar sus productos y flexibilizar una mayor integración en cualquier entorno heterogéneo cada vez más común.

En almacenamiento hay diferentes organismos para mejorar estos grandes problemas de incompatibilidades entre diferentes proveedores, de forma que establecen estándares y protocolos para una mejor comunicación e integración entre los dispositivos de almacenamiento. Entre todas ellas es destacable  el trabajajo que realiza SNIA (Storage Networking Industry Association) cuyo proposito es encabezar en la industria el desarrollo y promoción de estándares, tecnologías y servicios educacionales para apoderar la gestión de información. Todos los grandes fabricantes de almacenamiento son miembros de la SNIA y de forma paulatina va creciendo un marco de interoperatividad entre todos ellos. Aún así, debido al proceso lento de salida y aceptación de estos estándares se realizan de forma independiente muchas alianzas tecnológicas entre diferentes fabricantes que en su mayoría pretenden impulsar propios productos de avanzada tecnología consiguiendo en gran cantidad de casos ser pioneros y mejorar su cartera de productos y especificaciones y por consiguiente competir comercialmente. Forzando que el resto de competidores tecnológicos acepten e integren estas nuevas especificaciones aún no estandarizadas, motivada por esta necesidad de compatibilidad en entornos heterogéneos y para que no penalice su imagen comercial.

A continuación se aportará  información junto con enlaces de  los proveedores y fabricantes de almacenamiento para el conocimiento de la Interoperabilidad de sus productos con las de otros fabricantes.

Algunas Tablas de Interoperabilidad y HCL ( Listas de compatibilidad Hardware )

Fabricantes

Emulex

Emulex es unos de los líderes en interoperabilidad en SAN, su reputación “It Just Works” se basa en un compromiso con los estándares, abierto al soporte de software y hardware, y al testeo extensivo de interoperatividad.

A continuación se listan sus Tablas de Interoperabiliidad con los siguientes fabricantes :

Información y enlaces procedente de Emulex.

QLogic

QLogic presenta un magnífico trabajo disponible en su web de interoperabilidad al igual que de su historia altamente recomendable disponible en su web, que recopila sus productos, soluciones y servicios que proporcionan, al igual que su certificaciones con distintos proveedores de soluciones SAN. Un documento nada habitual en esta tecnología.

A continuación se listan las Tablas de Interoperabilidad con los siguientes fabricantes :

3PAR | AC&NC | Apple | ATTO Technology | BlueArc | Compellent | Dell | Dell EqualLogic | DNF | Dot Hill | EMC | Enhance Technology | Fujitsu Computer Products of America | Fujitsu Computer Systems | Hewlett-Packard | Hitachi Data Systems | Hitachi Global StorageTechnologies | HP LeftHand SAN (aka LeftHand Networks) | IBM | Infortrend | Intransa | iQstor | iStor | LSI | Matrox | NEC | NetApp | Nexsan | Overland | Pillar | Promise | Qualstar | Quantum | RELDATA | Seagra | SEPATON | Spectra Logic | StoneFly | StoreVault | Sun Microsystems | Symantec | Tandberg Data | Texas Memory Systems | Thales nCipher | Winchester Systems | Xiotech | Xyratex

Información y enlaces procedentes de QLogic.

Brocade – McData

Brocade pone a disposición un documento con la compatibilidad/interoperabilidad de sus productos en la sección de compatibilidad enlazable aquí llamado Brocade Data Center Ready.

Sun Microsystems

Proporciona un listado de soluciones de almacenamiento certificadas con Microsoft en el siguiente documento:

http://www.sun.com/software/windows/storage_cert.pdf

En su sección de almacenamiento y servidores individualmente es completada con tablas de soportabilidad/certificación/interoperatividad de cada dispositivo, y una sección genérica a la Interoperatividad de todos sus productos.

IBM

Presenta una sección de productos para SAN:

http://www-03.ibm.com/systems/uk/storage/san/index.html

Cada dispositivo va acompañado de un documento de Interoperabilidad llamado Interoperability Matrix.

EMC

Proporcionan un documento con las matrices de interoperabilidad en la sección de Interoperabilidad de su portal. Sus  clientes  pueden utilizar una herramienta de navegación para la interoperabilidad en Powerlink.

HP

Sección de almacenamiento en su portal:

http://welcome.hp.com/country/es/es/leb/storage.html

NETAPP

Sección de Interoperabilidad en su portal:

http://www.netapp.com/us/technology/interop.html

VMWARE

Dispone uns sección para consultas de compatibilidad desde su web con distintos proveedores:

http://www.vmware.com/resources/compatibility/search.php?action=base&deviceCategory=san

Proporciona un documento con las matrices de compatibilidad completa Storage/SAN Compatibility Guide.

….  sólo son algunos proveedores de fibra.

Para poner a prueba  el disco de fibra creado en el anterior post vamos a disponer de un servidor con Windows Server 2008 y una HBA Emulex LP-10000DC  con drivers en modo Initiator. El escenario creado para esta prueba es el siguiente:

Resumiendo: El servidor Centos con kernel vanilla preparado con proyecto SCST y una HBA con drivers en modo target es configurado para proporcinar un disco virtual(vdisk) a la SAN.  El disco virtual es un fichero que a través del módulo SCST es ofrecido por fibra óptica ( HBA operando en modo target). Por otro lado disponemos de un servidor con un sistema operativo Windows Server 2008  SP1, que dispone de una HBA operando en modo Initiator. Las dos HBAs están conectadas a una SAN y se ha realizado un zonning en el switch de fibra de forma que el Initiator pueda ver la lun correspondiente al vdisk.

Comprobación: Desde el servidor Windows se ve correctamente el disco de fibra creado, desde su administrador de dispositivos:

Aparecen dos discos tipo “disk drives” debido a que la HBA es de dos puertos y están zoneados al mismo disco. Hemos operado con sólo uno de los discos y lo hemos inicializado sin problemas:

Desde el servidor Centos comprobamos las sesiones en el target por los initiators (son dos, uno por cada puerto de la HBA Emulex usada):

# cat /proc/scsi_tgt/sessions

Target name          Initiator name                                Group name                   Active/All Commands Count

qla2x00tgt           10:00:00:00:c9:4f:56:a0                       Default                             0/0

qla2x00tgt           10:00:00:00:c9:4f:56:9f                       Default                             0/0

Hemos provocado simultáneas I/Os sobre el disco de fibra (copia, borrado y lectura de ficheros) con resultados  satisfactorios.

En breve, aumentaremos el tamaño del VDISK y lo someteremos a unas pruebas de rendimiento y stress. Igualmente se usará en el backend un disco físico.

Por otro lado, ya nos estamos preparando para nuestro próximo proyecto …. la emulación de una librería virtual de cintas (VTL) en fibra basado en el proyecto mhvtl que ya usamos en AA Labs en su versión para iSCSI.

Como se anunciaba en el anterior post se detallará el procedimiento mediante el  cual  un servidor linux con una HBA  ofrecerá almacenamiento sobre fibra a través del proyecto SCST. Para esta ocasión se ha usado una HBA QLA2340 con el propósito de integrar los drivers en modo target  con el módulo SCST, mostrándose como se podrá ofrecer un disco de fibra a partir de un fichero del sistema operativo.

Para ello hemos dispuesto de un equipo con las siguientes características:

Placa: ASRock ALiveNF7G-GLAN

RAM: 4 GB DDR 800 HHz Mushkin Extreme

Micro: AMD Athlon64 X2 4600+ 2.4 Ghz AM2 Box

SO: Centos 5.5 en su versión de 64 bits

HBA: QLogic QLA 2340

HD: Western Digital Caviar GP 750GB 5400 rpm SATA2 MAESTRO

HBA: QLogic QLA2340 PCI/PCI-X

Host con Centos 5.5 y HBA QLogic QLA2340 en modo target

QLogic QLA2340

Fases que consta el procedimiento:

1 – Cargar firmware de HBA

2 – Compilar un Kernel vanilla

3 – Compilar proyecto  SCST y drivers de QLogic

4- Configurar una lun accesible en modo target

1.- Cargar firmware de HBA

Se aconseja que la HBA  tenga un firmware de versión igual o superior a versión 5.xx para versiones de QLOGIC 24/25XX. Para la versión de HBA usada en el laboratorio, QLA2340, hemos descargado  ql2300_fw.bin.3.03.20 desde el siguiente link. Para otra versiones de HBAs QLogic aquí.

Se copia el archivo de firmware en la carpeta  /lib/firmware. Así el módulo qla2xxx(drivers de QLogic) que lleva por defecto la distribución lo cargará en la tarjeta en tiempo de arranque. El éxito de la carga del firmware se observará en la salida del comando dmesg de la siguiente forma :

qla2xxx 0000:01:0a.0: Found an ISP2312, irq 82, iobase 0xffffc20000028000
qla2xxx 0000:01:0a.0: Configuring PCI space…
qla2xxx 0000:01:0a.0: Configure NVRAM parameters…
qla2xxx 0000:01:0a.0: Verifying loaded RISC code…
qla2xxx 0000:01:0a.0: Allocated (412 KB) for firmware dump…
scsi4 : qla2xxx
qla2xxx 0000:01:0a.0:
QLogic Fibre Channel HBA Driver: 8.03.01.04.05.05-k
QLogic QLA2340 – 133MHz PCI-X to 2Gb FC, Single Channel
ISP2312: PCI (33 MHz) @ 0000:01:0a.0 hdma+, host#=4, fw=3.03.26 IPX

2 – Compilar un kernel vanilla

La versión inicial del kernel de partida en Centos 5.5 es:

# uname -a

Linux unknown001966cb53eb 2.6.18-194.3.1.el5 #1 SMP Thu May 13 13:08:30 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

Se descarga una versión vanilla (mainline)  desde kernel.org, versión 2.6.26:

#cd /usr/src

# wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.26.tar.bz2

# bunzip2 /usr/src/linux-2.6.26.tar.bz2

# tar -xvf /usr/src/linux-2.6.26.tar

Se crean los enlaces simbólicos linux y kernel :

#ln -s /usr/src/linux-2.6.26 linux

#ln -s /usr/src/linux-2.6.26 kernel

Se descargan las fuentes del proyecto de SCST de su Subversion:

#cd  /root

#svn co https://scst.svn.sourceforge.net/svnroot/scst/trunk

(…)

A    trunk/nightly/bin

A    trunk/nightly/bin/nightly

A    trunk/nightly/README.txt

U   trunk

Revisión obtenida: 1792

Ir a carpeta /root/scst/trunk/src y parchear las fuentes del kernel que nos hemos descargado:



# cd /root/scst/trunk/

# cp /root/scst/trunk/scst/kernel/scst_exec_req_fifo-2.6.26.patch /usr/src

# cp /root/scst/trunk/scst/kernel/scst_exec_req_fifo-2.6.26.patch /usr/src

# cd /usr/src

# patch -p0 < scst_exec_req_fifo-2.6.26.patch

Eliminar los drivers de las fuentes del kernel vanilla y sustituir por su homólogo modificado que proporciona las fuentes de SCST:

# mv /usr/src/linux/drivers/scsi/qla2xxx /usr/src/linux/drivers/scsi/qla2xxx_orig

Incluir el driver de Qlogic en modo target  previo a la compilación del kernel:

#  ln -s /root/scst/trunk/qla2x00t /usr/src/linux/drivers/scsi/qla2xxx

Procedemos a configurar la compilación del kernel y sus módulos:

#cd /usr/src/linux

#make menuconfig

Desde el menú de configuración del kernel activar “Device Drivers->SCSI device support->SCSI low level drivers->Qlogic 2xxx target mode support”:

Modificar el fichero Makefile y cambiar la entrada EXTRAVERSION de “-prep”  a “-scst”:

#vi Makefile

(…)

VERSION = 2

PATCHLEVEL = 6

SUBLEVEL = 18

EXTRAVERSION = -scst

RHEL_MAJOR = 5

RHEL_MINOR = 5

NAME=Avast! A bilge rat!

(…)

Procedemos a compilar el kernel y módulos:

#make bzImage
(…)

Setup is 11384 bytes (padded to 11776 bytes).

System is 2783 kB

CRC 5f0d96a4

Kernel: arch/x86/boot/bzImage is ready (#1)

#make modules

(…)

Building modules, stage 2.

MODPOST 3 modules

CC drivers/net/s2io.mod.o

LD [M] drivers/net/s2io.ko

CC drivers/scsi/qla2xxx/qla2xxx.mod.o

LD [M] drivers/scsi/qla2xxx/qla2xxx.ko

CC drivers/scsi/scsi_wait_scan.mod.o

LD [M] drivers/scsi/scsi_wait_scan.ko

#make modules_install
#make install

Si el proceso ha ido bien, tendremos una entrada en el grub para el nuevo kernel creado preparado para levantar el modo target de la HBA:

#cat /boot/grub/menu.lst

(…)

title CentOS (2.6.26)
root (hd0,2)
kernel /vmlinuz-2.6.26 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.26.img

(…)

Hacemos un reinicio del sistema y arrancamos desde grub en CentOS (2.6.26) o el que se haya creado.

3 – Compilar proyecto  SCST y drivers de QLogic

Después del reinicio se comprueba que se ha cargado el nuevo kernel creado:

#uname -a
Linux unknown001966cb53eb 2.6.26 #1 SMP Sun Jun 27 19:42:12 CEST 2010 x86_64 x86_64 x86_64 GNU/Linux

Sobre el que compilaremos el módulo SCST que nos permitirá crear aquellos dispositivos visibles a través del target de fibra.

#cd /root/scst/trunk/scst/src

#make all

(…)

CC /root/scst/trunk/scst/src/scst.mod.o

LD [M] /root/scst/trunk/scst/src/scst.ko

make[1]: se sale del directorio `/usr/src/linux-2.6.26'

#make install

install -m 644 ../include/scst_const.h /usr/local/include/scst
rm -f /usr/local/include/scst/Modules.symvers
install -m 644 Module.symvers /usr/local/include/scst
/sbin/depmod -a 2.6.26
mkdir -p /var/lib/scst/pr
****************************************************************
*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*
*!!                                                          !!*
*!!  Now don’t forget to rebuild and reinstall all your      !!*
*!!  target drivers, custom dev handlers and necessary user  !!*
*!!  space applications. Otherwise, because of the versions  !!*
*!!  mismatch, you could have many problems and crashes.     !!*
*!!  See IMPORTANT note in the “Installation” section of     !!*
*!!  SCST’s README file for more info.                       !!*
*!!                                                          !!*
*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*
****************************************************************

# cd /root/scst/trunk/qla2x00t/qla2x00-target/

# make

(…)

target/qla2x00tgt.mod.o

LD [M] /root/scst/trunk/qla2x00t/qla2x00-target/qla2x00tgt.ko

make[1]: se sale del directorio `/usr/src/linux-2.6.26'

# make install

(…)

INSTALL /root/scst/trunk/qla2x00t/qla2x00-target/qla2x00tgt.ko

DEPMOD 2.6.26

make[1]: se sale del directorio `/usr/src/linux-2.6.26'

/sbin/depmod -a 2.6.26

Los binarios recién compilados se encuentran como módulos en /lib/modules/linux-2.6.26/extra:

# ls /lib/modules/2.6.26/extra/
dev_handlers  qla2x00tgt.ko  scst.ko

# ls -l /lib/modules/`uname -r`/extra/dev_handlers

/lib/modules/`uname -r`/extra/dev_handlers
total 224
-rw-r–r– 1 root root 13792 jun 27 19:55 scst_cdrom.ko
-rw-r–r– 1 root root 11375 jun 27 19:55 scst_changer.ko
-rw-r–r– 1 root root 15209 jun 27 19:55 scst_disk.ko
-rw-r–r– 1 root root 15366 jun 27 19:55 scst_modisk.ko
-rw-r–r– 1 root root 11391 jun 27 19:55 scst_processor.ko
-rw-r–r– 1 root root 11351 jun 27 19:55 scst_raid.ko
-rw-r–r– 1 root root 15142 jun 27 19:55 scst_tape.ko
-rw-r–r– 1 root root 51965 jun 27 19:55 scst_user.ko
-rw-r–r– 1 root root 62807 jun 27 19:55 scst_vdisk.ko

¿ que es cada módulo?

- scst – SCST itself
- scst_disk – device handler for disks (type 0)
- scst_tape – device handler for tapes (type 1)
- scst_processor – device handler for processors (type 3)
- scst_cdrom – device handler for CDROMs (type 5)
- scst_modisk – device handler for MO disks (type 7)
- scst_changer – device handler for medium changers (type
- scst_raid – device handler for storage array controller (e.g. raid) (type C)
- scst_vdisk – device handler for virtual disks (file, device or ISO CD image).
- scst_user – user space device handler

4- Configurar una lun accesible en modo target

Para éste propósito se usará el módulo scst_vdisk a través del cual se ofrecerá un fichero de tamaño definido como una lun tipo disco en la SAN.

Cargamos los módulos, que para este caso sólo se necesitarían qla2xxx, qla2x00tgt y scst_vdisk, pero ya estamos pensando en el futuro

# for _mod in scst qla2xxx qla2x00tgt scst_vdisk scst_disk scst_changer scst_tape; do modprobe $_mod; done

# lsmod

Module Size Used by

scst_tape 10368 0

scst_changer 7936 0

scst_disk 10368 0

scst_vdisk 40556 0

qla2x00tgt 51480 0

scst 192628 5 scst_tape,scst_changer,scst_disk,scst_vdisk,qla2x00tgt

qla2xxx 186700 1 qla2x00tgt

Se crea un fichero de 512 MB en /mnt con nombre disk1:

# dd if=/dev/zero of=/mnt/disk1 bs=1024k count=512

512+0 records in

512+0 records out

536870912 bytes (537 MB) copied, 5,87352 seconds, 91,4 MB/s

# file /mnt/disk1

/mnt/disk1: data

Y se configura para que sea visible por la HBA:

# echo “open vm_disk /mnt/disk1″ > /proc/scsi_tgt/vdisk/vdisk

#  echo “add vm_disk 0″ >/proc/scsi_tgt/groups/Default/devices

El resultado de este proceso se puede observar en la salida del comando dmesg:

scst: Attached to scsi2, channel 0, id 0, lun 0, type 0
scst: Processing thread scsi_tgt0 (PID 6116) started
scst: Processing thread scsi_tgt1 (PID 6117) started
scst: Init thread started, PID 6118
scst: Task management thread started, PID 6119
scst: Management thread started, PID 6120
scst: SCST version 2.0.0-rc2-procfs loaded successfully (max mem for commands 928MB, per device 371MB)
scst: Enabled features: TRACING
Initializing QLogic Fibre Channel HBA Driver target mode addon version 2.0.0-rc2
Target mode driver for QLogic 2×00 controller registered successfully
scst: Target template qla2x00tgt registered successfully
scst: Virtual device handler vdisk_fileio for type 0 registered successfully
scst: Virtual device handler vdisk_blockio for type 0 registered successfully
scst: Virtual device handler vdisk_nullio for type 0 registered successfully
scst: Virtual device handler vcdrom for type 5 registered successfully
scst: Device 2:0:0:0: TST 0, QUEUE ALG 0, SWP 0, TAS 0, D_SENSE 0, has_own_order_mgmt 1
scst: Device handler “dev_disk” for type 0 registered successfully
scst: Device handler “dev_disk_perf” for type 0 registered successfully
scst: Device handler “dev_changer” for type 8 registered successfully
scst: Device handler “dev_tape” for type 1 registered successfully
scst: Device handler “dev_tape_perf” for type 1 registered successfully
dev_vdisk: Registering virtual vdisk_fileio device vm_disk
dev_vdisk: Attached SCSI target virtual disk vm_disk (file=”/mnt/disk1″, fs=512MB, bs=512, nblocks=1048576, cyln=512)
scst: Attached to virtual device vm_disk (id 1)
scst: Added device vm_disk to group Default (LUN 0, rd_only 0)

Para activar el modo target sólo quedaría introducir el valor 1 en el fichero target_mode_enabled correspondiente a su scsi_host asociado como interfaz sysfs.

# echo “1″ >/sys/class/scsi_host/host5/target_mode_enabled

Dejo unas comprobaciones verificando la correcta configuración de nuestro vdisk:

# cat /sys/class/scsi_host/host5/active_mode

Target

#  cat /proc/scsi_tgt/scsi_tgt
Device (host:ch:id:lun or name)                             Device handler
2:0:0:0                                                     dev_disk
vm_disk                                                     vdisk_fileio

# cat /proc/scsi_tgt/vdisk/vdisk

Name Size(MB) Block size Options File name T10 device id

vm_disk 512 512 /mnt/disk1 vm_disk 968d2339

#  cat /proc/scsi_tgt/groups/Default/devices

Device (host:ch:id:lun or name) LUN Options

vm_disk 0

El el siguiente post pondremos a prueba nuestro disco creado, usando un initiator de fibra sobre un host Windows Server 2008 con HBA QLA2340.

Fuentes:

How to configure QLogic target driver for 22xx/23xx/24xx/25xx adapters. Step by step guide.