Consulta Técnica: Conversión de máquinas linux.

Hace unos días nos preguntaban:

"Hola Jose Luis, bucando,buscando por ahi, he llegado a tu blog.

Estoy intentando vistualizar en ESXi una maquina física con Suse Linux 7.2 y kernel 2.2.19. Tiene unas viejas aplicaciones en cobol que se configuraron hace años, estan emuladas con ibcs porque originariamente eran para Unix Sco. y no tengo ni idea de como montarlas en un entorno nuevo.

Lo he intentado con vmware converter stand alone sin exito. Alguna ayuda, por favor?????

Gracias anticipadas."

La conversión de máquinas linux con converter nunca ha sido un tema simple. Quiero decir que cuando funciona, lo hace a la primera... pero cuando no...

He aquí mi receta, al menos la que me ha funcionado en varias ocasiones:

1. Clonado de la máquina física.

Para el proceso de clonado, yo uso Ghost For Linux. Sé que hay otras herramientas (a gusto del consumidor), e incluso con un dd directamente desde un CD de arranque con linux, pero a mi, casi siempre, Ghost for Linux me ha dado buenos resultados. Frente a dd, permite compresión de la imagen de destino, y con un poco de suerte, sólo te vuelca el espacio de disco usado, no el disco entero.

Ghost for linux tiene una interface algo rebuscada, por lo que aconsejo hacer alguna prueba antes. Sobra decir que has de sacar la imagen sobre un disco USB o similar.

2. Conversión en máquina virtual - Fase 1.

Una vez tengas la imagen de la máquina virtual en un disco USB, vamos a convertir esa imagen en una máquina virtual. Para ello, necesitaremos VMware Workstation, VMware Player o cualquier producto soportado por VMware Converter como máquina virtual a convertir.

Esta VM debería tener la siguiente configuración:

- Disco 0: Un disco de igual o mayor capacidad que la del servidor original a convertir. La controladora debe ser IDE o Buslogic.... En destribuciones antiguas no se suele encontrar el driver LSI.

- CD: La imagen ISO de Arranque de Ghost For Linux

- USB0: El disco USB donde hemos sacado la imagen del servidor a convertir.

Opcional: En caso de no poder/querer usar la opción de mapeo USB, siempre podemos mapear el disco USB en modo RAW a la VM a crear.

Una vez configurado el hardware virtual de la VM, procederemos a arrancarla desde el CD virtual (es decir, con la imagen de Ghost for Linux)

Tras arrancar, Clonaremos la imagen que sacamos en el disco USB sobre el disco 0 de la VM.

3. Arranque de la VM.

Una vez convertida la VM, cruzamos los dedos y arrancamos la máquina virtual. Si todo va bien, la VM debería arrancar sin problemas..... pero si al arrancarla nos da un "kernel panic" es posible (y más que probable) que el driver de disco IDE o Buslogic no esté configurado. Ahora vendrá la parte divertida.

En este momento es buena idea tener a mano un rescue disk de la distribución linux que nos ocupa, o en su defecto, un Live CD de cualquier distribución. Reconfiguraremos la VM para que el CD virtual apunte a la imagen ISO o CD de recuperación, y rearrancaremos la máquina haciendo que esta arranque desde este CD o ISO.

Una vez arrancado y en la lshell, procederemos a montar el disco 0 en, por ejemplo, /mnt/sysimage. Una vez hecho esto, hagamos un chroot a /mnt/sysimage.

naveguemos entonces dentro del nuevo root a la carpeta /etc, y allí encontraremos el fichero modules.conf . Editaremos la línea del alias correspondiente a la controladora de disco original del servidor físico, substituyéndola por el driver Buslogic.

