Las LSI 9211-8i y el modo IT

La madre de las tarjetas interesantes fabricadas por LSI que son útiles para algo como FreeNAS o (probablemente) BlueStore, es la 9211-8i: Dos conectores SFF-8087 y, algo de magia negra mediante, ningún software RAID entre los discos y el sistema operativo principal. Es básicamente la misma tarjeta que la Dell H310 o la IBM M1015.

Sin embargo, para convertir estas tarjetas a modo IT, he tenido que hacer algo distinto. En algunas placas base, los sas2flsh.exe de DOS no funcionan. Ni idea del motivo; da un error diciendo algo de PAL, que me suena a tele analógica en color. Así que he tenido que recurrir al shell UEFI.

Como no todo podía ser bonito, el shell UEFI de la Supermicro X9SCM-F tiene dificultades para ver un sistema de ficheros que no sea el de un disco SATA (tampoco ni idea de por qué: tenía que flasear las malditas tarjetas, así que simplemente fui aceptando los hechos tal como me los iba encontrando). Adiós al brillante plan de cascar los ficheros en un pincho USB y terminar.

Total, que con un FreeDOS instalado en el disco C:, me bajé el paquete Installer_P20_for_UEFI de Broadcom (ex Avago, ex LSI), creé un directorio 9211 y le copié:

  • sas2flsh.efi
  • MPTSAS2.ROM
  • 2118IT.BIN

Si se intenta meter el firmware IT sin más, el chisme se niega, indicando (un tanto estúpidamente) que nada de flasear un firmware IT sobre uno IR. Así que, igual que con toda la familia, lo primero que hay que hacer es

sas2flas.efi -o -e 6

Al carallo, ya no hay firmware. Ahora ya nada nos lo impedirá:

sas2flas.efi -o -f 2118IT.BIN -b MPTSAS2.ROM

La BIOS no creo que sea necesaria, pero ya estaba un poco cansado y decidí que ya experimentaría con quitarla de en medio en otro momento, si eso.

Como cosa curiosa, al borrarles la flash a estas tarjetas, no han perdido su dirección SAS.

Como cosa más curiosa aún, el proceso de pasarlas a IT ha sido el más sencillo de la familia.

Referencias y créditos:

  • http://brycv.com/blog/2012/flashing-it-firmware-to-lsi-sas9211-8i/
  • https://linustechtips.com/main/topic/104425-flashing-an-lsi-9211-8i-raid-card-to-it-mode-for-zfssoftware-raid-tutorial/

Un disco de estado sólido para usar con FreeNAS, rápido y barato

Hay dos buenos motivos para tener en un servidor con FreeNAS, al menos un disco lo más rápido posible. Uno es poder usarlo para L2ARC, y el otro es usarlo para SLOG/ZIL.

No voy a entrar en los detalles de una y otra cosa, porque para eso se ha molestado jgreco en escribir el artículo antes referido en los foros. En lugar de esto, voy simplemente a compartir lo que he hecho.

Un disco rápido, en los tiempos que corren, quiere decir SSD. Pero dentro de los SSD, también hay clases. No me refiero a los discos “Enterprise” o “Pro”, sino a algo más básico y es que hay discos SSD con puerto SATA, SAS, mSATA y M.2. Para acabar de confundir el asunto, este último formato puede llevar, según le parezca al fabricante, presentado en su conector un puerto SATA 3.0, un PCI Express 3.0, y/o un USB 3.0. De estos tres buses, el más rápido con diferencia es el PCI Express, así que el siguiente paso es elegir un disco M.2 con bus PCI Express y un adaptador para poder pincharlo en la placa base del servidor en cuestión.

Siendo uno de natural perfeccionista y rata a la vez, he acabado con esta solución de lo más afinado en ambos: Un disco Samsung 960 Evo, un poco más caro que los tradicionales 850 Evo SATA pero no una barbaridad en capacidades modestas, y un adaptador que Amazon está encantado de vender por la principesca suma de 7 euros y 99 céntimos, porte incluído:

Este adaptador funciona, no hay mucha ciencia en ello, pues se trata básicamente de llevar las líneas adecuadas del conector PCI Express al conector M.2. Viene con chapita para ranuras de altura completa, y la que se ve en la foto es una adaptación hecha en mi taller de una que agarré en la pila de los trastos.

Tal cual, no hay más que pincharla y contarle a FreeNAS para qué la queremos usar.

Usando una tarjeta Dell H310 con FreeNAS

Es vox populi que FreeNAS, o cualquier cosa que use ZFS como la versión 5 de Proxmox VE, quiere acceso directo a los discos para que el ZFS los gestione directamente. Es decir, no queremos una tarjeta RAID presentando un único volumen gordo con todos los discos que tiene detrás; solamente queremos que el sistema operativo vea todos y cada uno de los discos.

Para hacer esto, la opción más sencilla es tener una placa base con todos los conectores necesarios. Pero a veces tenemos una cierta cantidad de discos, por ejemplo 12 o 24, conectados a un backplane que, típicamente, cuenta con un par de conectores SFF a partir de los cuales conecta todos los discos.

La Dell H310 es una de bastantes versiones remarcadas de la LSI 9211-8i. Es una tarjeta RAID, pero LSI, en su infinita sabiduría, suministra un firmware que la convierte en una sencilla HBA. Es decir, una tarjeta que se limita a conectar discos y presentarlos de manera visible al sistema operativos. O sea, lo que queremos.

Otra encarnación de la LSI 9211-8i es la popular IBM M1015.

¿Por qué comprar la H310? Por lo de siempre: Por dinero. Van más baratas que las LSI. Además, no hay tantas copias chinas como de las M1015.

Dije que LSI suministra un firmware para convertirla en HBA. Ahora bien, aquí acaban las buenas noticias: El proceso que hay que seguir es algo engorroso pero sobre todo plagado de puñetitas. Así que, ya que me he puesto, he decidido documentarlo.

Hay que decir que la tarjeta tiene un firmware y una BIOS, que son dos piezas separadas. En mi caso, decidí dejarla sin BIOS. Esto no es ningún sacrilegio (la tarjeta vive perfectamente sin ella) y ahorra tiempo en el arranque porque, al no tener BIOS, ya no tiene que echar su meadita en cada arranque del sistema.

Siendo uno de natural paranoico, por otra parte, decidí que solamente iba a descargar el software necesario de sitios de los que me fiara. Tuve que hacer un pequeño salto de fe con fdos.org, más que nada porque es la manera más práctica de generar una ISO de arranque con FreeDOS.

En fin. Vamos a por los ingredientes:

  • Una Debian o cosa similar con xorriso (apt-get install xorriso, sin más)
  • FDOEMCD.builder.zip de fdos.org. Unzip eso, suelta un directorio con el DOSero nombre de FDOEMCD
  • megarec.exe. El único sitio fiable que encontré fue, de una FAQ de Supermicroel FTP de Supermicro. Unzip eso dentro de FDOEMCD/CDROOT. Ya de paso, nos suministra megacli.
  • El firmware IT para la H310. Que, por supuesto, no puede estar en una página de descargas de Dell llamada H310. No, está en la página de los R410, que son uno de los modelos que la montaban. Y ni siquiera se llama H310, sino “6Gbps SAS HBA Firmware Package”. En fin, que está aquí y que espero que los de Dell tengan que encontrar su camino por Mongolia con un mapa de carreteras de Libia de 1978. Unzip (es uno de esos exe autoextraíbles que unzip también entiende) dentro de FDOEM/CDROOT también.
  • empty.bin, que es un firmware vacío. Es un fichero de 256 bytes que contiene:
    • 0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      *
      0000090 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
      00000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      *0000100
    • Si te encuentras especialmente paranoico, créalo con un editor hexadecimal.
    • Y si no eres muy paranoico: empty.bin
    • En cualquier caso, también a FDOEM/CDROOT

