Mi nuevo portátil HP dv5-1132es

Hace unas semanas me compré un nuevo portátil en MediaMark aprovechando la ayuda de 200€ que nos dá nuestro gobierno regional. El portátil es como el que ahora mismo tienen en oferta por 699€ con el anuncio del avión, pero con ligeras diferencias, por aquello de que yo sí soy tonto: Me costó 799€ y es un modelo HP Pavilion dv5-1132es, que en resumen tiene un poco más de procesador que el de la oferta, 1GB más de RAM, algo más de disco duro, y un modelo superior de tarjeta gráfica.

Aunque aún no he terminado de ponerlo a punto (como siempre Fedora tiene la culpa de mis desgracias), le he instalado perfectamente Ubuntu 8.10 en 32bits (todo funciona perfectamente), Fedora Core 10 en 64bits (tengo problemas con el sonido y con la WIFI), Windows Vista (que viene de serie) y he probado a instalar Hackintosh 10.5.4 (funciona todo excepto la suspensión) y que al apagar no termina de apagarse completamente). Este post lo estoy escribiendo con ECTO sobre leopard acostado en el sofá y conectado con la Wifi.

No habría podido instalarlo correctamente si no es por la inestimable ayuda de Jesús Gómez, que se estuvo peleando con esto durante varios días. Conseguí que funcionara todo de la siguiente forma:

1. Instalar leopard 10.5.2 desde la imagen Kaliway.


2. Actualizar a leopard 10.5.4 desde la imagen de iATKOS 4i sin formatear siguiendo http://forum.insanelymac.com/index.php?showtopic=127885&pid=904505&mode=threaded&start=#entry904505. La idea es seguir los pasos del foro y seleccionar el driver para VGA – Nvinjet de 256Mb, y en System todo excepto ext2fs y ntfs-3g. En red eligir realtek 8139 y broadcom 440x.
3. Al hacerlo tendremos un problema de permisos, por lo que habrá que subsanarlo siguiendo http://docs.info.apple.com/article.html?artnum=306876-es.
4. Para instalar la Wifi Broadcom 4310, podemos seguir http://forum.insanelymac.com/index.php?showtopic=51725. En el hilo de mensajes del foro descargaremos el Script v0.5.1. Lo descomprimiremos y desde un terminal ejecutaremos:

   sudo ./bcm43xx_enabler.sh

   Luego reiniciaremos el equipo. Luego vamos a Preferencias-Red y eliminamos Red Airport.
5. Para el sonido seguimos http://forum.insanelymac.com/index.php?showtopic=132495&pid=942841&mode=threaded&start=#entry942841: Descargar HDAEnabler.kext, eliminar los ficheros /System/Library/Extension/AppleHDA.kext y /System/Library/Extension/HDAEnabler.kext (si lo tenemos). Copiar AppleHDA.kext y DAApple.kext en la carpeta /System/Library/Extension y eliminar /System/library/Extension.mkext. Ejecutar los siguientes comandos para actualizar los permisos, y luego reiniciar

   chown -R root:wheel /System/Library/Extensions
   chmod -R 755 /System/Library/Extensions/AppleHDA.kext
   chmod -R 755 /System/Library/Extensions/HDAapple.kext

Tomcat y enlaces simbólicos

Esta semana pusimos una aplicación Java bajo Tomcat 5.0 en alta disponibilidad. Para ello, la aplicación necesita usar un sistema de archivos compartido, que configuramos mediante NFS remoto. Los directorios donde se guardan los ficheros compartidos caen dentro del contexto de la aplicación, por lo que decidimos sacarlos al directorio NFS, y en su lugar dejar enlaces simbólicos. El problema que sucede entonces es que a Tomcat (igual que Apache) tenemos que decirle que siga los enlaces simbólicos.

Esto se le puede decir con el atributo allowLinking="true" en la etiqueta <context>, que encontraremos de forma aislada en el fichero XML del contexto de nuestra aplicación, dentro de los subdirectorios conf/Catalina/localhost/ o conf/Standalone/localhost (según hayamos definido el Engine en server.xml), o bien el en el propio conf/server.xml, dentro de <Server><Service><Engine><Host>

<context path="/mi-aplicacion" 
         docBase="DIRECTORIO_de_mi_aplicacion"
         allowLinking="true"/>

Evento Citrix en Murcia

Hace unas semanas estuve en un evento que Citrix celebró en Murcia. Estuvo organizado por el grupo inforges y resultó muy interesante porque pudimos descubrir cómo Citrix ha re-bautizado sus productos tras la adquisición de XenSource y Ardence, y encontrar las analogías con lo que conocemos del mundo VMware.