Ahora cambiemos al directorio /boot y, mediante el comando mkinitrd, regeneremos el ramdisk de arranque. (mkinitrd -f -v /boot/initrd-[versión]-img [versión]

Reiniciemos la máquina virtual, desconectemos el CD y, con un poco de suerte, la máquina arrancará a la perfección.

Es buen momento para isntalar las vmware-tools en la VM.

4. Conversión en máquina virtual - Fase 2.

Ahora, y tras apagar la VM, usaremos el converter para pasar nuestra VM a los ESX.

Este no es un proceso infalible, especialmente si usas LVM o si el driver Buslogic no está en el disco original de la máquina. Pero a mí me ha funcionado en unas cuantas ocasiones. Te dejo un par de Links que serán seguro de ayuda.

Un saludo

Linux P2V

How to P2V a Linux machine

Consulta Técnica: View y Thin Clients

Nos pasan la siguiente consulta:

"Hola JL,

Estoy leyendo tu blog con mucho interés y tengo unas dudas sobre VDI.

Estoy viendo la posibilidad de implantar thin clients en mi empresa y me surge la siguiente duda:

Si pongo thin clients con windows embedded con el view client de vmware, necesitaré un antivirus para proteger los thin clients, ya que no dejan de ser unos mini-pcs con windows?

También he pensado en poner thin clients con linux, que suponemos que tienen el vmware-view-open-client, pero he visto que no soportan la redirección de USB, lo cual es un problema. Sabes si esto es así en estos clientes?

También he pensado en reutilizar los pcs actuales, quitandoles el HD y arrancando por PXE y ejecutando el cliente vmware-view-open-client desde una sesión de LTSP. ( https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall http://www.jaimebalmes.org/php/mod/resource/view.php?id=409 )

Por otra parte, qué platafoma de gestión nos recomiendas para gestionar los thin clients sena linux o windows?


Muchas gracias por tu tiempo.

Saludos."

Efectivamente. Si utilizas Thin clients basados en Windows XP (sea o no embedded) sigue siendo un Windows XP, eso sí, con menos "superficie" de exposición a virus y demás, lo que no implica que debamos prescindir del Antivirus, ya que en un entorno mixto, como dice el maestro Ros, la podemos liar parda. Por otro lado, un entorno de thin clients Linux nos obligará a prescindir de la redirección USB de View, olbligándonos a ir a productos de terceros, salvo que el fabricante disponga de licencia de VMware para la redirección de USB.

Mi recomendación sobre la plataforma de gestión de los Thin Clients es clara: Ninguna. Nunca he terminado de entender eso de migrar a Virtual Desktop para sustituir SMS o System Center por un Thin client management. El uso de clientes basados en linux o Windows obliga, en mayor o menor medida, a disponer de una plataforma de gestión de los mismos, y mi recomendación es que la gestión tire a inexistente. Es un hecho que la plataforma del Thin Client variará substancialmente su precio dependiendo de si el cliente corre o no Windows (Normalmente la gestión de clientes basados en Windows suele ser más cara e implica mayor nivel de gestión).

Tanto en un caso como en otro, el Thin Client puede convertirse en un punto de fallo dentro de la infraestructura View, ya que su propia "inteligencia" lo hace - eso sí, bastante menos - susceptible a fallos en los procesos de actualización y configuración.

Respecto a la opción de convertir PC's en Thin Clients, además de la que comentas (LSTP), dispones de Thin Station, una minidistribución altamente configurable, que incluso dispone de configuradores Web donde "montarte" tu cliente ligero desde ella (los TS-O-MATIC). En el mirror de Dinamarca (DK) incluso te permite integrar el cliente View de VMware. Estos ts-o-matic te permiten crear desde imágenes ISO a imágenes PXE para el arranque. Recomiendo fervientemente esta distribución como iniciación de bajo o nulo coste al mundo del Virtual Desktop.

Si lo que buscas es una solución robusta, sin intervención en el thin client del usuario, que permita redirección USB, compatibilidad con VMware View, en la que despreocuparte ABSOLUTAMENTE del dispositivo y a un coste unitario realmente interesante, te recomiendo los SUN Ray de SUN Microsystems. En mi compañía (y en varios clientes) tenemos la solución funcionando en menos de dos horas. Es realmente elegante y ciertamente potente. Las características incorporadas en la versión 5 (aceleración multimedia, aceleración flash, USB Mapping) junto con las ventajas de siempre (hot desking, multiple monitors - hasta 8, creo recordar) hacen de SUN Ray, al menos para mí, la solución Thin client perfecta. Por no necesitar, no necesitan IP del entorno corporativo. El terminal SUN Ray (DTU para los amigos) es simplemente eso: Un terminal del servidor SUN Ray. Las conexiones con los virtual desktop se realizan desde este, y no desde el terminal, es decir, el SUN Ray client no es más que una pantalla y un teclado extra del servidor SUN Ray (que puede correr tanto en Solaris como en Linux). Te invito a verlo cuando quieras.

Un cordial saludo.

Consulta Técnica: Rendimiento iSCSI

Leonardo nos pregunta:

"Hola, me gustaria saber cual es el rendimiento adecuado para accesos a disco en un entorno SAN Iscsi , en un cliente con una cabina iscsi equalogic me esta dando en maquinas virtuales con esx 3.5 update 2 tasas de 40 MB/s ... para el cliente este rendimiento es bajo, en el esx o maquina virtual se ha configurado todo y mas de lo que se debe configurar."

El tema del rendimiento iSCSI es un tema puntiagudo, en especial en entornos donde el número es importante: Es decir, donde tenemos a alguien para quien las métricas puras y duras son un parámetro de evaluación. En mis test con ESX, con varios targets, desde un Openfiler hasta un NetApp 3020, he obtenido picos de 750 Mbit/sec (Aprox. 94 MB/sec), aunque el mantenido se establece en unos 350/400 Mbit/sec (43 - 50 MB/sec). Por comparación, he realizado los mismos test bajo Windows Server, obteniendo límites algo superiores. El dato anecdótico es que en entornos Microsoft, el rendimiento de un SQL Server (por ejemplo) no difiere excesivamente de FC a 1/2 Gb/sec... Mis conclusiones son evidentes: a) El sistema operativo tiene mucho que decir en lo que a rendimiento de disco se refiere. b) El tipo de carga es determinante. Si aún así el cliente o responsable sigue insistiendo... responde al fuego con fuego: IOMeter en las VM, comparando, por ejemplo, el rendimiento de una VM sobre iSCSI y sobre disco local/SAN FC.