Ya tenemos todo.

Ahora cogemos y desde FDOEM, y con fe: xorrisofs -o miiso.iso -p "Yo Claudio" -publisher "blog.tecnocratica.net" -b isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table -N -J -r -c boot.catalog -hide boot.catalog -hide-joliet boot.catalog CDROOT

No todas las opciones son estrictamente necesarias, pero así queda más mono. Eso genera miiso.iso.

Bueno, pues arrancamos nuestro servidor con eso (si ese día le toca funcionar al KVM del servidor basado en una versión fosilizada de Java, claro) y ejecutamos:

  • En el directorio de Supermicro, tools:
    • megacli.exe -AdpAllInfo -aAll -page 20
    • Tomar nota de la dirección SAS, para ponérsela más tarde, porque nos la vamos a calzar.
    • megarec.exe -writesbr 0 \empty.bin
    • megarec.exe -cleanflash 0

En este punto, hay que rearrancar. No me preguntes por qué, pero si no, no funciona el invento. Venga, rearranca. Yo espero.

Sigamos:

  • Ahora nos vamos al directorio del firmware de Dell:
    • sas2flsh.exe -o -f 6GBPSAS.fw
    • sas2flsh.exe -o -sasadd <la dirección SAS>

Ya hemos acabado. Llegados a este punto, o tenemos una HBA, o algo con que sujetar la puerta. De nada.

Créditos y enlaces de interés:

  • https://tylermade.net/2017/06/27/how-to-crossflash-perc-h310-to-it-mode-lsi-9211-8i-firmware-hba-for-freenas-unraid/
  • https://forums.freenas.org/index.php?threads/ibm-serveraid-m1015-and-no-lsi-sas-adapters-found.27445/
  • http://www.cgsecurity.org/wiki/Create_a_TestDisk_FreeDos_LiveCD
  • http://blog.asiantuntijakaveri.fi/2013/09/turning-dell-perc-h310-to-dumb-biosless.html
  • https://techmattr.wordpress.com/2016/04/11/updated-sas-hba-crossflashing-or-flashing-to-it-mode-dell-perc-h200-and-h310/
  • https://ciamician.wordpress.com/2015/03/06/flashing-your-dell-perc-h310-to-it-firmware-uefi/

Más difícil todavía: Partido y con las teclas en blanco

Desde la primera vez que noté que me dolían las muñecas, he estado buscando el teclado ideal.

Antaño, gustaba del tacto de aquellos IBM, ahora Unicomp. Durante años no pude usar otra cosa que Key Tronic. Pasé fugazmente por Logitech y, aunque nunca quedé totalmente convencido, Logitech fue mi primer teclado partido.

Hoy, tengo un teclado que tiene casi todo lo mejor de todos ellos: Un Ergodox-EZ.

Ergodox es un diseño de teclado abierto, tanto hardware como software. La electrónica se basa en Teensy, y las teclas en el caso del Ergodox-EZ son Cherry MX (la historia de la empresa Cherry es interesante, pero es otra historia y debe ser contada en otra ocasión).

Ergodox-EZ cogió el diseño Ergodox y, financiación de moda mediante, lo vende listo para funcionar. Perfecto para los que, como yo, tienen cierta tendencia a meterse en berenjenales y acabarlos al cabo de varios años.

El teclado parte de una filosofía de diseño, heredada de su antecesor Key64: No poner más teclas que las que se usan. Esto parece de perogrullo, pero cualquiera que tenga la costumbre de comer sandwiches de mermelada a la vez que usa el ordenador sabe que hay teclas que se usan, teclas que apenas se usan, y teclas que se usan poco pero no se puede pasar sin ellas. Ergodox tiene suficientes teclas para cubrir las que se usan y las que no se puede pasar sin ellas. Total, 76 teclas. Pero mediante el truco de disponer diferentes capas, se pueden tener disponibles hasta las que casi nunca se usan.

