Uncategorized

Es probable que al intentar virtualizar un Windows 2000 con VMWARE Converter, aparezca la petición de un archvio llamado SCSIPORT.SYS, donde Converter nos pide la ruta para encontrar ese archivo.
Bueno, esto no es difícil de resolver:
Windows 2000 Server requiere para poder ser virtualizado el SP4 Rollup 1.
Por lo general, quienes tienen Windows 2000 Server en Producción con su SP4, suponen que ya están totalmente cubiertos.  Pero existe el Rollup 1, que salió posteriormente al SP4, quien tiene actualizados algunos drivers, por ejemplo el mencionado SCSIPORT.SYS.

Una vez instalado el Rollup 1, el servidor físico necesita ser reiniciado para poder convertirlo.
Les dejo acá el link de Ms para bajar el Rollup 1.
http://www.microsoft.com/downloads/details.aspx?FamilyId=B54730CF-8850-4531-B52B-BF28B324C662&displaylang=en

Éxitos con la Virtualización!
Saludos…
Patricio Limeres

Para no responder sin conocimientos mi respuesta siempre fue consultá en la guía "Getting Started with ESXi Installable" para saber los requerimientos mínimos de hardware que se necesitan para correrlo. El punto siguiente fue que cuando quise hacer una prueba y tuve que verificar la lista de requerimietnos mínimos me encontré con una sorpresa… la cantidad mínima de memoria para correr solamente el sistema operativo era de 2GB de RAM (2048 MB). Ante esta información decidí comprobar si realmente era o no real la cantidad de memoria solicitada por la guía y comencé la instalación:

Luego de seleccionar la opción "ESXi Installer" y de algunos minutos para la descompresión de la imágen… la siguiente pantalla:

Evidentemente la guía estaba en lo correcto y a partir de las siguientes versiones de los productos enterprise de VMware no tendremos más opción que contar con equipos de gran porte… incluso para laboratorios.

Para los que se siguen preguntando cuales son los requerimientos mínimos de hardware para correr VMware ESX4i el contenido de la guía (al momento de escribir este post) es el siguiente:

Procesadores:

• Todos los AMD Opterons support 64 bit.
• Todos los Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 7100/7300, y 7200/7400.
• Todos los Intel Nehalem con soporte para 64 bits.

Memoria:

• 2GB mínimo.

Red:

• Una o más placas 10 GBe. Para el listado completo de placas soportadas verificlar la Hardware Compatibility Guide

• Basic SCSI controllers – Adaptec Ultra-160 or Ultra-320, LSI Logic Fusion-MPT, o NCR/Symbios SCSI.
• RAID controllers – Dell PERC (Adaptec RAID or LSI MegaRAID) o IBM (Adaptec) ServeRAID.

Para obtener el listado completo de controladoras SATA soportadas consulen la guía Getting Started with ESXi Installable (página 6).

Espero que les sirva!

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

VMware ESX server es un producto complejo que combina una consola basada en Linux (Red Hat) y la posibilidad de correr máquinas virtuales y sus múltiples sistemas operativos en un único servidor. Existen varias formas de realizar la administración de VMware ESX Server dependiendo de necesidades, gustos y presupuesto. Cualquiera que sean los motivos este articulo presenta las diferentes formas de realizar la administración de este producto.

1. Acceso por consola por medio del Service Console Como cualquier otro sistema operativo basado en Linux podemos acceder y realizar la administración por medio de una línea de comandos. Para poder trabajar sobre esta consola se requieren conocimientos de Linux y tiempo para aprender los comandos de administración de VMware ESX Server. Las desventajas de administrar VMware ESX de esta forma son: 1) se debe estar presente en la consola del equipo (o utilizar algún dispositivo de acceso remoto como las placas ilo de HP o Drac de Dell) y 2) se deben poseer conocimientos de Linux para realizar la mayoría de las tareas.

2. Acceso a la consola por SSH Se puede establecer una conexión al service console de un servidor VMware ESX por medio del protocolo SSH y trabajar de la misma forma como si estuviera en la consola del servidor. Para utilizar. Este método el servidor VMware ESX deberá estar conectado a la red y tener un cliente ssh instalado en la pc desde la cual se desea acceder al servidor.