En el caso de ESX, independientemente del medio de acceso al disco, el trabajo de caching del ESX es fundamental... En especial en operaciones de disco "normales", es decir, con una VM más o menos típica... La cosa cambia con las atipicidades: Un cubo OLAP, por ejemplo, requiere más atención que un web server...

Por el momento en ESX no es posible el uso de ciertas técnicas que podrían mejorar el rendimiento: TOE (TCP Offload Engine, Jumbo Frames, etc), pero se me ocurren ciertas pruebas que puedes realizar:

• Cambia de switch: La electrónica de red es importante
• dedica una VLAN exclusivamente al tráfico iSCSI
• Intenta configurar la VLAN como Private VLAN, es decir, que los host SOLO vean al target iSCSI
• Libera la CPU/Core 0 del host.

Personalmente sigo apostando por iSCSI para mis entornos, reservando la fibra para aquellos que realmente lo necesitan. Con todo, iSCSI sigue siendo infinitamente menos problemático que FC.

Un saludo.

Consulta Técnica. Datastore compartido

Ignacio me hace la siguiente consulta.

"Buenos días, antes que nada felicitarte por el blog que la verdad resulta de gran ayuda. Os planteo el entorno que tengo:Tengo 25 ESX divididos en 3 Clusters con Vi3, para cada cluster tengo creados 3 datastores para almacenar las VMs y un datastore común para los 3 donde tenemos ISOS y plantillas. Esta configuración la dejó planteada la consultura que montó el sistema. El caso es que queremos añadir un nuevo datastore que funcione igual que el común para los 3 clusters, la LUN de la SAN está ofrecida a todos los ESX de los 3 clusters. He creado un datastore mediante el boton de add storage en uno de los ESX y efectivamente ese datastore es visible por los ESX de ese cluster pero no consigo que sea visible por los ESX de los demás. ¿Cómo debo de crear el datastore o donde se administran los accesos para que lo compartan todos? Muchas gracias."

Bueno, la verdad es que no me das muchos datos sobre los que investigar, pero me da la impresión es que el problema no lo tienes en los ESX, sino en la SAN. Me explico. Es posible que hayas creado la LUN en la SAN de manera que sea visible por los miembros del cluster al que te refieres, que supongo que estarán metidos en el mismo grupo de iniciadores. Por eso sólo lo ven los nodos de ese cluster. Los accesos en Fibra o iSCSI son administrados por la SAN, Así que supongo que deberás hacer que esa LUN sea ofrecida por la SAN al resto de los ESX.

De todas formas, y centrandome sobre tu instalación (volumen respetable, si señor), te agradecería que nos contases un poco más sobre ella: SAN que utilizas, Número de LUNs... lo veo un caso de éxito sobre el que todos podemos aprender.

Un saludo.

Consulta Técnica: Compatibilidad Hardware / II

"Hola Realmente he mirado y hablado por telefono con vmware y me han dicho que la controladora 2120s "SI es soportada" , además viene en la HCL.Me pregunto que puedo hacer ahora, ¿podria instalar el esx en un disco ide y luego desde la consola de ESX bajarme los drivers de la controladora?, ¿es posible esto?, bueno , ahora mismo tengo instalado esx en el ide pero claro, no veo "storages", ¿podria instalar los drivers del scsi ahora?.Y otra cosa....¿cual seria entonces para mi servidor hp ml110g4 una controladora ideal?gracias "

Dame otro medio de contacto, messenger o similar, ya que lo que me cuentas me parece extraño.

Un saludo.

Consulta Técnica: vMotion y Almacenamiento

Cesar nos pregunta:

"Hola, primero muchas gracias a esos tipeos increibles y agotadoras respuestas que se agradecen en lo mas profundo de los bits.. Una gran consulta : es imposible usar Vmotion sin una SAN ?? o es posible con el propio VMFS de ESX implementarlo en los mismos discos del ESX. Tengo una maquina virtual que tiene como 20GB de tamaño, la cual quiero dejarla en otro ESX para hacer continuidad, pero he leido que solo vmotion funciona con SAN u otro sistema. Se puede hacer otra cosa ( aunque solo ejecute una MV en cada ESX ). Nuevamente te agradeceria infinitamente si me aclaras esta gran duda."

Creo que en otro post ya hablamos sobre el tema. vMotion requiere de almacenamiento compartido, ya sea SAN o NAS, por razones obvias: Ambos ESX han de ver el VMDK de la máquina virtual.

Un saludo.

Consulta Técnica: ¿Cómo?

Nuestro amigo Oscar nos pregunta:

"Hola que tal, ante todo felicitarte por la página.Yo acabo de empezar en esto de la virtualizacion con vmware , y acabo de instalar un INFRASTRUCTURE 3.0.2 pero tengo varias dudas:He bajado de evaluacion el VIRTUAL CENTER para infrastructure 3 pero NO entiendo como ponerlo en marcha para "centralizar" la administracion, yo lo que queria probar es a instalar dos ESX , crear maquinas virtuales en cada uno y administrarlos centralizadamente, y luego "migrar maquinas virtuales de uno a otro.., crear un entorno de cluster....".Pero no consigo ver como se pone en marcha el virtual center, yo lo maximo que he hecho ha sido bajarme el "infrastructure client" conectandome por http al esx y desde ahí conectarme al esx, pero no entiendo primero como conectarse al virtual center (o donde está la interface para hacerlo) y la diferencia entre uno y otro (me refiero a virtual center server y client).

He instalado en un server 2003 tanto "infrastructure client, como virtual center server", tampoco consigo entender como acceder via web.....

Si me puedes ayudar no sabes como te lo agradeceria."

Difícil me lo pones. ¿Te has mirado la documentación del producto? Responder a tu post requeriría un blog entero, y no sólo una respuesta. Te recomiendo la lectura detallada de:

Introduction to VMware Infrastructure
Quick Start Guide

Un saludo.

Consulta Técnica: Acceso a ESX como root

Otro anónimo nos pregunta:

"Hola a todos. Me va a servir de gran ayuda este manualillo.He empezado a hacerlo y tengo el siguiente problema:Me da "acceso denegado" cuando intento conectarme al ESX desde la aplicacion WINSCP, y todavia no consigo saber porqué .Si alguien sabe....gracias "

ESX, por defecto, no deja acceder via root. Es una medida de seguridad por defecto de SSH. Mi personal consejo es que lo dejes así. Créate una cuenta sin privilegios de root y accede por ella tanto a consola como con SCP. Si deseas habilitar root para acceder remotamente, has de modificar el fichero de configuración de ssh.

Este fichero se encuenta en /etc/ssh y se llama sshd_config. has de modificar la línea que pone:

PermitRootLogin No

y dejarla en

PermitRootLogin yes

Un saludo.

Consulta Técnica: Compatibilidad Hardware

Anónimo nos pregunta:

"Hola Tengo un servidor HP PROLIANT ML110 G4 en donde quiero instalar VMWARE ESX 3.0.2. Tengo una controladora ADAPTED 2120 S Y de momento un disco de 10.000 rpm wide ultra 320 scsi. Tambien tengo pero sin montar una 39160 de adaptec.La controladora y el disco me lo detecta perfectamente al arrancar, pero cuando meto el cd del esx y empiezo a instalar, me llega un momento en el que me dice que se ha detectado en el sistema BROADCOM TIGON3 ETHERNET (TG3) y ADAPTEC AACRAID (AACRAID_ESX30). y que si no están en la lista meta un diskete para instalar el controlador.Si esto me lo paso y doy a continuar , me dice que no tengo disco, así que por lo que veo ESX 3.0.2 no tiene estos controladores.Mi pregunta es: ¿como los consigo ahora?Y otra pregunta.... le he puesto un disco IDE y así si he podido instalar, pero me pregunto............cuando me conecte al ESX mediante infrastructure client ... ¿aparecerán los storages?, ¿aparecerá el disco scsi?"

En primer lugar, antes de desplegar ESX, debemos mirar la HCL... la Hardware Compatibility Guide.... y si nuestro equipo no está incluído, pues prepararnos a "rezar" para que nuestro hardware sea compatible. Si la cosa está como me dices, ESX no verá tu disco como candidato a albergar un VMFS... así que busca una controladora soportada... me dá que con la Adaptec que nombrabas tendrás algo más de suerte.

Respecto a los drivers, hay los que hay, salvo que algún fabricante incorpore drivers propios para su hardware (no conozco ninguno, aunque también es verdad que tampoco lo he necesitado). VMware implementa los nuevos drivers como patches o nuevas releases de ESX, así que estate atento a las release notes de cada parche.

Un saludo.

Consulta Técnica: Problemas con VMware, openfiler y iSCSI

Consulta anónima:

"Lo primero darte las gracias por toda la información que ofreces a todo el que la necesite sin pedir nada a cambio.Y lo segundo a ver si me puedes echar una mano en este problemaEl tema esta en que tu blog tienes colgado un articulo el cual explica como poner vmware esx en un servidor Windows con nfs, hasta ahí todo correcto pero el problema viene cuando al intentar colocar la vmware con un servidor iSCSI (openfiler) no lo consigoHe intentado de todo en la versión de 64 bits de este servidor de ficheros lo he conseguido conectar con un Windows 2003 a través de iSCSI conector y sin problemas pero cunado intento conectarlo con la maquina de vmware no puedo.¿Que estoy haciendo mal?En la tarjeta de red que conecto al openfiler esta creada la conexión de la consola y una conexión de vmkernel puesto que la maquina de vmware me la pide para conectar a través de iSCSI.Pero luego en la configuración de iSCSI le pongo como target la dirección de la maquina de openfiler y no me carga el espacio que tengo para poder guardar mis maquinas virtuales.De antemano gracias por tu ayuda y sigue como hasta ahora que lo estas haciendo genial."