Ergodox EZ tiene un configurador por web con el que fácilmente se puede decidir la distribución de teclado,  y escupe un .bin que se larga al teclado con el cargador de Teensy. Facilito. Lo único que no es facilito, y es una pequeña desgracia dado el precio del juguete, es que el configurador solamente está disponible con el juego de teclas US. Así pues, ¿cómo se configura en castellano, que es lo que uso yo? Se coge un teclado US, se mira a qué símbolo corresponde la misma tecla en el teclado ES, y se pone la del teclado US en el configurador. Durante el proceso, recordar varias veces el árbol genealógico del que hizo la distribución de teclado ES. Y eso es todo. Esta es mi distribución en el momento de empezar a escribir este artículo:  ergodox_ez_firmware_kvpdlm_alfredo.hex. En esta distribución, está todo lo necesario para escribir en castellano y creo que también en gallego y euskera, pero le faltan algunas cosas para escribir en catalán.

Inspirado un tanto onanísticamente por mi propio artículo, me he hecho otra distribución que simplemente tiene accesible una capa con teclas de función y un teclado numérico bastante útil para picar direcciones IP, con el 5 centrado en la J, o sea, en la tecla que tiene el resalte, al igual que en un teclado numérico clásico: ergodox_ez_firmware_qgrdnj_alfredo.hex

Me ha llevado en torno a un par de semanas habituarme lo bastante como para encontrarlo razonablemente cómodo y empezar a pensar en exprimir algo más de él. Los primeros días fueron horrorosos. Al cabo de una semana, empieza a doler menos, y al cabo de dos, ya lo uso con cierta soltura.

Por la pasta que ha costado, espero que me dure muchos años… Y que no me duelan las muñecas mucho más.

phpipam: Mola mucho

Hace muchas, muchas lunas, tenía toda la red documentada con un MediaWiki. Incluso hice una ñapilla para recoger las descripciones de los puertos de los switches y generar con ellas una tabla automáticamente; la mandé a la lista de ExNIC hace ocho años:

Aquí os dejo una pequeña barbudez que he parido. Se trata de una extensión para MediaWiki que saca una tabla de interfaces de un trasto de Cisco; está pensado para switches. Disculpad los comentarios en espanglis y demás, resultado de copiar y pegar ejemplos de acá y allá.

Para hacerlo funcionar, hay que:

1. Ponerlo en un sitio adecuado (típicamente, extensions/tablainterfaces/tablainterfaces.php)
2. Añadirlo como extensión (añadir a LocalSettings.php, normalmente al final:

require_once “$IP/extensions/tablainterfaces/tablainterfaces.php”;

3. Meter en el código de la página que sea la llamada

{{#tablainterfaces:nombredeltrasto | community }}

(obviamente, nombredeltrasto puede ser un nombre o dirección IP, y es recomendable una community con solamente permiso de lectura).

Se admiten sugerencias.

Cuidado con los saltos de línea que introduce el editor de correo. Salud.

<?php

# Funcion de enganchar
$wgExtensionFunctions[] = ‘Iniciar_Tabla_Interfaces’;
# Add a hook to initialise the magic word
$wgHooks[‘LanguageGetMagic’][]       = ‘ElParseador_Magico’;

function Iniciar_Tabla_Interfaces() {
global $wgParser;
# Enlazar la palabra ‘tablainterfaces’ con nuestra funcion
$wgParser->setFunctionHook( ‘tablainterfaces’, ‘EscupirTablaInterfaces’ );
}

function ElParseador_Magico(&$magicWords, $langCode ) {
# Add the magic word
# The first array element is case sensitive, in this case it is not case sensitive
# All remaining elements are synonyms for our parser function
$magicWords[‘tablainterfaces’] = array( 0, ‘tablainterfaces’ );
# unless we return true, other parser functions extensions won’t get loaded.
return true;
}

function EscupirTablaInterfaces(&$parser, $dispositivo = ”, $community = ” ) {
# The input parameters are wikitext with templates expanded
# The output should be wikitext too
# Codigo SNMP inspirado por jmartinson(AT_nospam)info234.com en php.net

// Solamente valores. Sin esto, devuelve el tipo tambien, p.e.: INTEGER: 1
snmp_set_quick_print(TRUE);

// For sequence types, return just the numbers, not the string and numbers.
// snmp_set_enum_print(TRUE);

// Don’t let the SNMP library get cute with value interpretation.  This makes
// MAC addresses return the 6 binary bytes, timeticks to return just the integer
// value, and some other things.
// snmp_set_valueretrieval(SNMP_VALUE_PLAIN);

$ifIndex = snmp2_walk(“$dispositivo”,”$community”,”interfaces.ifTable.ifEntry.ifIndex”);
$ifDescr = snmp2_walk(“$dispositivo”,”$community”,”interfaces.ifTable.ifEntry.ifDescr”);
$ifAdminStatus = snmp2_walk(“$dispositivo”,”$community”,”interfaces.ifTable.ifEntry.ifAdminStatus”);
$ifOperStatus = snmp2_walk(“$dispositivo”,”$community”,”interfaces.ifTable.ifEntry.ifOperStatus”);

$tabla =  ‘{| border=”0″‘.”\n”;
$tabla .= ” |+ Tabla de interfaces de $dispositivo\n”;
$tabla .= ” ! Puerto !! Descripci&oacute;n !! Estado oper. !!
Estado adm.\n”;
$tabla .= ” |-\n”;

for ($i=0; $i<count($ifIndex); $i++) {
$tabla .= ” | $ifDescr[$i]\n”;
$tabla .= ” | “.snmp2_get(“$dispositivo”,”$community”,”IF-MIB::ifAlias.”.$ifIndex[$i]).”\n”;

$tabla .= ” | $ifOperStatus[$i]\n”;
$tabla .= ” | $ifAdminStatus[$i]\n”;
$tabla .= ” |-\n”;
}

$tabla .= ” |}\n”;

return $tabla;
}
?>

El tiempo no pasa en balde, y aquella ñapilla que iba bien para tres o cuatro armarios con un puñado de switches en total, ya no llega. No solo por su inexistente modelo de seguridad; es que no creo que nadie la haya probado en Mediawikis más modernos que la versión de hace ocho años.

Afortunadamente, existe Eslovenia. La “Suiza del Este” ha dado su cuota de gente interesante, pero de particular interés hoy es un tipo llamado Miha Petkovsek.

El hijo de su ingenio, phpipam, es justo lo que su nombre da a entender: Una aplicación en php, sencillita pero pulcramente escrita, que permite llevar un inventario de las direcciones IP. En versiones recientes, también cuenta con un sencillo, casi rudimentario, pero útil, inventario de equipos; incluyendo coordenadas tales como ubicación geográfica, armario y U. ¿A que mola?

Phpipam tiene, por supuesto, su API REST que permite engancharlo (a base de wget si es menester) con los escriptillos y ñapillas diversas que adornan cualquier NOC que en la vida es.

La instalación no puede ser más sencilla; usa una base de datos MySQL, como la mayor parte de este tipo de aplicaciones. Se colocan los ficheros en su sitio, se configura el acceso a la base de datos, y a correr.

dehydrated y Apache

Si antes lo digo… Hoy he tenido que instalar dehydrated con Apache.

Igual que con nginx, es la sencillez misma; pero no puedo pasar la oportunidad de dejar testimonio de una configuración de ejemplo con Apache, típicamente guardada (en Debian) en /etc/apache2/sites-available/midominio.mitld.conf:

<VirtualHost *:80>
 ServerAdmin webmaster@localhost
 ServerName midominio.mitld
 DocumentRoot /var/www
 <Directory />
  Options FollowSymLinks
  AllowOverride None
 </Directory>
 <Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>
 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 <Directory "/usr/lib/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>
 ErrorLog ${APACHE_LOG_DIR}/midominio.mitld.errores
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/midominio.mitld.accesos combined
 Alias /.well-known/acme-challenge /var/lib/dehydrated/acme-challenges/
 <Directory "/var/lib/dehydrated/acme-challenges">
  Require all granted
 </Directory>
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
 ServerAdmin webmaster@localhost
 ServerName midominio.mitld
 DocumentRoot /var/www
 <Directory />
  Options FollowSymLinks
  AllowOverride None
 </Directory>
 <Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 </Directory>
 ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
 <Directory "/usr/lib/cgi-bin">
  AllowOverride None
  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
  Order allow,deny
  Allow from all
 </Directory>
 ErrorLog ${APACHE_LOG_DIR}/midominio.mitld-ssl.errores
 LogLevel warn
 CustomLog ${APACHE_LOG_DIR}/midominio.mitld-ssl.accesos combined
 # SSL Engine Switch:
 # Enable/Disable SSL for this virtual host.
 SSLEngine on
 SSLCertificateFile /var/lib/dehydrated/certs/midominio.mitld/cert.pem
 SSLCertificateKeyFile /var/lib/dehydrated/certs/midominio.mitld/privkey.pem
 <FilesMatch "\.(cgi|shtml|phtml|php)$">
  SSLOptions +StdEnvVars
 </FilesMatch>
 <Directory /usr/lib/cgi-bin>
  SSLOptions +StdEnvVars
 </Directory>
</VirtualHost>
</IfModule>

El resto de la instalación es idéntico a nginx, y también con la salvedad de activar el módulo SSL después de ejecutar dehydrated -c por primera vez y por tanto tener el certificado ya preparado.

En Debian, esto se hace con la sencilla y elegante instrucción

sudo a2enmod ssl

Seguido, si es menester, por

sudo apache2ctl restart

A pasarlo pipa.

dehydrated y nginx

dehydrated es un cliente ACME escrito en bash.

Resulta extremadamente sencillo de montar y está empaquetado en Debian (desde jessie-backports en adelante), por lo que desplegarlo es trivial. Sin embargo, la documentación, aunque completa, es quizá algo confusa. Especialmente, considerando que lo que quiere hacer la mayor parte de la gente es obtener su certificado y olvidarse del asunto. Pues bien, esto se hace de la siguiente manera:

  1. apt-get install dehydrated
  2. echo “midominio.mitld” > /etc/dehydrated/domains.txt
  3. Configurar el servidor web
  4. Pedir el certificado
  5. Poner un cron que lo renueve periódicamente

Respecto al punto 3, esta es una configuración de ejemplo para nginx. La parte de SSL no funcionará hasta el final del proceso, por lo que hasta entonces no se puede introducir, o nginx no arrancará:

server {
 listen 80;
 server_name midominio.mitld;
 location /.well-known/acme-challenge {
 alias /var/lib/dehydrated/acme-challenges/;
 }
}
server {
 listen 443 ssl default_server;
ssl on;
 ssl_certificate /var/lib/dehydrated/certs/midominio.mitld/cert.pem;
 ssl_certificate_key /var/lib/dehydrated/certs/midominio.mitld/privkey.pem;
 ssl_trusted_certificate /var/lib/dehydrated/certs/midominio.mitld//fullchain.pem;
server_name midominio.mitld;
}

Esto puede ir en /etc/cron.monthly/renovar-certificado:

#!/bin/dash
/usr/bin/dehydrated -c && /usr/sbin/nginx -s reload

Y ya está. No hay más que ejecutar una vez /usr/bin/dehydrated -c para pedir el certificado, meter la configuración de ssl en nginx, recargar nginx, y listo.

Editado en 23 de Agosto de 2017 para añadir mandar una señal reload a nginx: de lo contrario, no leerá el certificado renovado.

Mover un hipervisor de un vCenter a otro

Aprovechando la necesidad de reconstruír un vCenter debido a una muy extraña incidencia en un por demás fiable servidor Dell, decidí bajar el vCenter empaquetado que ofrece vmware.

Esto no es otra cosa que vCenter en Linux, concretamente una SuSE, con el software necesario para comportarse como un vCenter, empaquetado como una máquina virtual lista para desplegar.

He de decir que, aunque es un poco alienígena (¿qué ha hecho vmware que no lo sea?), funciona bastante bien en general. Y librarse de la licencia de Windows, y del Windows propiamente dicho, sienta bastante bien; no lo vamos a negar.

Ahora bien, hay que mover los hipervisores de un vCenter a otro. Y el switch distribuído está definido a nivel de vCenter, por lo que al cambiar de vCenter, las máquinas virtuales dejan de tener información sobre a dónde están conectados sus puertos. De momento funciona, pero no se puede tocar ni un puerto de una sola máquina virtual. ¿Qué vamos a hacer?

Migrar los puertos al switch distribuído del vCenter nuevo, claro.

Hay una opción maravillosa, al añadir un hipervisor al inventario de redes (Inventory->Networking) que casi no se ve: Migrate virtual machine networking.

Con esto, podemos elegir (tediosamente, puerto por puerto) a dónde conectar cada uno de los puertos de red de cada una de las máquinas virtuales.

Por supuesto, antes de desconectar el hipervisor del vCenter antiguo, hay que tener claro:

  1. Qué puerto(s) físico(s) del hipervisor es/son el/los asignado(s) al switch distribuído, para marcarlos al dar de alta al hipervisor en el inventario de redes.
  2. A dónde va cada puerto de cada máquina virtual.

Lo primero es trivial de mirar en la configuración; para lo segundo, me he hecho este pequeño guioncillo de PowerShell:

# Usuario y vCenter
$vcServidor = ‘vcenter.micasa'
$vcUsuario = ‘miusuario'
$vcClave = ‘miclave'
$hv=‘mihipervisor'
$historico = "C:\Users\yomismo\$(Get-Date -uformat "%Y%m%d-%H%M%S").sucesos"
Start-Transcript -Path $historico
Connect-VIServer $vcServidor -User $vcUsuario -Password $vcClave
$MVs = get-VMHost -name $hv | get-vm | sort name
Foreach($MV in $MVs) {
   $Adaptador=get-vm $MV | get-NetworkAdapter
   Write-Host ($MV.Name+" "+$Adaptador.NetworkName)
}

Armados con este conocimiento, y la paciencia de marcar a mano a cada interface en su red, podemos hacer el movimiento casi en menos que lo que se tarda en contarlo.

Por supuesto, es enteramente posible guardarnos la configuración de las máquinas virtuales y luego colocarlas con el mismo guioncillo. Pero entonces, ¿dónde estaría nuestro ojo inquisidor para detectar anomalías, ya de paso?

Ruby y Python

Muchos, me atrevo a decir casi todos los que trabajamos en empresas relativamente pequeñas, estamos acostumbrados a que, tarde o temprando, hay que hacer de todo. Sin ir más lejos, hoy he cambiado un interruptor de luz de la oficina. Bien, pues eso es la parte de hardware: ahora, vamos con el software.

Hace poco, me empeñé en automatizar ciertas operaciones relacionadas con dominios que se hacían a mano, con el riesgo de retrasos y errores que ello entraña y que, de hecho, han generado más de un alzar de cejas. Es un affaire en el fondo sencillo, pero hay que hablar con tres APIs de tres proveedores diferentes en tres países distintos, que no siguen una norma común más allá de lo habitual del uso de json y la filosofía REST tan de nuestros días. Ah, y generar un XML.

La primera versión, para probar, la hice en Bash a base de curl. Curl es una herramienta potente, pero el manejo de flujos de programa en Bash recuerda demasiado que el inefable señor Bourne (nada que ver con el señor Burns, aunque suene casi igual), todo lo que necesitaba era una shell para hacer cuatro cosas. Bastante lejos ha llegado.

Total, que inspirado por un programita que me enseñó un compañero, me puse a hacer una siguiente versión en Python, sin haberlo usado en la vida anteriormente, usando la metodología que nuestro desarrollador de referencia llamó SODD: Stack Overflow Driven Development. Pues bien, Python fue un lenguaje sumamente fácil de aprender para hacer algo sencillo. Las cosas salen con facilidad y, a pesar de que no pretendo ser un programador, me resultó fluido hacer un programa de 200 líneas que cumple su cometido.

Me he limitado a las librerías que vienen de serie con una instalación normal en Debian, y aún así, ha sido razonablemente sencillo encontrar lo necesario para manipulación de fechas, POST, GET, un poco de números y cadenas.

Luego decidí aprovechar para aprender Ruby, y porté el programita.

Me sucedieron inmediatamente varias cosas:

  1. No entiendo Ruby. Hay cosas que no sé por qué funcionan, y otras que no sé por qué no. Hay partes de la sintaxis que me resultan alienígenas. Esta sensación no la tengo con Python.
  2. Hay cosas extrañamente difíciles de hacer. Un POST, por ejemplo. No he encontrado forma de hacerlo si no es con una gema aparte, o con un bloque de código, o con ambas cosas. También enviar correo se me hace algo aparatoso comparado con Python.
  3. El programa engordó un 15%, especialmente por los bloques necesarios para los POST.
  4. La escritura de xml es mucho más elegante (siempre hablando de las librerías que vienen “de serie”), si bien con una sintaxis algo alienígena, pero elegante y ligera.

Total. Que el programita de los demoniosdominios lo voy a mantener con Python, y le daré otra oportunidad a Ruby cuando tenga que hacer (si llega el caso, que llegará) alguna pequeña aplicación web. Según me ha asegurado el antes aludido, en ese momento las cosas van a favor de Ruby (on Rails). Claro, que también ha dicho que el futuro es Rust… Así que no sé. Estoy por volver a Bash.

Las iDRAC molan. A veces. Salvo que te las cargues actualizando

Las iDRAC antiguas, en particular las iDRAC 6 y anteriores, tienen sus manías. Más manías cuanto más antiguo es el firmware, hasta el punto de ser poco menos que intratables: Solo funcionan con versiones prehistóricas de ie, les petan las actualizaciones, no les funciona https… En fin, esas cosillas.

A veces, es posible que una de estas iDRAC antiguas petardee al actualizar, y las cosas se van rápidamente a la alcantarilla. El peor caso que he conocido necesitó comprar un recambio. ¿Qué recambio? Ahí está lo gracioso: Dell parece hacer como si no existiera.

En los fiables (aunque ya venerables) r610, el acceso fuera de banda al servidor está compuesto de dos piezas separadas: La placa que contiene el puerto Ethernet (y que habitualmente se llama iDRAC a secas) y otra placa que se llama iDRAC express, y que no es otra cosa que una BMC glorificada. Para confundir las cosas, el firmware no va en la iDRAC, sino en la iDRAC express. Y la iDRAC express, va de serie en los r610, y no se vende como recambio normalmente. De hecho, en el esquema del servidor donde se dice dónde van hasta cosas tan raras como la licencia de iSCSI (que es una especie de llave física), no se hace ni mención a la iDRAC express, pero sí a la iDRAC, que es opcional.

Pues bien, cuando la actualización de firmware de iDRAC se va al desagüe… ¿A que no adivinas qué placa es la que se ha quedado gagá? Claro, como no podía ser de otra forma: La que “no existe”.

¿La solución? Bueno, tal vez sea posible recuperarla por el método descrito aquí, usando el puerto serie virtual para acceder a la consola de recuperación. Pero si no, no hay problema: Nos vamos a eBay, y preguntamos por una iDRAC 6 express. Las he llegado a ver por un euro (mas 18 de envío). Os aseguro que es más barato que el tiempo que se puede llegar a perder peleando con una iDRAC 6 express mal flasheada (y disculpad el barbarismo). Creedme, aunque os costara 50 euros, seguiría siendo barato.