1. XenServer se correspondería con VMware ESX Server. Dispone de hasta cuatro versiones de licenciamiento. XenServer Express Edition es gratuito hasta 4 máquinas virtuales corriendo en un único servidor. En la Enterprise Edition hay disponible un XenMotion (equivalente a VMotion).
2. XenCenter se correspondería con VMware VirtualCenter.
3. XenConvert se correspondería con VMware Converter. Este producto permite virtualizar equipos, generando una imagen .XNA que luego podemos importar desde XenCenter.
4. Citrix Provisioning Server, es lo que llaman Streaming de Sistema Operativo, y al final consiste en una herramienta para poder desplegar el sistema orativo como hace Altiris Rapid Deployment Pack vía PXE entre otros.
5. XenApp es la suite clásica de productos Citrix (ICA) que ya conocíamos (Metaframe, SecureGateway, etc) que han provisto además de posibilidades para el streaming de aplicaciones (lo que hace SoftGrid de Microsoft) o virtualización de aplicaciones. Resultó interesante ver un vídeo que demostraba como el protocolo RDP6 de Micrsoft aún tiene mucho que mejorar para hacer sombra a ICA, sobre todo bajo conexiones lentas

De pasada me quedé con las herramientas libres de inventario que están pegando duro: GLPI que están poniendo en marcha en la Consejería de Hacienda, y OCS Inventory que estamos poniendo en marcha en la Consejería de Educación.
En lo que se refiere a la virtualización del escritorio XenDesktop (se apoya en ActiveDirectory, igual que hace VDI de VMware, y sólo podemos usarlo bajo Windows 2003) presentaron los cuatro formatos en las que lo encontramos (Express, Platinum, Standard, Enterprise): La edición Express permite 10 hasta usuarios de forma gratuita. La Enterprise incorpora licencias de XenApp (lo que sería el Presentation Server) de forma que nos permite degustar los dos sabores, para pode determinar qué es mejor: si virtualización de escritorios o de aplicaciones. XenDesktop se fundamenta en portICA que es un protocolo distinto a ICA, que está en pleno desarrollo y que sólo permite virtualizar escritorios Windows XP, Vista y 2008.

VMware VMotion entre CPUs diferentes

Hace una unas semanas configuramos en un cliente VMware VirtualCenter 1.3 sobre los dos servidores ESX que tenía instalados. Estos servidores eran un IBM xSeries 346 y un 345, prácticamente con el mismo hardware pero diferían en el modelo de CPU: Uno llevaba un intel xeon 3.2GHz y el otro iba con un intel xeon 2GHz.

Cuando lanzábamos el live-migration de vmotion en caliente nos encontrábamos que no podíamos hacerlo, y nos daba un el error:

Error: Cannot migrate between hosts with different CPUs. Supported extended features differ. (Source: 0x00000000, Destination: 0x0000001d)

En los foros de VMware existen diferentes soluciones, pero probablemente ninguna se ajuste a lo que necesitamos. El documento que mejor explica este problema lo encontramos en VMotion CPU Compatibility - Migrations Prevented Due to CPU Mismatch - How to Override Masks, donde comenta que todo se debe a un problema máscaras de bits, por lo que las soluciones que a otras personas les funcionaron, no tienen por qué servirnos.

Lo que tendremos que hacer, es ejecutar el comando cat /proc/vmware/cupinfo y observar la salida, y buscar el campo al que hace mención el error (Supported extended features differ), que en nuestro era extFeat: Para un nodo valía 0x0000441d, y para el otro 0x00004400, que al hacer un OR-Lógico nos devolvía el error que estábamos obteniendo: 0x0000001d. En ese momento calculamos la máscara que tendríamos que aplicar para que al hacer el XOR-Logico el resultado fuera 0x00000000. En nuestro caso, la máscara que probamos nos funcionaba fue: 0xE5FF.

Una vez tenemos la máscara, debemos crear el fichero C:\Documents and Settings\All Users\Datos de programa\VMware\VMware VirtualCenter\config.ini con el siguiente contenido:

migrate.ignore.extfeature.bits = 0xE5FF
migrate.ignore.feature.bits = 0x20000

, reiniciar el servicio VirtualCenter y volver a probar el live-migration.

Comandos dmidecode y wmic

Siguiendo las entradas compartidas de Reader de Rubio, me he encontrado que podemos averiguar el modelo de nuestro equipo, número de serie, etc con el comando dmidecode del paquete con el mismo nombre:

dmidecode -s system-product-name
dmidecode -s chassis-serial-number

En el barebone de casa no ha funcionado, pero de rebote he encontrado el comando wmic en Windows, que permite lanzar consultas WMI desde una consola de Windows, algo así como el WMIExplorer del que ya he hablado alguna vez, pero para consola.
Para saber nuestro numero de serie y modelo de BIOS vía WMI, podemos ejecutar en una consola de Windows:

wmic bios get serialnumber
wmic bios get

El Kernel-PAE en RHEL5