La configuración de iSCSI no es, bajo ESX, de las labores más sencillas. Te recomiendo sigas la siguiente Checklist:

- ¿Tengo un adaptador VMkernel dedicado en iSCSI?
- ¿Tengo una Service Console en la misma red de la interface iSCSI del VMkernel?
- ¿He definido el default gateway en la interface del VMkernel?
- ¿He definido correctamente los targets iSCSI?
- ¿He rearrancado la máquina?

Espero tus noticias.

Consulta Técnica: vm system hang detection modes

Nuestro amigo Eneko nos pregunta:

"Salu2:

Siento ser repetitivo pero enhorabuena por tu blog, No te vo a aburrir con detalles de la instalacion que no vienen a cuento, en definitiva sabes alguna manera para detectar pantallazos azules o cuelgues de las maquinas virtuales aparte de las alarmas del propio esx ?. "

Bueno... la detección de pantallazos azules es relativamente fácil: Algo deja de funcionar. Bromas aparte, el agente de las VMware Tools te informa periodicamente del "heartbeat" de la VM, tipificando como alarma la pérdida del mismo.

Respecto a los cuelgues.... complicado me lo pones. ¿Qué entendemos por cuelge? ¿Pérdida de respuesta del servidor, de sus servicios?... Evidentemente, la pérdida de respuesta de un servicio no es algo que corresponda a un servicio de infraestructura como resulta ser ESX, sin embargo, con algo de desarrollo usando el SDK de VI, creo que puedes usar el agente de ESX como una especie de cabeza de playa que permita al ESX subyacente el estado de servicios.

Espero haberte sido de ayuda.

Consulta: VI3

Nuestro amigo V. nos pregunta:

"Hola, que tal?
Antes de nada feilicitarte y danrte las gracias por el blog, nos es de gran ayuda a la gente que comenzamos en este mundillo de las virtualizaciones.
Te escribo por si me puedes ayudar con un par de dudas que me surgen:

1. Tengo varios VMWare Server distribuidos por toda la empresa, hay alguna manera de centralizar la administración? Ya que VirtualCenter es de pago.
2. Por otro lado, tengo un ESX 2.1.2 con VirtualCenter 1.1, me sorprende que no tenga opción de crear Snapshots de las máquinas ya que la VMware Server(Free) si que dispone de ella. ¿El hecho de que no disponga de esta funcionalidad tiene que ver con la versión?
3. Nos aconsejas actualizar las versiones? A cuáles? LLevan coste añadido?"
   

Respecto al punto 1. Sí, claro que lo hay. Tú lo has dicho: Virtual Center. La versión para Virtual Server (la 1.4) se comercializa por 1400 US$, gestionando un máximo de 3 VMware Server. Cada VMware Server adicional te cuesta unos 400 US$.

Punto 2: Estás comparando un producto del 2007 con uno del 2004-5. Es obvio que haya grandes diferencias. Creo que dispones de Snapshot desde la versión 2.5. La actualización es gratuíta SI tienes tu contrato de soporte vigente.

Punto 3: Pásate a Virtual Infrastructure. Es posible que puedas actualizar tu ESX 2.1 a un coste competitivo, pero coste, al fin y al cabo. Respecto a la versión (starter, standard o enterprise), dependerá de tu entorno... cuéntame algo más (nº de servidores, almacenamiento) y quizá pueda ayudarte.

Un saludo

Consulta Técnica: Discos en ESX

Raúl nos pregunta:

"Hola JL, soy un recien certificado en VI3 pero con poca practica en proyectos avanzados, se me plantea próximamente una migración de GSX a ESX y me surgen ciertas dudas, te comento a ver si me iluminas...
Partimos de un sistema con tres servidores GSX que albergan unas 5 MV's cada uno. Dos de ellos tienen discos SCSI y uno discos IDE. Todo el almacenamiento que tienen es local.
El sistema resultante tiene que estar formado por los dos servidores con discos SCSI reinstalados con ESX y usando almacenamiento FC de una SAN.

Con el VMWare Converter puedo convertir las MV's (tanto Windows como Linux) e ir migrandolas a la SAN. Mi duda es... una vez tenga las maquinas en la SAN (una LUN que es visible para un servidor intermedio que tenga instalado el Converter) y tenga reinstalados los servidores con ESX, ¿Esa misma lun es válida para que accedan los hosts ESX ? o debo crear otra LUN con vmfs ? En este concepto del almacenamiento y el formato de las LUN's de la SAN es donde me pierdo. "


Gracias de antemano y sigue con tu fantástico blog, que no tiene precio..."


Vamos a ver, que me pierdo un poco con tu pregunta. La LUN de un ESX, formateada con VMFS sólo es accesible para un ESX. Converter solo ghraba directamente el vmdk si el destino es una "stand alone VM", o sea, una VM para Workstation o para Server.

En el caso de VI3, el destino es un Virtual Center o un ESX, con lo que son estos quienes graban el fichero, no el converter.

Espero haberte sido de ayuda.

Consulta Técnica: Netapp & iSCSI