3. Acceso al servidor VMware ESX por medio del VMware Virtual Infrastructure (VI) Web Access La forma más simple de acceder a una interface de administración gráfica de un servidor VMware ESX es utilizando la VMware Virtual Infrastructure (VI) Web Access interface. Esta interface se instala por defecto y para accederla lo único que se necesita es una pc conectada a la red y un navegador de internet. Acceder a la interface es tan simple como abrir un navegador y tipear la dirección IP del servidor. Lo que se obtendrá es una pantalla de bienvenida mostrando opciones de administración. El beneficio de utilizar esta interface es la posibilidad de acceder a una interface de operación básica (no todas las funciones de administración están disponibles) de un servidor VMware ESX sin la necesidad de instalar un cliente local en el equipo que se utilizará para realizar la administración.

4. Acceso a un servidor VMware ESX por medio de VMware Virtual Infrastructure Client (VI Client) Esta es sin lugar a dudas la mejor forma de administrar remotamente un servidor VMware ESX. El VMware VI Client es un software que se instala en la pc de administración remota y para obtenerlo se puede descargar directamente desde la web gui. Los beneficios de utilizar este cliente son básicamente la posibilidad de acceder de forma completa a todas la funciones de VMware ESX desde un único punto de administración. El único punto en contra es el requerimiento de instalación del VI Client para realizar la administración.

5. Acceso por medio de VMware Virtual Infrastructure Client (VI Client) y VMware Virtual Center El mismo cliente (VI Client) puede ser utilizado para administrar un único servidor como también para administra la infraestructura de VMware completa. En lugar de apuntar el cliente al servidor VMware ESX que queremos administrar todo lo que tenemos que hacer es tipear la dirección IP o el nombre de nuestro servidor VMware Virtual Center. Asumimos aquí que ya tiene un servidor VMware Virtual Center y que además cuenta con un usuario y contraseña para realizar la administración. Desde el VMware Virtual Center podrá administrar todos los servidores VMware ESX server, Storage y redes virtuales que se encuentran configuradas en su infraestructura virtual. VMware Virtual Center es un producto adicional a VMware ESX Server y requiere licencias adicionales.

Saludos,

 Nicolas Solop

Únete al grupo de virtualización en español en LinkedIn

Desde hace algunos años los proyectos de consolidación de servidores fueron ocupando lugares importantes en la mayoría de las organizaciones. Este tipo de proyecto generalmente tiene alguno de los siguientes objetivos: * Reemplazar hardware obsoleto con equipamiento nuevo * Mejorar la utilización de todo el centro de cómputos * Disminuir el costo total relacionado con la adquisición de nuevos equipos Considerando que los servidores multicore modernos cumplen con su carga de trabajo utilizando menos energía eléctrica que sus antiguos hermanos y que cada vez la idea de virtualizar viejos equipos en máquinas virtuales está cada vez más arraigada en los planes de las organizaciones los resultados se vuelven evidentes. Una carga de trabajo que podría haber demandado en el pasado unos 20 ó 30 servidores puede ser ejecutada de la misma manera (a veces con mejorías) utilizando únicamente 1 o 2 servidores en la mayoría de los casos. Con la cantidad de opciones disponibles de Hypervisor el día de hoy, algunas de estas de utilización libre, la virtualización es la manera más siempre de lograr los objetivos de consolidación de servidores. En muchos casos incluso el reemplazo de servidores uno-a-uno de hardware viejo por nuevo puede reducir el consumo de energía. Sin embargo, combinando la carga de trabajo de varios servidores en un único servidor se puede obtener ahorros de consumo de energía eléctrica mucho más importantes. El ahorro de energía solamente es un buen motivo para abordar proyectos de consolidación de servidores pero seguramente no sea el único. Por ejemplo la adecuación del centro de cómputos y específicamente la refrigeración del mismo es otro punto importante para analizar. ¿Es más económico refrigerar 30 servidores viejos e ineficientes ó dos nuevos servidores y una red SAN? A menos que la red SAN ocupe por completo el centro de cómputos apuesto que las necesidades de energía para refrigeración también se verán reducidas. Los proyectos de consolidación no tienen porqué terminar dentro del centro de cómputos. Tomemos por ejemplo la virtualización de puestos de trabajo. Distribuyendo dentro de la organización equipos terminales de bajo consumo eléctrico y sumando la utilización de algunos servidores de utilización eficiente de energía en el centro de cómputos las organizaciones podrán alcanzar los mismos objetivos "Verdes" en los escritorios de los usuarios. Para resumir este concepto, el costo total de propiedad para los puestos de trabajo se ve reducido lo cuál incluye ahorros de energía significantes. Supongamos que distribuimos dentro de la organización 200 clientes delgados para reemplazar 200 PCs. Supongamos también que para soportar esta carga de trabajo necesitaremos 5 servidores. Haciendo las cuentas nos encontraremos con que el consumo de energía de los 200 thin clients y los 5 servidores es mucho, mucho menor que el de 200 PCs normales. Los proyectos de consolidación son cada vez más comunes.