Al parecer, lo que pasa si tenemos un equipo con más de 3GB de RAM y le instalamos RHEL5/Centos5, sólo veremos que el sistema tiene 3GB. Esta tarde me ha pasado, y me he preocupado bastante, porque estaba trabajando con blades de IBM con 6GB de RAM, y he pensado que me habían llenado los slots con DIM de Spare ¿?. Menudo susto, luego resulta que es una tontería, y todo se soluciona instalando el kernel-PAE, siempre que las CPUs incluyan "Physical Address Extensions".

yum install kernel-PAE kernel-PAE-devel

Editar la configuración de grub, para asegurarnos de que en el siguiente reinicio arrancamos con este kernel y reiniciar.
Con RHEL4 en el mismo tipo de Blades HS21 y sin kernel hugemem, me reconocía perfectamente los 6GB. Esto son los misterios de la informática que nos invitan a reflexionar si se fundamenta verdaderamente sobre ciencias exactas o aproximadas.

Conceptos VMware e IBM

El miércoles pasado, estuve en una charla que organizó el Grupo Inforges en el hotal Amistad, sobre VMware y soluciones Blade de IBM. Para ello tuve que descartar asistir al TechNet que se organizaba en Murcia. Las cosillas que me enteré de forma resumida fueron:

• En VMware, DRS es el VMotion dinámico.
• La solución de VMware para optimizar el consumo eléctrico de nuestra granja ESX es DPM, que lo que hace es mover máquinas virtuales y apagar servidores ESX, para minimizar el consumo.
• VMware HA, se encarga desde el VirtualCenter de detectar que un ESX ha muerto, y entonces levanta las máquinas virtuales en otro ESX, pero claro, esto tiene una parada, no es como el VMotion.
  
• Modelos de licenciamiento en el ESX:
  • ESXi, es la gratuita, para empezar a trabajar con la infraestructura virtual
  • ESX fundation, es como el ESXi, mas el Backup Consolidation, Update Manager (algo así como el SUS para VMware), el agente de Virtual Center.
  • Standard, que lleva lo mismo que el anterior, pero con VMware-HA.
  • Enterprise, el que incluye todo: DRS, Vmotion, etc
    
• Modelos de licenciamiento del VirtualCenter:
  
  • Fundation, que permite controlar hasta 3 ESX
    
  • Full, sin límite de ESX que poder controlar.
    
• Al hablar de Disaster Recovery encontramos,
  
  • RTO, cantidad de tiempo que tardamos en ser operativos
    
  • RPO, Hasta el punto que debemos retroceder en una caída.
    
  • En VMware encontramos Site Recovery Manager, que permite automatizar la parada y recuperación desde el segundo CPD, con ayuda de herramientas del almacenamiento como MirrorView o SRD de EMC, o ERM de IBM
    
• También hablamos de VDI, y los elementos que se necesitan para trabajar con él: La infraestructura ESX 3i, el VirtualCenter y VDM que es un broker de conexiones que requiere del directorio Activo, y que haría las veces de CSG+Presentation Server (si lo comparamos con la infraestructura Citrix. Más tarde en el aperitivo, tuve ocasión de hablar con los técnicos que ya están trabajando en estas soluciones y les pregunté sobre VDI vs XenDesktop: Se mojaron, y me comentaron que la solución de Citrix resulta más atractiva porque por el mismo precio te ofrecen virtualización de escritorio y de aplicaciones, que según para qué cosas puede interesar una cosa u otra.
  
• Ya sobre hardware VMware vimos el BladeCenter S, que está bastante, bastante bien para PYMES, que no tienen porqué racks: En uno de estos Chasis nos dejan casi el CPD entero... está muy, muy bien. Permite meterle todo (blades, array de discos, circuitería de red, KVM), etc y todo en 11Us, sin necesidad de RACK.
  
• Además de este tipo de BladeCenter está el E y el H, donde la diferencia estriba en el número máximo de conexiones que permite sacar (switches que podemos meterle), y que es importante de cara a los Blades que luego deberemos comprar, por aquello de que no todos los Blades les podemos pinchar tarjetas de red o de fibra, de 8 puertos, etc.
  
• Las familias de blades son: HXXX (micro intel), LXXX (micro AMD), JXXX (micro Power6) y QXXX (micro cell), y que todos los blades pueden pincharse en el mismo chasis. Según la gente de IBM, uno de los valores diferenciales de su BladeCenter es que todas las especificaciones son libres (como ya hicieran con el PC), y otros fabricantes empiezan a fabricar Blades compatibles con este BladeCenter.
  
• En cuanto a filosofía de cabinas, parece que la hermana menor es DS3000 que puede llegar a DS5000 (no sé donde quedan las FasT), y que en productos ERM es equivalente a MirrorView de EMC, y FlashCopy a SnapShot de EMC.