Anónimo me pregunta:

"Primero: Realmente he estado buscando informacion de netapp y VM, y realmente muy interesante.Tengo una consulta: La gente de NetApp jura y perjura que SQL (120Gb) no degrada con iSCSI. Alguna sugerencia? "

Bueno... esto se sale un poco de la dinámica que pretendo darle a este blog, pero como los equipos de Netapp están entre mis caprichos más queridos, he decidido hacer una excepción.

En cualquier caso, os agradecería que dejáseis un correo de respuesta para este tipo de consultas, para poderos responder personalmente.

Vamos a ver. A esa pregunta no puedo responder con un "sí" o un "no", así que me extenderé un poco.

El rendimiento de un SQL no depende exclusivamente del almacenamiento. Dependerá de la plataforma hardware, la configuración del SQL, la aplicación que use la base de datos, y por último, del nivel de mantenimiento del mismo. En otras palabras, si esperas que tu SQL "vuele" por ponerle un Netapp, un EMC o un Hitachi detrás, quizá te lleves una decepción.

Los fanáticos de los IOPS (IO Operations per second) Defienden, y no sin razón, que FC puede dar más rendimiento que cualquier otra tecnología. Por otro, todos sabemos que un host Wintel es incapaz de mantener tasas sostenidas de más de 600 Kb Mb por segundo (sea cual sea el medio).

Otra de las "ventajas" de FC es que la infraestructura es dedicada, y normalmente el integrador/fabricante llega, la instala, configura y listo. Esto, evidentemente tiene un coste que hay que asumir.

iSCSI ofrece un rendimiento (teórico, al menos) de entre un 15 a un 20% menos. Pero no nos confundamos: de un 15 a un 20% menos que el mayor rendimiento posible en un entorno FC. Nuestras bases de datos, exchanges y similares no alcanzan, ni de lejos, el máximo rendimiento de un enlace FC, por lo que, en la mayoría de los casos, la diferencia es inferior al 1% (este 1% suele ir relacionado al overhead que el procesamiento IP supone para los procesadores del servidor en cuestión).

Una de las ventajas claras de iSCSI es, paradójicamente, uno de los motivos por los que iSCSI es despreciado por algunos admins de sistemas: La capacidad de usar la infraestructura IP existente. No es el primer proyecto que veo con problemas porque se ha conectado una flamante SAN iSCSI a un switch Netgear o procurve de gama baja.

Otro aspecto donde iSCSI supera ampliamente a FC es en la simplicidad: Como dice la propaganda, configure usté el IP, instale y configure el Initiator, ofrezca las LUN y a andar. Realmente es así. Una instalación FC es compleja, con múltiples puntos críticos y con una configuración casi de gurú. Las actualizaciones en una SAN FC son laboriosas y arriesgadas, mientras que en iSCSI son bastante simples.

Hay un tercer dato que se tiende a obviar, y que en el caso de Netapp adquiere gran importancia: El hardware de la SAN IP. Mientras IBM, EMC, etc utilizan hardware específico (ASICs, etc), limitado y caro por definición, Netapp se ha volcado en el hardware estandar: PCI-e, Opterons e ingentes cantidades de memoria. Como resulta de esto, Netapp garantiza un path de alta velocidad desde el cabezal del disco hasta la GbitE de salida. De hecho, casi el 40% de las operaciones de IO sobre un Netapp las estás realizando en una memoria caché interna de varios GB, protegida por una batería que garantiza la supervivencia del dato en caso de pérdida de fluído eléctrico.

Otro aspecto que afecta sensiblemente al rendimiento es la reconstrucción de discos en caso de fallo de uno. Las arquitecturas tradicionales basadas en RAID 5 son realmente pesadas a la hora de reconstruir un disco fallado. Las reconstrucciones suelen ser largas, con degradaciones de entre el 10% y el 20% de rendimiento durante la misma. Dado el estado de vulnerabilidad de el RAID durante una reconstrucción (ya que RAID5 no soporta el fallo de dos discos), nos interesa que la ventana de reconstrucción sea lo más limitada posible, lo que supone asignar alta prioridad al proceso de reconstrucción. Recordemos que en RAID 5, la paridad se distribuye entre todos los discos, lo que obliga a leer de todos ellos, compartiendo el IO de estos entre la reconstrucción y el servicio.

Netapp basa su esquema de protección de datos en la especificación RAID4, dedicando un disco para paridad. Esto significa que, en las reconstrucciones, sólo un disco es accedido en lectura para obtener los datos a reconstruir. Por otra parte, refuerzan esta implementación con el uso de un segundo disco como paridad doble, lo que permite el fallo de DOS discos simultáneamente en un mismo RAID. Con esta implementación, que ellos denominan RAID-DP (o RAID 6, a todo hay que ponerle un nombre) las ventanas de reconstrucción (consideradas a menudo ventanas de vulnerabilidad) quedan cubiertas. Hay que tener en cuenta que, los discos de un RAID, si han sido adquiridos al mismo tiempo, comenzarán a fallar más o menos en la misma época. La degradación, tanto en rendimiento como en fiabilidad de los discos, es una realidad.