Si su organización u empresa todavía no comenzó a analizar este tipo de soluciones el momento de comenzar es ahora, ya mismo. Nicolas Solop

Únete al grupo de virtualización en español en LinkedIn

1. Servidores con diferentes versiones de VMware conformando una misma granja.
2. Dimensionamiento de los dispositivos de almacenamiento en el “aire” sin medir requerimiento y performance requeridos.
3. Servidores de VMware con años de producción sin actualizaciones y parches aplicados.
4. Implementaciones si una hoja completa de documentación sobre la arquitectura.
5. Planes de contingencia y backup en producción pero nunca probados.

Si bien ninguna de las dos listas contempla de forma completa los problemas que existen en las infraestructuras virtuales ni tampoco todas las formas de trabajar proactivamente para conformar una plataforma de VMware “saludable” son un buen punto de partida previo a  la realización de un estudio del tipo VMware health check el cual brinda desde el punto de vista tecnológico una visión general de la plataforma y los puntos de la misma que deben ser atendidos.

Siempre hablamos de los beneficios de virtualizar, de las características, de lo nuevo, de lo mejor, pero en el caso de hoy voy a tratar algo distinto, ¿donde están los verdaderos temores de aquellos que aún no han adoptado la virtualización?, luego de más de 7 años virtualizando, les paso una descripción de donde están centrados los principales temores de los CIOs.

Performance

El primer interrogante que tienen está directamente relacionado con el rendimiento o la performance de sus aplicaciones.

Siempre surge el mismo desafío cuando se hace participar al área de desarrollo, porque los mismos entienden que bajo ese concepto, sus servidores perderán potencia a comparación de sus anteriores pares físicos y por consiguiente todas sus pruebas de desarrollo se verán altamente perjudicadas. Ni hablar de la oposición rotunda por “default” que tienen los DBA (en especial los que tienen su preferencia por oracle).

Para responder a los miedos sobre performance voy a dividir el tema en tres partes básicas; cpu, memoria y disco.

• Cpu,

El manejo de la cpu se realiza bajo un componente llamado “scheduler” el cual se encarga de realizar la asignación de cada core en un intervalo aproximado de 20 msg. Si uno toma datos de performance sobre los sistemas actuales, el promedio no supera el 15 % de uso de cpu.

Otro dato no menor, es que las aplicaciones están mal desarrolladas, si, lamento ser algo crudo con los desarrolladores (van a pensar que tengo algo personal con ellos), pero la realidad es que ninguna hace uso eficiente de los múltiples threads, es decir los varios cores de un sistema.

Si consideramos esta aclaración veremos que las compañías están comprando mayor cantidad de procesamiento (ej: quad core ) solo para gastar más plata en adquisición de cpus y el resumen de la cuenta de luz.

No recomiendo para nada que los jefes de infraestructura confronten con los jefes de desarrollo sobre el porque no se desarrolla en múltiples hilos, dado que seguramente lleve a ambos al caos o incuso no sea un problema propio de desarrollo sinó de la tecnología que soporta dicha aplicación (llamese sistema operativo base, aplication server, etc); pero desde luego,  10 años y 7 virtualizando me han demostrado eso, los multicore no se están usan para nada.