He tenido la oportunidad de instalar y explotar SQL Servers, Oracles y VMware sobre Network Appliance, incluso en entronos mixtos (FC e iSCSI sobre netapp y iSCSI sobre netapp/FC sobre IBM/EMC) y no hay diferencia de rendimiento puntual. Donde sí la hay, y es a favor de Network Appliance, es en el medio plazo. Mientras con IBM y EMC los tiempos de reconstrucción afectaban al usuario, con Netapp ni se enteraban.

Netapp en españa tiene un equipo técnico muy cualificado, con mucha experiencia y muchas horas de vuelo en lo que a almacenamiento se refiere.

Espero haberte sido de ayuda.

En respuesta a tu pregunta... Créeles. Los equipos son fascinantemente rápidos, simples y, sobre todo, seguros.

Consulta técnica: Activación de Windows tras P2V

Iñaki nos pregunta:

"Buenas tardes José Luis.
Estoy empezando en el tema de las virtualizaciones.
He conseguido que compren un servidor con ESX 3.0.1 para virtualizar todos los servidores en producción que se están quedando desfasados y sin garantía.
El caso es que he virtualizado un Windows 2003 con vm converter, pero al arrancar me indica, lógicamente, que el hardware ha cambiado ostensiblemente, con lo que tengo que volver a activarlo en 3 días.
Creo que hay una solución de agregar una línea al .vmx para que no pida activación.
Serías tan amable de indicármela?
Muchas gracias por tu tiempo y perdona por las molestias.
Iñaki"

Pues hasta donde yo sé, me da que necesitas llamar a Microsoft. Esto no es un problema de VMware (con virtual server te pasará lo mismo), sino del modo de control de la instalación que hace Windows.

Sin embargo, buceando por esos googles de dios me encuentro con que el siguiente parámetro, incluído en el fichero de configuarión de la VM, parece que, a veces, evita la activación.

smBIOS.reflecthost="TRUE"

Un saludo.

Consulta Técnica: Diferencias entre VMware Workstation & Server

Nuestro amigo Linck nos pregunta:

"Hola Jose Luis

Leo atento tu blog sobre Virtualizacion y quisiera que me saques de una duda.

Cual es la diferencia entre VMWare Server y VMWare WorkStation ya que uno es free y el otro pago, he leido las especificaciones tecnicas de cada uno y no logro ver la diferencia.

gracias"

Las diferencias son grandes:

Rendimiento: Con diferencia, VMware Workstation es más rápido que VMware Server
Capacidad: a igual HArdware, VMware server levanta más máquinas que workstation.
Hardware virtual: VMware Workstation soporta hasta 8 Gb de RAM en una VM, 2 procesadores, USB 2.0, display múltiple, estado de la batería y 10 adaptadores ethernet. VMware Server soporta 3.5Gb de RAM, 2 Procesadores y 3 Adaptadores ethernet.
Precio: Vmware Workstation es de pago y VMware server no.

Ejemplo: Com VMware server no virtualizas VMware ESX.

Espero haberte sido de ayuda.

Consulta Técnica: Licenciamiento de VI3

Nuestro amigo Iván nos pregunta:

"llevo tiempo siguiendo tu pagina la cual me encanta, encontrar algo desde lo que basarme para poner a funcionar y tener unas explicaciones desde la experiencia me reaniman. Sobre todo el conocimiento desde nuestra lengua nativa.
Mi pregunta es la siguiente, pues me he encontrado ante esta situacion en el trabajo, tengo 2 servidores con ESX instalado y tienen 4 CPU's cada uno.
Ademas tengo 2 licencias x 2 CPU. la licencia es server-based por lo que tengo instalado el servidor de licencias.
La cuestion es si puedo hacer q un ESX coja la licencia para 2 CPU y el otro ESX coja la licencia para 2 CPU. Con los dos servidores quedarian con 2 CPU con licencia y 2 CPU sin licencia. pues actualmente un servidor coje las 4 licencias y el otro se queda sin ninguna."

Lamento informarte que no puedes. Y aunque pudieses, no funcionaría. Si quieres que ESX te permita arrancar máquinas, TODAS las CPU del host han de estar licenciadas. Así qué, a menos qu eelimines físicamente dos CPU de cada máquina, no podrás activar las dos máquinas.

Un saludo.

Consulta Técnica: Virtualización de DCs.

Nuestro amigo Pedro nos pregunta:

"Hola Jose Luis,

En primer lugar, felicidades por el Blog. Nos resulta de lectura obligada debido a que en mi empresa hemos comenzado un proyecto de consolidación de servidores mediante virtualización y a pesar de haber recibido el obligado curso por parte del proveedor de Vi3, una vez que te metes en harina, empiezan los problemas y no todo es de color de rosa.

Tenemos varios frentes para atacar, pero quisieramos realizarte una consulta especifica sobre el tema que más quebraderos de cabeza nos está dando: la virtualización de domain controllers en W2003. Estamos teniendo diferentes problemas con Domain Controllers Virtualizados, sobre todo en temas de replicación de AD con uno físico e incluso eventos de errores de escritura en disco.

Por otro lado, en diferentes documentos de Microsoft hemos encontrado referencias que invitan a NO virtualizar DCs o a realizarlo con muchas limitaciones (que no sean Catalogo Global, que no tengan ciertos Roles, etc…). Dentro de tu experiencia quisieramos que nos comentases s i son ciertas estas limitaciones, y que criterios habría que seguir tanto en la virtualización como en la configuración de los domain controllers.

Agradeciendo de antemano tu atención y esperando que no sea molestia recibir este correo, recibe un cordial saludo.

Pedro."

Estimado Pedro:

La virtualización es una ciencia exacta, en tanto en cuanto, para lograr el resultado correcto, hemos de tener en cuenta todas las variables. Si enfrentamos la virtualización como un proyecto marginal en el contexto de la infraestructura de la compañía, todo suele ser color de rosa; Muy distinto se vuelve el panorama cuando, como es tu caso, el proyecto pasa por consolidar y virtualizar una infraestructura existente, es donde empiezan los problemas.

Respecto a tu pregunta de ¿Se pueden virtualizar los DC?, mi respuesta, siendo exacto, es: Los míos (entre los propios y ajenos, unos 30) están virtualizados y sin problemas.

Uno de los mayores problemas que presenta la virtualización es que la potencia no viene en cajas. Quiero decir que, cuando compras un servidor físico, sabes de antemano que vas sobrado (en el caso de los DC). Pero los servidores virtuales los diseñamos nosotros, y es ahí donde es posible quedarse corto... o demasiado largo. La respuesta correcta entonces a la pregunta de si se pueden virtualizar los DC (o cualquier otra cosa) es: Depende. Depende de si se ha hecho un estudio de carga de los servidores físicos. Depende de si se pretende hacer un P2V con los DC o no (yo, personalmente, no lo recomiendo), Depende de la infraestructura virtual (Los host, el almacenamiento), depende de la configuración de VI3.

En resumen: Depende de si el consultor que te lleva el proyecto sabe de lo que habla, o simplemente ha hecho el curso de VCP y listo.

Sé que no te he sido de demasiada ayuda, pero desde estas páginas sólo puedo aconsejaros prudencia.

PD: Eso del error de acceso a disco suena muy raro... cuéntame qué configuración hardware tienes en VI3 (Servidores, HBA, Almacenamiento, etc)

Consulta Técnica: Copias de seguridad de vmdk's

Nuestro amigo Alberto Donat nos pregunta en relación con el post Nota Técnica: Usando Windows Server como servidor NFS para ESX:

"Genial, me ha servidor de mucha ayuda este post.Solo una pregunta, utilizo esta unidad NFS para sacar backups de las MV a otro servidor. ¿ Alguna otra forma de hacerlo más rápido ?Muchas gracias.Fdo: Un incondicional de tu blog "

Bueno. En lo referente a las copias de seguridad de las VM hay mucho que hablar, de hecho tengo algo a medio escribir sobre el tema. Respecto a lo que me planteas, entiendo que usas una estrategia tradicional de respaldo con los ficheros vmdk y las configuraciones, y lamento decirte que, bajo ese enfoque tradicional, el fichero de una VM que ocupa 8 Gb sigue siendo un fichero de 8 Gb, con exactamente los mismos problemas de tiempo de copia que cualquier otro. Si en vez de utilizar NFS utilizaces iSCSI o FC, la copia te iría bastante mejor, pero aún así seguiría tardando.

La virtualización requiere de un nuevo enfoque en lo referente al respaldo, y debemos tener en cuenta este handicap a la hora de diseñar nuestro entorno. Tan pronto tenga un rato, terminaré ese post que os comenté sobre el tema del respaldo de VM's

Consulta Técnica: Seguridad en entornos VMware Server

Nuestro amigo Herman nos pregunta:

"Una consulta que no tiene que ver con Viridian sino con VmWare Server, si quiero virtualizar unos servidores que estan en la DMZ cual sería el metodo mas seguro, una NIC que apunte a la LAN y la otra a la DMZ?, o todo configurado (host y guests) en la DMZ?Muy bueno el blog.Herman"

Bueno, la pregunta, o al menos el transfondo, no es exclusivo de la Virtualización. Por definición, cualquier cosa que pongas en una DMZ debería mantener un nivel de exposición muy bajo, limitando la visibilidad a lo justo y necesario. En tu montaje en particular, aunque no nos dices si vas a utilizar Windows o Linux en el host, yo me limitaría a lo siguiente:

Distribución de interfaces: 1 o varias para las VM y una exclusiva para gestión
Interface de Gestión: En red de gestión, aislada de todas las demás
Interface(s) para VMs: En el caso de Windows, desactivar el Cliente para redes Microsoft, el Compartir impresoras y archivos para redes microsoft, y si te deja (reconozco que no lo he probado), el TCP/IP.

Se admiten más opiniones. Espero haberte sido de ayuda