Ahora bien, si hay casos donde las aplicaciones lo usaran, por medio de SMP (tecnología para presentar múltiples procesadores virtuales a una maquina virtual) se podrían tranquilamente crear hasta cuatro virtual cpus para cada maquina virtual y resolver tranquilamente el tema.

• Memoria,

La memoria  se optimiza perfectamente,  muchos de  los usuarios de VMware ven que sus sistemas bootean mas rápido o que incluso sus aplicaciones funcionan mejor. Hay una relación directa entre la memoria y la maquina virtual, es decir conviene tener sistemas con mucha memoria y cpus para almacenar mayor cantidad de maquinas virtuales, y luego asignar a estas la memoria que quiero (no voy a discutir el tema de shares, limits y reservations), pero si quiero explicar que es el TPS (transparent page sharing).

El TPS tiene por definición el eliminar las páginas de memoria redundantes, generalmente estas páginas son datos en memoria llevados en modo read only o código . Cuando una página es identificada como existente en la memoria del esx, dicha pagina es referenciada en el bloque de memoria que le corresponde a la VM, y en definitiva solo se hace el mapeo. Si ustedes usaran maquinas virtuales estandarizadas con el mismo nivel de service pack o kernel, podrán imaginarse lo que ahorrarán en memoria, es por ese motivo que pueden llegar a poner más de 32 maquinas virtuales en un equipo con 16 gigas de memoria y funcionar perfectamente.

Ahora si una de esas páginas debiera modificarse, el hypervisor notara la diferencia y generará una nueva página y la guardará en su propio espacio en memoria, la técnica suena simple pero es avanzada y el principal driver es el uso de una tabla de hash para cada frame de memoria.

El concepto es claro, ahorro de memoria en base a no realizar sobreescrituras superfluas.

Además de ese método, está el método de memory balloning conocido gracias al proceso vmmemctrl que se ejecutara en las maquinas virtuales (incluido dentro de las VMware tools). Simple, si el esx no tiene más memoria se enviará lo que se necesite al storage para paginar utilizando métodos de locación y reclamación para manejarla.

Igualmente para aquellos que quieran conocer más en detalle en breve voy a realizar un post con el manejo detallado de la memoria ram en VMware ESX.

• Disco,

Cuando hablamos de Virtualización, en la mayorías de los casos hablamos de usar subsistemas de disco (storage), ya sea por ISCI o Fibre Channel. Principalemte si uno agrega más ejes al enclosure, mayor performance este le ofrecerá, segundo, se debe hacer mucho hincapié en cómo se configuran las LUNS y la c la forma de trabajar de las controladoras, por ejemplo NetAPP tiene un manejo de memoria   distinto al resto de los players, lo que significa que para el uso convencional del array, EMC, IBM, NETAPP o HITACHI serán casi iguales, pero a la hora de reconstruir arreglos formados, por ejemplo, sobre raid 5, la reconstrucción cuanta mayor memoria tenga la controladora, más rápido se hará y menos se sentirá.

Generalmente los problemas de IO no son los que fueran a tener, si tienen problemas, seguramente sean de SCSI Reservations por una mala configuración de las LUNS y una mala distribución de las VMs y los ESX.

Seguridad,

La seguridad dentro de un ambiente virtual basado en VMware (es el que más conozco),  radica en tenér adecuadamente configurada la service console (su interfaz de administración) basado en un “muy recortado” kernel de Linux red hat. Es decir que no tiene código sobrante que genere vulnerabilidades, pero que las tiene, las tiene como cualquier soft.  Ahora, si uno implementa un correcto protocolo de segurización de la Service Console, les puedo asegurar que las probabilidades de que alguien gane acceso a un ESX segurizado son casi nulas, distinto es ver lo que se ve diariamente donde el 90% de las instalaciones realizadas están por default.

Desde el lado de las maquinas virtuales  entre sí no saben ni que existen, son archivos encapsulados, y en memoria son instancias separadas o compartidas según si es la misma pagina o no. Ninguna VM puede explotar una vulnerabilidad de  la service console porque cada VM trabaja en su propio espacio de memoria. Conclusión, el ESX y las maquinas VMs son dos mundos separados.

Disponibilidad, único punto de fallas,

Otro cuestionamiento que surge es el único punto de fallas, si cae un ESX con 10 VMs  se caen 10 servidores, en cambio si se cae un solo servidor físico cae ese solo. Previamente antes de implementar la solución de virtualización se deberán hacer exigentes test de stress para verificar que el equipamiento no traiga defectos. Los test se recomiendan correrlos por tiempos no menores a 3 días.

Si consideramos tener un storage de disco y al menos dos ESX server para trabajar en cluster, la caída de un ESX implicará ver una reiniciada forzosa de las 10 VMs y se bootearán en el otro ESX por medio de HA. Todo puede llegar a demorar como máximo 5 minutos. Mi pregunta es, cuanto demorará HP, IBM o DELL en traer los módulos necesarios para reponer la parte dañada de eses único equipo?, mientras uno sufre por un Exchange caído dos  o más horas, yo prefiero tener un pequeño booteo y seguir operando como si nada hubiera sucedido. Algo para recordar es que el uptime de los esx está llegando a ser comparado con los de mainframe.  

Lo importante en este caso es comprender que siempre pueden ocurrir fallas, lo importante es ver como uno se prepara para soportarlas.  De que sirve gastar miles de dólares para que un equipo funcione y si este falla se debe tener que esperar a que el técnico traiga las partes. Para eso conviene virtualizar, aprovechar bien la inversión en dos o tres ESX bien distribuidos con un storage redundante, si algo pasara a un de ellos, no me preocuparía dado que las maquinas virtuales se iniciaran en los otros activos.

Ojo, durante el 2009 se lanzará VMware Fault Tolerance (lo cual les permitirá tener 100% alta disponibilidad (activo-activo).

Conclusión

Comprender que la Virtualización es una tecnología para evitar que nuestros servicios dependan de un hardware específico y realmente el hardware se enfoque a satisfacer necesidades de negocio va  a ser la clave para ver en la Virtualización más que beneficios económicos. Hablamos de transformar al departamento de IT en uno más versátil y dinámico para finalmente convertir nuestro datacenter en una ventaja competitiva real.

Ing. Diego Quintana

VCP-VAC-VTSP

Hace algunos años ya, cuando trabajaba como admin de plataforma, una de las cosas que más me perturbaba era el poder balancear mi vida personal con la privada durante las semanas en que estaba cumpliendo guardia pasiva. No había cosa que me perturbara más que escuchar ese teléfono celular sonar y pensar que me estaban por avisar que había un servidor que no respondía, o que los recursos de hardware estaban siendo consumidos y que tenía que dejar de hacer lo que estaba haciendo (cine, cena, almuerzo, deporte, etc.) de forma automática para conectarme por VPN a la oficina para resolver el incidente que fuese. Muchas personas en la actualidad pasan por lo mismo pero, si usan VMware como plataforma, esos días se terminarán ya que VMware estará lanzando a modo de evaluación durante abril de 2009 VMware vCenter Mobile Access (vCMA). vCMA permite monitorear y administrar VMware Infrastructure desde un teléfono inteligente (smart phone) con una interface optimizada para estos dispositivos. Las funcionalidades básicas que permite vCMA son: • Buscar máquinas virtuales dentro del inventario del datacenter. • Migrar máquinas virtuales de un host a otro utilizando vMotion. • Lanzar planes de recuperación de desastre desde VMware Site Recovery Manager. • Acceder a tareas programadas, alarmas y eventos. • Muchas cosas más… Uno de los requerimientos para ejecutar vCMA es el de implementar un virtual appliance que deberá estar conectado al VMware Virtual Center oun servidor VMware ESX que queramos administrar. Una vez configurados los componentes se podrá administrar la infraestructura desde un smart phone. Según la información que aparece en el sitio web del VMware vCenter Mobile Access Technology Preview la solución fue probada en las siguientes tecnologías:

• BlackBerry

• Iphone

• Symbian/Nokia

• WinMo

• Android

Esperemos un poco más para que lo liberen en forma definitiva.

Saludos!

Nicolas Solop

Únete al grupo de virtualización en español en LinkedIn