Mostrando entradas con la etiqueta Nota Técnica. Mostrar todas las entradas
Mostrando entradas con la etiqueta Nota Técnica. Mostrar todas las entradas

martes, 16 de agosto de 2011

Nota técnica: Autoconfiguración de Máquinas virtuales.

Las capacidades de cloning de vSphere no son un secreto. La posibilidad de desplegar una nueva máquina virtual desde otra definida como plantilla, con las opciones de personalización definidas previamente como "Customization Specification" suponen un gran ahorro de tiempo y de nivel deautomatización de despliege.

Una "Customization Specification" no es más que un fichero de respuestas sysprep "inyectado" en la VM destino para que está se configure de determinada manera, en especial en lo relacionado al nombre, pertenencia al dominio o configuración IP.

Sin embargo, sysprep puede dejarnos el trabajo a medias. Me explico.

Si nuestra VM origen tiene, por ejemplo, varios discos duros con unas asignaciones de letras determinadas, estas desaparecerán con el sysprep, siendo sustituidas por las asignaciones por defecto. Si hemos modificado cosas como el swap, (tamaño o localización), también estas configuraciónes se revertirán a sus valores por defecto.

Evidentemente no es nada que no pueda ser solucionado con powershell, GPOs o con intervención manual. Sin embargo, hay entornos donde modificar las GPO no depende de nosotros, o powershell no puede ser usado por normativa interna. El caso que nos ocupa es el siguiente:

Por definición los servidores del entorno que nos ocupa deben tener la siguiente configuración de disco:
  • C: Arranque
  • D: Datos
  • S: swap
  • T: Temporales de sistema y usuarios.

Además, el archivo de swap debe tener un tamaño fijo de 1.5 veces la RAM del sistema.

Por otro lado, el escritorio de la VM debe estar organizado de la siguiente manera:
Icono "Computer": Debe tener como etiqueta el nombre del sistema
Fondo de pantalla: Con BGInfo. debe actualizarse cada vez que se loguea un usuario.

En este caso, en el que el cliente usa McAfee ePO, eliminamos el GUID del agente para que pueda registrarse correctamente en la consola. Así mismo, deshabilitamos el firewall en el perfil de Dominio.

Por requerimientos de la instalación, no podemos usar ni GPOs ni powershell.
Vaya, todo un problema. Por suerte podemos echar mano de las herramientas de línea de comando de Windows 2008R2 (insuperables) y de nuestros maravillosos archivos .bat (o .cmd)

¿Qué hicimos?

Respecto a la máquina virtual, decidimos equiparla con dos controladoras SCSI, una de ellas LSILOGIC y la otra Paravirtual, para aprovechar las ventajas del driver sintético de disco, quedando el disco de arranque en la primera, y el resto de los discos en la segunda. Así mismo, definimos el disco dedicado a temporales como no persistente, lo que nos permite, por una parte, limpiar nuestro servidor cada vez que lo apaguemos, y por otra, evitar que el disco de temporales crezca en exceso quitándonos las ventajas del thin provisioning (recordad que el espacio borrado no se recupera de manera automática)

En primer lugar, crear una customization specification con las siguientes características:



Destaco en rojo los dos parámetros necesarios para el caso que os propongo: El autologin count, que nos permitirá que el usuario administrador de loguee automáticamente tras acabar el despliegue UNA SOLA VEZ, y el GUI run once command, que nos permitirá que en ese login se ejecute nuestro script. Sobra decir que este debe estar previamente en la VM plantilla.

Código, código...

Aquí va el código del script.


:vars
set tdrive=t
set sdrive=s
@echo off
:start
if a%1 == a/install goto install
@echo Personalizando
:mktemp
@if not exist %tdrive%:\temp.usr\%username% mkdir %tdrive%:\temp.usr\%username%
@reg add HKCU\environment /v TMP /t REG_EXPAND_SZ /d "%tdrive%:\temp.usr\%username%" /f > nul
@reg add HKCU\environment /v TEMP /t REG_EXPAND_SZ /d "%tdrive%:\temp.usr\%username%" /f > nul
set temp=%tdrive%:\temp.usr\%username%
set tmp=%tdrive%:\temp.usr\%username%
:MyPcIcon
@reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D} /ve /t REG_SZ /d %computername% /f > nul
@reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\HideDesktopIcons\NewStartPanel /t REG_DWORD /v {20D04FE0-3AEA-1069-A2D8-08002B30309D} /d 0 /f > nul
:Background
c:\tools\bginfo /timer:0 /nolicprompt c:\tools\omt.bgi
goto end
:install
:fwdomdisable
@echo Desactivar firewall en dominio
@netsh advfirewall set domainprofile state off
:tempdrive
@echo Configurando disco temporal y de swap a %tdrive%:\
wmic computersystem where name="%computername%" set AutomaticManagedPageFile=False
@if exist %sdrive%:\pagefile.sys wmic pagefileset where name="%sdrive%:\\pagefile.sys" delete > nul

@echo select volume 5 > c:\tools\swapdrive.dsk
@echo assign letter %sdrive% >> c:\tools\swapdrive.dsk
@diskpart /s c:\tools\swapdrive.dsk > nul

@echo select volume 3 > c:\tools\tempdrive.dsk
@echo assign letter %tdrive% >> c:\tools\tempdrive.dsk
@diskpart /s c:\tools\tempdrive.dsk > nul

@echo Setting Configurando variables TEMP y TMP del sistema
@reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TEMP /t REG_SZ /d "%tdrive%:\temp.sys" /f > nul
@reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TMP /t REG_SZ /d "%tdrive%:\temp.sys" /f > nul
:swapfile
@echo setting System swap
@for /f "tokens=*" %%a in ('wmic computersystem get TotalPhysicalMemory^ /Value ^| find "="') do (set var.%%a)
@set vargb1=%var.TotalPhysicalMemory:~0,-7%
@set /a vargb2=%vargb1%/1024
@set /a swapsize=%vargb2%*1024
@set /a swapsize=%swapsize%+(%swapsize%/2)
@echo Configurando swap a %swapsize% MB
@wmic computersystem where name="%computername%" set AutomaticManagedPageFile=False > nul
@wmic pagefileset create name="%sdrive%:\pagefile.sys"
@wmic pagefileset where name="%sdrive%:\\pagefile.sys" set InitialSize=%swapsize%,MaximumSize=%swapsize% > nul
@if exist c:\pagefile.sys wmic pagefileset where name="c:\\pagefile.sys" delete > nul
:McAfee
@echo detecting MCAfee Products
@reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent" /v AgentGUID > nul
if errorlevel 1 goto reboot
if errorlevel 0 goto deleteGUID
:deleteGUID
@echo Detectado ePO¡¡ - Borrando GUID
@reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent" /v AgentGUID > nul
:REBOOT
shutdown /r /t 0
:end

El script contiene dos secciones, que se invocarán dependiendo del parámetro que le pasemos al invocarlo.

Si no le pasamos ninguno, el script se limitará a verificar que los directorios temporales del usuario existen y a configurar las variables de entorno del sistema (Sí, sé que en lugar de set podía haber utilizado xset) Así mismo, renombra el icono "Computer" y se asegura de que éste se muestre en el escritorio.

La segunda parte sólo se ejectuta si el script es invocado con el parámetro "/install".

Etiqueta :vars

Aquí definimos las variables que vamos a utilizar: %sdrive% para la letra del disco de swap y %tdrive% para las letras del disco temp

Etiqueta :fwdomdisable

En esta parte, desactivamos el firewall en el perfíl "Dominio" mediante netsh advfirewall

Etiqueta :tempdrive

Esta etiqueta elimina el pagefile existente (nos libera espacio del disco C). Para ello, dejamos al sistema temporalmente sin swap y procedemos a borrar el pagefile.sys que, por defecto, tendrá la máquina en C:

En esta fase, aprovechamos para "reordenar" los discos según especificaciones, con los valores especificados en %tdrive y %sdrive. Para ello, echaremos mano de diskpart y su capacidad de recibir órdenes desde un fichero (parámetro /s). Este fichero lo hemos creado "on the fly". Los números de volumen (3 y 5) dependerán de cada sistema. En el que nos ocupa, los discos creados para temp y swap ocupaban el 3 y el 5 respectivamente). Una vez asignadas las letras correspondientes, modificamos las variables TMP y TEMP del sistema.

Etiqueta :swapfile

Ahora a lo gordo... esta parte del script creamos el nuevo archivo de swap. Para ello, utilizamos el comando wmic (que nos dá acceso a la instrumentación de windows desde línea de comando) y las capacidades "aritméticas" del CMD de Windows.

Etiqueta :McAfee

Aquí detectamos si existe la entrada de registro del ePO de McAfee. Si existe (lo detectamos con errorlevel) saltamos a la etiqueta :deleteGUID que la borrará, forzando al agente a generar una nueva.

Etiqueta :REBOOT
Forzamos un reboot del sistema

Etiqueta :end
¡Esto es todo, amigos!

Resumen.

Este script es sólo un esqueleto, y pueden añadirse más funciones (instalación de software, por ejemplo o de roles del servidor) de forma que una vez desplegada nuestra nueva VM la tarea manual sea la mínima posible.

Esto es todo por ahora.... ¡¡ Buena semana!!

lunes, 26 de octubre de 2009

Nota Técnica: VMware View Open Client

Como supongo que sabéis, VMware ha "liberado" hace ya un tiempo el cliente View (o VDM) para Linux, lo que permite tanto a los forofos y/o usuarios de este sistema operativo como a los fabricantes de Thin Clients acceder a los entornos View desde este sistema operativo.

Entrecomillo "liberar" ya que el cliente en cuestión tiene ciertas peculiaridades, que destaco:
  • No soporta redirección USB. En la distribución estándar del cliente "faltan" los componentes de la redirección de dispositivos USB, que entiendo que requerirán de licencia OEM al efecto.
  • Es pelín exclusivo: No tenemos control sobre la ventana del desktop virtual, ya sea para cambiar el tamaño o alternarla con el deskop físico.
  • Presenta algunos "problemillas" con el teclado: Tiene como buena "costumbre" obligarnos a usar el teclado US en lugar del que tengamos configurado.
Dado que de último uso Ubuntu en mi flamante Sony Vaio VGN-P11z (el vista que trae de serie hace desesperadamente lento al cacharro en cuestión, y Windows 7 no mejoró mucho las expectativas de rendimiento me decidí a "Ubuntear" el portátil, ya que todo mi entorno de trabajo se encuentra en el desktop virtual) el uso del cliente View se volvió necesario, así que me decidí a intentar superar las limitaciones antes expuestas, al menos las concernientes al desktop.

El VMware View Open Client, al igual que su contrapartida en Windows, requiere de un cliente de terminal server previamente instalado en el equipo, en el caso de Linux, rdesktop, así que me dediqué a investigar cómo el cliente View interacciona con rdesktop. Para ello, procedí a realizar lo siguiente:

1. Renombré el binario de rdesktop, localizado en /usr/bin/rdesktop a /usr/bin/rdesktop.bin:

# mv /usr/bin/rdesktop /usr/bin/rdesktop.bin

2. Creé un archivo /usr/bin/rdesktop.wrapper con el siguiente contenido:

#!/bin/bash
echo $* > $HOME/rdesktop.parms
/usr/bin/rdesktop.bin $*

en $* el shell nos suministrará la línea de comandos que View Client le pasa a rdesktop

3. Hice un link simbólico entre el archivo rdesktop.wrapper y rdesktop:

# ln -s /usr/bin/rdesktop.wrapper /usr/bin/rdesktop

Tras lo cual, ejecuté el cliente de vmware view (vmware-view).

Tras conectarme, procedí a examinar el contenido del fichero $HOME/rdesktop.parms, encontrando lo siguiente:

-z -K -g 1280x1024 -X 65012445 -u jlmedina -d bato-its -p - -a 24 -r sound:local :3389 10.0.10.18

Si consultamos las opciones de rdesktop (via man rdesktop) observamos lo siguiente:

-z: Activar compresión RDP

-K: No anular las asignaciones de teclas del Window Manager. Por defecto (es decir, sin esta opción activada) rdesktop intercepta todas las pulsaciones. Esta opción es la que nos impide minimizar la ventana del virtual desktop mediante la pulsación de ctrl+alt+enter

-g: Resolución de la ventana de virtual desktop. Por defecto, VDM ocupa toda la pantalla disponible.

-X: Ejecuta rdesktop dentro de una ventana existente. El comportamiento por defecto de VDM es ejecutar la ventana de rdesktop sobre una ventana invisible que no es minimizable.

-u : Usuario con el que conectarse

-d: Dominio al que pertenece el usuario

-p: password suministrada al cliente VDM

-a: Profundidad de color. Por defecto, VDM utiliza el máximo soportado por VDM, que es 24 bits.

-r: Dispositivos redirigidos. Por defecto, sólo el sonido

el resto corresponde a la IP y puerto del desktop a conectarse.

Por lo pronto, las opciones que parecen "molestarnos", es decir, la de no poder salir de la ventana del Virtual Desktop, son las siguientes:

-K, es decir, la que nos desactiva el ctrl+alt+enter

-X, que ejecuta el rdesktop en una ventana no "resizable".

Si nos limitamos a eliminar estas dos opciones, nos encontraremos con los siguientes "problemillas":

  • El teclado seguirá estando en inglés EEUU
  • El virtual desktop se presentará por defecto en modo ventana

Para solucionarlo, deberíamos pasar a rdesktop los siguientes parámetros:

-f: Activa el modo full sreen
-k es: configura el teclado por defecto a español.

Ahora bien... ¿Cómo eliminar opciones y añadirlas a los parámetros que el cliente view pasa a rdesktop?

Como antes dijimos, la variable $* almacena los parámetros que vmware-view pasa a rdesktop, así que aprovecharemos esto para eliminar los parámetros que nos molestan y añadir los que nos faltan. Para ello, volvamos a mi fichero rdesktop.wrapper:

#!/bin/bash
echo $* > $HOME/rdesktop.parms
/usr/bin/rdesktop.bin $*

lo modificaremos para que quede como sigue:

#!/bin/sh
parms=`echo $* awk '{print $1,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17}'`
/usr/bin/rdesktop.bin -k es -f $parms

Básicamente lo que he hecho es, mediante el comando awk, eliminar de la línea de parámetros los que me molestan, y después añadir "a pelo" los que necesito. En este caso, eliminaría los que destaco en rojo:
-z -K -g 1280x1024 -X 65012445 -u -d -p - -a 24 -r sound:local:3389

De esta manera conseguiremos un cliente view funcionando en pantalla completa, que nos permite volver al desktop pulsando ctrl+alt+enter y con teclado en castellano(*)
Espero que os sea útil.

(*) Es posible pasar a rdesktop el código de teclado mediante variable de entorno, pero lamento reconocer que no lo conseguí.

domingo, 21 de diciembre de 2008

Nota técnica: Conversión de Domain Controllers

Parece que está de moda convertir los domain controller. A pesar de que es una práctica no recomendada, se incrementan las "quejas" de mucha gente que intenta hacerlo. Partiendo de la base de que, en mi opinión, se tarda menos en promover un nuevo DC que en convertirlo, os dejo el link a un KB de VMware para los que aún se atrevan (o no les quede otro remedio) que convertirlo. Sólo un recordatorio: Converter sólo virtualiza un domain controller, no arregla un dominio con problemas. Para lo que sí sirve una conversión de un domain controller es para hacer aflorar o agravar los posibles "problemas" ocultos de un directorio, así que toca revisión exhaustiva el Dominio antes de la conversión (link, otro link, más una enormidad en google). Para los que os tropezáis con uno de esos Domain controller-navaja suiza (es decir, un DC que además tiene trescientas cosas más montadas encima), mi consejo es: Nueva VM, dcpromo para promoverla a DC, migración de roles (os dejo un link por aquí) y un dcpromo en la vieja para despromoverla como DC.

Un saludo.

domingo, 20 de abril de 2008

Nota Técnica: Windows w/o Windows....

Comentario recibido al post anterior:

"Mira, a lo mejor por eso Spectra ha sacado un flavour de Windows server 2008 que se llama "Server Core", donde no hay entorno gráfico ni zarandajas; sólo los servicios básicos del Sistema Operativo para ejecutar otras capas (¿SQL Server 2008, por ejemplo?, DNS, etc)."

Nada como consultar a Microsoft ante la duda:

¿Qué hace Windows Server core 2008?

Según documentación oficial de Microsoft, en un 2008 no tiene:
  • No hay escritorio
  • No hay explorador de Windows.
  • No hay .NET framework (nada de CLR). Consecuentemene NADA de SQL 2008 ni de Exchange 2007....
  • No hay MMC ni SnapIns.
  • No hay applets en panel del control, salvo excepciones.
  • No hay Internet Explorer.
  • No hay accesorios.
  • No hay ayuda en línea.
  • No hay boton de soporte.

¿Qué incluye Server Core?

  • El kernel. (El mismo de 2008, "sastamente" el mismo, con las mismas bondades y vulnerabilidades)
  • La HAL, limitada a soporte para disco, tarjetas de red, video básico y drivers básicos. El resto de drivers embebidos se eliminan, aunque es posible añadirlos.
  • Quedan logs del sistema, pero se invocan desde línea de comandos.
  • Soporta IPSEC.
  • Soporte completo de CLI.
  • Incluye Remote Desktop.
  • AD Básico (Nada de federación, nada de RMS, etc)
  • LDS
  • DHCP
  • DNS
  • File Services (Incluyendo NFS y DFS)
  • Print Services
  • Streaming
  • Hyper-V

Osea, básicamente es un Windows sin ventanas. Pero sigue siendo Windows... no es un sistema mínimo orientado a la aplicación a la que sirve (estilo appliance basada en Linux o similares).... Core Server sigue necesitando antivirus, mantenimiento (por línea de comandos, eso sí)... osea, más de lo mismo, eso sí, sin posibilidad de descargarme virus de internet o de ejecutar chorradas en la consola.

Todo esto está extraído de la documentación oficial de formación de Server 2008.

Valga como aclaración.

Nota Técnica: VMotion falla al 10%

¿Y qué pasa cuando VMotion falla al 10% del proceso dándonos un error similar a este?

Operation timed out Tasks: A general system error occurred: Failed waiting for data. Error 16. Invalid argument

Bueno.... vamos a dar unos pasos dirigidos a resolver ese tipo de incidencias. El documento original de VMware puede consultarse aquí. Desgraciadamente los links mencionados no funcionan en algún caso (he corregido los que he podido).

  1. Reiniciar el agente de gestión de los ESX (los famosos mgmt-vmware, vmware-*, mediante el comando service restart ) para más info, consultad Restarting the Management agents on an ESX Server (1003490).
  2. Verifiquemos que la configuración del networking del VMkernel es válido. A saber:
    - Que el host origen y el destino tienen configuradas redes para vMotion
    - Que las redes de vMotion se llaman igual (son case-sensitive)
    - Que ambos puertos están en la misma VLAN
    - Que el VMkernel tiene definido un default gateway
    Para más info, consultad Unable to set VMkernel gateway as there are no VMkernel interfaces on the same network (1002662).
  3. Verificar que las redes del VMkernel se ven entre ellas utilizando el comando vmkping. Funciona como el ping, pero a través de las interfaces del VMkernel. Para más información, consultad Testing vmkernel network connectivity with the vmkping command (1003728).
  4. Verificad que las consolas de ambos ESX se ven entre ellas, mediante ping. Para más información, consultad Testing network connectivity with the Ping command (1003486).
  5. Verificad que la resolución de nombres funciona entre los ESX. yo, personalmente, tengo como mala costumbre el añadir a los ficheros /etc/host de cada ESX las IP de gestión de cada uno de los ESX que mantengo. Así no dependo del DNS. Para ms información, consultad Identifying issues with and setting up name resolution on ESX Server (1003735).
  6. Verificad que todos los ESX utilizan la misma hora. Es fundamental el configurar la sincronización horaria. Yo uso NTP para sincronizar mis ESX contra un servidor NTP, que es, asu vez, controlador de dominio. Para configurar NTP en ESX, consultad Installing and Configuring NTP on VMware ESX Server. Para configurar un servidor Windows como servidor NTP, consultad Using Windows Server 2003 in a Managed Environment.
    Más información en Verifying time synchronization across environment (1003736).
  7. Si usamos límites de recursos en la configuración de la VM, verificad que esos límites, especialmente los inferiores - reservations - "caben" en el host de destino. Para más información VMware VMotion fails if target host does not meet reservation requirements (1003791).
  8. Verifiquemos que la Service Console (el COS) tiene recursos suficientes, especificamente que los procesos hostd no estén "saturando" la consola. Para más información, consultad Checking for resource starvation of the ESX Server service console (1003496).
  9. Verificad que la VM no está configurada para usar un dispositivo que no es válido en el host de destino. Para más información, consultad Troubleshooting migration compatibility error: Device is a connected device with a remote backing (1003780).

Si VMotion falla al 10% después de haber verificado todos estos aspectos, abrid un caso con VMware.

Saludos.

Nota Técnica: Mensajes de error de VMotion

Todos los hemos sufrido en alguna que otra ocasión, en especial cuando queremos presumir de VMotion, por aquello delefecto demo: Los famosos errores de VMotion. VMotion es la capacidad de VI3 ara mover en vivo una máquina virtual de un host a otro. Como requerimiento tenemos la presencia de un Virtual Center (VMotion NO puede hacerse sin él), la existencia de un Virtual Switch habilitado para el mismo, el almacenamiento compartido, y cumplir unos mínimos requerimientos para evitar situaciones de fallo, esto es:

  • Red de vMotion dedicada: No usemos trunks 802.1q para la red de vMotion. Ethernet es un protocolo orientado a pérdidas - usemos o no switches - y cuanto más tráfico, más posibilidades de fallo, así que aislemos el tráfico vMotion.
  • Red de almacenamiento adecuada: Usemos lo que usemos, iSCSI, NFS o FC, procuremos que la red sea lo más adecuada posible. Si nos decidimos por iSCSI, el vSwitch debe ser dedicado. Si escogemos NFS, tres cuartos de lo mismo.
El cumplir estos requisitos no evitará que puedan aparecer errores. A continuación cito los remarcados por VMware (quien quiera puede obtener el kb desde aquí)

Mensajes de compatibilidad de CPU.

Respecto a estos errores, mi granito de arena: VMware no virtualiza la CPU, lo que implica que la VM la ve tal y como es: Con sus características específicas. Este tipo de errores aparecen cuando se intenta migrar entra distintas generaciones de CPU de un mismo fabricante, o entre fabricantes distintos. El documento que se indica suministra información de cómo limitar el impacto de las diferencias de arquitectura entre generaciones de procesadores. Yo tengo algún DRS donde conviven 3 generaciones de Opteron: D, E y F, y con pequeños ajustes, hacen VMotion entre ellos sin problemas. No es necesario asustarse. Enmascarar características de las CPU para evitar estos errores es sencillo, aunque laborioso si se desea un ajuste fino.

Mensajes relacionado con la configuración de dispositivos.

Mensajes relacionados con la configuración del Disco.

Más granito de arena con ejemplo práctico: Un cluster virtual NO MIGRA!!!

Este es de los buenos. Básicamente VMware no recomienda hacer vMotion de máquinas con Snapshot, advirtiendo que la máquina puede caerse cuando la migración se completa. Entiéndanse las cursiva/negrita como ironía.

Mensajes relacionados con la configuración del ESX:

Mensajes relacionados con la configuración de red de vMotion:

Mensajes relacionados con la configuración de los recursos de VMotion.

Un saludo

Nota Técnica: VMware y Cisco

Para todos los que tenéis algún que otro quebradero de cabeza con ciertas configuraciones avanzadas de networking con ESX, aquí os dejo un documento de Cisco donde podéis encontrar todas esas respuestas que os (nos) han costado horas de interpretación de los manuales de ambos fabricantes. Os recomiento su lectura.

ServerVirtualization: Network Implications & Best Practices por Maurizio Portolani.

Disfrutadlo.

miércoles, 20 de junio de 2007

Nota Técnica: Windows server 2008 beta 3 en ESX 3.0

Si os da por instalar Windows Server 2008 en una VM bajo ESX, observaréis que la instalación os pide drivers para .... ¡¡¡ la unidad de CD !!! (progresamos, sin duda). Podéis descargaros de aquí una imagen de floppy con los drivers necesarios.

Un saludo.

miércoles, 16 de mayo de 2007

Nota Técnica: Nuevos parches para VI3.

Tenemos nuevos parches para nuestros servidores ESX, así que a parchear.

Clasificación:

ESX-4825991 Patch 05/15/07 Critical Patch
ESX-5095559 Patch 05/15/07 Security Patch
ESX-5140477 Patch 05/15/07 Security Patch
ESX-6657345 Patch 05/15/07 General Patch
ESX-6704314 Patch 05/15/07 Security Patch
ESX-7281356 Patch 05/15/07 General Patch
ESX-7302867 Patch 05/15/07 Critical Patch
ESX-7408807 Patch 05/15/07 General Patch
ESX-7557441 Patch 05/15/07 General Patch

ESX-7557441 for VMware ESX Server 3.0.1

Resolved Issues

This patch fixes an issue where restarting the mgmt-vmware service can cause an unexpected reboot of virtual machines that are configured to automatically start or stop

ESX-5095559 for VMware ESX Server 3.0.1

Security Issues

This patch fixes an issue where in a 64-bit Windows guest, on a 64-bit host, debugging local programs could create system instability. Using a debugger to step into a syscall instruction may corrupt the virtual machine's register context. This corruption produces unpredictable results including corrupted stack pointers, kernel bugchecks, or vmware-vmx process failures.
Thanks to Ken Johnson for identifying this issue.
The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2007-1876 to this issue.

Resolved Issues

  • This patch fixes an issue where the Linux virtual machine fails to boot from the network using PXE, and shows the network adapter hardware address as "FF:FF:FF:FF:FF:FF"
  • This patch is a partial fix for memory leaks that can occur in VMware Tools. You must also install patch ESX-6704314 to complete the fix for this issue. Patches ESX-5095559 and ESX-6704314 can be installed in any order. After both patches have been installed, you must upgrade the VMware Tools installed in all virtual machines on that host in order to complete this fix and to end warning messages that your virtual machine does not have the latest version of VMware Tools.

ESX-5140477 for VMware ESX Server 3.0.1

Security Issues

This patch fixes an issue where the SSL certificates used to authenticate mouse, keyboard and screen (MKS) connections for virtual machines were not being verified by the plugins for those devices.The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2006-5990 to this issue.

ESX-6657345 for VMware ESX Server 3.0.1

Resolved Issues

This patch provides an enhancement to the software ISCSI initiator that enables array vendors to certify iSCSI arrays that expect SCSI reserve/release commands without a data direction bit.

ESX-6704314 for VMware ESX Server 3.0.1

Security Issues

This patch fixes an issue where some VMware products support storing configuration information in VMware system files. Under some circumstances, a malicious user could instruct the virtual machine process (VMX) to store malformed data, causing an error. This error could enable a successful Denial-of-Service attack on guest operating systems.
Thanks to Sungard Ixsecurity for identifying this issue.The Common Vulnerabilities and Exposures project (cve.mitre.org) assigned the name CVE-2007-1877 to this issue.

Resolved Issues

  • This patch is a partial fix for memory leaks that can occur in VMware Tools. You must also install patch ESX-5095559 to complete the fix for this issue. Patches ESX-5095559 and ESX-6704314 can be installed in any order. After both patches have been installed, you must upgrade the VMware Tools installed in all virtual machines on that host in order to complete this fix and to end warning messages that your virtual machine does not have the latest version of VMware Tools.

ESX-7281356 for VMware ESX Server 3.0.1

Resolved Issues

  • This patch enhances the mechanism for time zone updates to ensure updated time zone rules are reflected in /etc/localtime.
  • This patch also provides the following updated time zone rules:
    Pulaski County, Indiana, is switching from CST/CDT to EST/EDT on 3/11/07
    Turkey switches at 01:00 standard time, not at 01:00 UTC.
    Updated Bahamas time zone with 2007 US DST change compliance
    Added new zone Australia/Eucla
    Atlantic/Faeroe time zone is renamed to Atlantic/Faroe
    Latitude/longitude changes for Europe/Jersey and Europe/Podgorica Note: Europe/Jersey and Europe/Podgorica time zones no longer observe daylight savings; the DST roll-forward on 3/25/07 and roll-back on 10/28/07 rules have been removed
    Cuba has ended its three years of permanent DSTNote: The rule governing the time change occurring on 10/28/07 has been removed

ESX-7302867 for VMware ESX Server 3.0.1

Resolved Issues

  • This patch resolves the following issues:
    An issue where an ESX Server panic can occur during a vm-support command after removing a USB drive from the host.
  • Updates the aacraid_esx30 driver to fix a condition that may cause an ESX Server console operating system panic when the corresponding device's /proc node is accessed. One example of such operation is during "vm-support" log collection.

ESX-7408807 for VMware ESX Server 3.0.1

Resolved Issues

  • This patch fixes an issue where the ESX Server host stops responding during the boot sequence, when a disk is missing or has failed when in RAID1 configurations on an Integrated RAID LSILogic controllers.

ESX-7557441 for VMware ESX Server 3.0.1

Resolved Issues

  • This patch fixes an issue where restarting the mgmt-vmware service can cause an unexpected reboot of virtual machines that are configured to automatically start or stop.

Os aconsejo aplicarlos todos, pero especialmente los críticos.

Buen parcheo y un abrazo.

Nota Técnica: VI3

Nuestro amigo Eduard nos comenta:

"Buenas, antes de nada felicitarte por el genial blog que tienes que a través del de Daniel Matey lo encontré.Me gustaría trastear con Infrastructure, pero las versiones que he encontrado son para linux.Me encantaría un post sobre el tema. Merci por todo!"

Eduard:

Virtual Infrastructure 3 no es un producto en sí, sino un conjunto de productos. Se compone de VMware ESX, la capa de virtualización, de Virtual Center, el servidor de gestión de infraestructura virtual, y productos como VMware Converter, la utilidad de conversión de físico a virtual o VMware Consolidated Backup, una solución de backup para máquinas virtuales.

VMware Virtual Center, VMware Converter y VMware Consolidated Backup se ejecutan bajo Windows; VMware ESX es una plataforma "near baremetal" que utiliza un cuasi-linux para arrancar y para la consola de gestión. No es un producto con "versiones" para Windows o Linux. Has de instalarlo sobre hardware "pelado".

Espero haberte sido de ayuda.

Un saludo.

sábado, 5 de mayo de 2007

Nota Técnica: WSUS

Nuestro estimado Jedi Daniel Matey ha colgado en su base estelar unas detalladas guías de uso y disfrute de WSUS que os aconsejo fervientemente leer, incluyendo algún script de su cosecha.

Bromas aparte, mantener nuestro parque de plataformas Windows actualizado es algo que trasciende más allá de la virtualización, entrando de lleno en el ámbito del sentido común. No hace mucho, conversando con uno de los mejores administradores Unix que conozco, le decía que era imposible comparar los entornos Unix con los entornos Windows, ya que el paradigma cambia, al menos en los entornos que él administra. Le decía que, habitualmente, los entornos Unix están más orientados al proceso, mientras que los entornos Microsoft están, y he ahí su baza, orientados al usuario. El perfil de administración es totalmente distinto, así como las capacidades necesarias para su administración. Durante un par de horas me dediqué a jugar con la línea de comandos de Windows 2003 server y creo que medio le convencí de que Windows Server es un Sistema Operativo. (Fuí con toda la mala intención, a ver si consigo traérmelo al grupo que lidero). A este hombre le extrañaba la necesidad constante de actualizar Windows, y creo que le aclaré la necesidad: No lo actualizamos porque esté mal, simplemente lo hacemos para que no lo esté.

En Unix te puedes permitir un sistema congelado en versiones más o menos antiguas en bastantes más casos que en un entorno Microsoft, básicamente porque Telnet y SSH no cambian demasiado, al menos en lo referente al acceso a los sistemas. En un entorno microsoft, estos escenarios se reducen muchísimo, y siempre asociados a entornos más o menos específicos. COnozco casos de alguien que sigue manteniendo Checkpoint 4.5 sobre NT Service Pack 2, y le vá tan bien que no quiere actualizar. Incluso hay aplicaciones que desaconsejan su actualización (Véase el Cisco Call Manager, que como le pases un Windows Update posiblemente deje de funcionar), pero como puede extraerse de estos dos casos, no son aplicaciones que estén orientadas a un contacto directo con el usuario (Call Manager lo más cerca que está del usuario es de su teléfono, y Checkpoint no lo vé ni de lejos; sólo interactúa con paquetes IP).

Para terminar, recuerdo una broma de mis comienzos en este mundo: el UPL (Universal Programming Language), si, ese que no existe, cuando los Talibanes del Pascal pretendían convencernos de que con Pascal todo era posible. No caigamos en el mito del UOS (Universal Operating System), y por supuesto, no valoremos los OS en base a nuestra experiencia con alguno determinado.

Para terminar, y aunque Daniel no esté de acuerdo conmigo, la frase del mes: Trabajamos con tecnología, no con productos.

Un abrazo.

viernes, 4 de mayo de 2007

Nota Técnica: ESX y las VLANs

Interesante artículo, que recomiendo leer, sobre el manejo y configuración de Virtual LANs (VLANs) en entornos ESX. Podéis leerlo aquí.

Estoy seguro que os será de gran ayuda.

Un saludo.

J. L. Medina

Nota Técnica: ESX@home II

Dado el interés que ha levantado mi modesto ESX@home, me he puesto a investigar. En esta pagina encontraréis información de cómo construirnos un ESX casero por muy poco dinero.

Espero que os sirva de ayuda.

Un abrazo;

J. L. Medina.

domingo, 29 de abril de 2007

Nota Técnica: Conversiones

Entiendo que todos los que leéis este blog ya habréis utilizado converter, aunque sólo haya sido para demostrar de lo que es capaz de hacer un usuario con derechos administrativos en el portátil del compi. Los que no lo hayáis hecho, ya estáis tardando.

Como ya he dicho en post anteriores, converter es una potente herramienta que facilita (en muchos casos) la vida del administrador. Aunque mi experiencia me dice que no siempre es posible realizar una conversión de físico a virtual, soy de los que me siento satisfecho con un ratio de conversión del 50%.

Como sabéis, converter permite la conversión "en caliente", es decir, sin parar la máquina a convertir, o "en frío", con la máquina apagada. Ambos tipos de conversión tienen su escenario de aplicación y la combinación de ambos métodos nos permitiré llevar a buen puerto (o a buen ESX) el proceso de virtualización.

Converter tiene dos modos de licenciamiento: El gratuíto, que permite sólo conversiones en caliente y una concurente, o el enterprise, que incluye las conversiones en frío, mediante un CD de arranque, y la concurrencia de conversiones. La licencia enterprise os viene incluída cuando compráis el ESX en modo enterprise.

Respecto a los modos en que converter opera, digamos lo siguiente:

Conversión en caliente.

El proceso de conversión en caliente es simple: Una vez instalado el agente, este realiza una instantánea del disco (snapshot) y lo que "mueve" es ese snapshot. De ambos modos, a igualdad de servidor, es el más rápido, ya que sólo mueve los datos contenidos en el disco. Sobra decir que los datos que se mueven son los contenidos en el snapshot, no los generados desde que se creó el snapshot hasta que se completó la virtualización. Este método es especialmente recomendable en bases de datos en producción si queréis perder las transacciones realizadas durante el periodo de conversión y que vuestro jefe se os quede mirando con cara de "¿pero tú eres tonto o qué". Ya en serio, sobra decir que si usáis la conversión en caliente en servidores de este tipo - Bases de datos, servidores de ficheros, servidores con contenido variable en el disco en general - Lo hagáis en ventana sin usuarios, aunque os recomiendo que en este caso, utilicéis el método de conversión en frío. Yo lo he utilizado para cosas como controladores de dominio (se resincronizan con facilidad), servidores SMTP (incluyendo exchange), servidores web (si el contenido no varía), servidores de gestión (DHCPs, DNS, etc) donde el diferencial del contenido entre el momento del snapshot y el power on de la nueva máquina virtual no sea crucial. Incluso un servidor de ficheros, en hora de mínimo impacto (o nulo) es un candidato adecuado.

Hay cosas que la conversión en caliente no se come: Una de ellas es un servidor con discos por iSCSI. Falla. Así que ya sabéis. Entiendo que un Oracle con raw disk tampoco colará, ya que el agente de converter se mueve al nivel del sistema de ficheros.

Conversión en frío.

La conversión en frío es el método más recomendable siempre que se puedan parar las máquinas. Utiliza un Windows PE para la ejecución, así que hay que tener en cuenta que el hardware de disco del servidor, así que primero debéis aseguraros de que el controlador de la SCSI o FC de vuestro server está en la lista incluída en la imagen PE. Si no fuera así, tranquilos. Converter permite la modificación de la imagen PE para adaptarla a nuestro hardware. Eso sí, requiere que el NTFS esté en estado correcto (lo de un NTFS inconsistente parece que no es lo suyo, así que olvidaros del botonazo o de convertir ese servidor que ya ha caído). Como norma general valga la que dice que si PE no ve el disco no lo convertirá.
Aquí os dejo el link de la documentación de VMware converter.

Servidor orígen.

En lo referente a los orígenes de la conversión, converter permite trabajar con conversiones de Físico a Virtual (P2V), de virtual a virtual (V2V) o de imagen a Virtual (I2V). La conversión de virtual a físico queda clara. La de Virtual a Virtual la aplicaríamos cuando deseemos pasar máquinas virtuales de VMware Workstation, GSX o Server, o Microsoft Virtual Server a ESX o a VMware Server, Workstation o GSX.

En lo referente a I2V, VMware converter soporta los siguientes formatos:
  • Symantec Backup Exec System Recovery Files
  • StorageCraft Shadow Protect

Personalmente no he probado a hacer una I2V, pero tengo conocidos que sí lo han probado con éxito.

Consideraciones en las conversiones V2V.

Uno de los detalles a tener en cuenta en una conversión V2V es que Converter "importa" el fichero de imagen de disco directamente, así que si tenéis una VM en un GSX con un disco de 50Gb preasignado, Converter importará los 50 Gb. Otra consideración a hacer es que la VM tiene que estar parada. Esto me pasó en una migración de GSX a VI3. Tras esperar dos horas, aborté la conversión. Al final me decidí por tratar a las VM como máquinas físicas, me dediqué a borrar ficheros sobrantes en las VM y, ni corto ni perezoso, les apliqué un P2V. Resultado: En 25 minutos las VM convertidas y sin apagarlas. Funciona y lo hace bien. Os recomiendo el método. He de probarlo con Microsoft Virtual Server. Si alguien se anima, que nos pase feedback.

Converter, en su versión 3.0.1, ofrece la característica experimental de realizar conversiones desde línea de comandos. Esta característica abre excitantes posibilidades para Disaster recovery programados de servidores. Prometo investigarla.

Espero que estas reflexiones os sean de ayuda.

viernes, 27 de abril de 2007

Nota Técnica: Mi ESX@home

Pues sí, tengo en casa un flamante ESX. En otra época de mi vida laboral, mi oficina estaba en casa, así que decidí montarme un Lab... y hasta ahora.

Uno de los "problemas" de ESX es, precisamente, el Disco duro. Como el señor nos ha salido fino, pide discos SCSI y una controladora más o menos decente (y soportada) para montarlo. Y no, no invertí un pastizal en montarlo. Os cuento mi montaje.

  • Placa Base ASUS P4-800 (la que viene con intel en placa)
  • Pentium 4 a 3.2 Ghz
  • 4 Gb de memoria RAM
  • Controladora IBM ServeRaid 4M
  • 2 Discos IDE de 80 Gb para arranque en Mirror.
  • 5 Discos SATA de 300 GB para los VMFS.

¿Qué cómo me lo hice?, Pues bien fácil. Encontré un cacharrito que me permitía conectar mis baratísimos discos SATA a una controladora LVD 160. El gadget en cuestión lo podéis encontrar aquí. No necesitáis una controladora SCSI de la muerte; con cualquiera de las 2940 de adaptec de las que tenéis por ahí oxidándose funciona.

Si tenéis algo más de pasta (y no os apetece hacer la ñapa con los conversores SATA/SCSI), hay una adaptec SATA soportada, ya que se identifica como una 29160 o así.

Hasta otra.

lunes, 23 de abril de 2007

Nota Técnica: Usando Windows Server como servidor NFS para ESX

Me ha tocado implementar una nueva estructura VI3 en uno de nuestros clientes, y, dado que no disponemos por el momento de almacenamiento SAN, he decidido usar NFS para el despliegue de plantillas de máquinas virtuales, imágenes ISO y de repositorio central de parcheado de los tres ESX que conforman la infraestructura virtual.

He encontrado un how-to bastante simpático de como hacerlo, y dada mi natural vagancia, os lo dejo por aquí, eso sí, traducido.

Este how-to ha sido realizado por Jason Mattox, de Vizioncore.

Esta configuración en particular usa un servidor Windows como servidor NFS, mediante la instalación de los Windows Services for UNIX (WSFU). La siguiente url contiene información detallada de la autenticación NFS en el entorno de WSFU:http://www.microsoft.com/technet/interopmigration/unix/sfu/nfsauth.mspx

Nota importante: O bien habéis configurado la opción PermitRootLogin = yes en el /etc/ssh/sshd_config del VMware o tendréis que crear una cuenta en el ESX para acceder a estos por SSH.



Resumen del proceso:

  1. Instalar Windows Services for Unix
  2. Copiar el fichero de passwords y grupos de un servidor ESX al servidor NFS Windows
  3. Configurar WSFU para que acepte las conexiones de los servidores ESX
  4. Compartir la carpeta en el servidor Windows con soporte NFS
  5. Configurar ESX para que monte los shares NFS de Windows como Datastores.

  1. Instalar Windows Services for Unix
    Primero, cómo no, nos lo descargamos de http://www.microsoft.com/windowsserversystem/sfu/downloads/default.mspx
    Procedemos a instalarlo en el servidor Windows, configurando las siguientes opciones:

    * NFS + Server for NFS
    * Authentication tools for NFS + user name mapping

    Tras la instalación, abriremos el panel de control de servicios, y cambiaremos el servicio llamado "User Name Mapping" para que arranque automáticamente. Tras esto, iniciaremos el servicio.
  2. Copiar el fichero de passwords y grupos de un servidor ESX al servidor NFS Windows

    Usaremos cualquier programa de copia SCP (Como el WinSCP) para copiar los siguientes ficheros al servidor NFS en Windows:
    * /etc/password
    * /etc/group
    Debemos copiar estos ficheros en la carpeta donde hayamos instalado WSFU. podéis descargaros el WinSCP de http://winscp.net/eng/download.php#download2
  3. Configurar WSFU para que acepte las conexiones de los servidores ESX

    * Ir a Inicio, Programas, Windows Services for UNIX Administration
    * Ir a User name mappings, seleccionar configuration


    *
    Ir a password and group files. Aquí buscaremos los ficheros que hemos copiado antes medante el diálogo de busqueda de ficheros. Haremos lo propio tanto para el fichero de passwords como para el de grupos
    * Aplicaremos los cambios.
    * Seleccionar Maps e ir a show maps. Seleccionaremos List windows users and List Unix Users.
    * Seleccionaremos un administrador local de la máquina Windows en la izquierda que será mapeado al usuario root en la derecha


    * Aplicaremos los cambios (arriba a la derecha)

    Como ejemplo utilizaremos el siguiente share: \\nfssrv.acme.com\NFS01

  4. Compartir la carpeta en el servidor Windows con soporte NFS.

    * Pulsaremos boton derecho sobre la carpeta que deseamos compartir por NFS.
    * Seleccionaremos NFS Sharing. Asignaremos el nombre de la carpeta, en nuestro ejemplo, NFS01
    * Eliminaremos la opción "allow anonymoys access"
    * Iremos a "Permissions"
    * Cambiaremos los permisos a "Read+Write"
    * Activaremos "Allow root Access"




  5. Configurar ESX para que monte los shares NFS de Windows como Datastores.

    Abriremos el cliente de Virtual Center y seleccionaremos el host que va a acceder al servidor NFS.
    * En la pestaña de configuración, seleccionaremos Networking, Add Networking y seleccionaremos un vSwitch que pueda acceder al servidor NFS. Añadiremos una conexión VMkernel con una IP que le permita acceder al servidor NFS.








    * Seleccionaremos Storage, Add storage, Network File System




    * en el campo destinado al servidor, pondremos el nombre o la IP del servidor NFS, p.e. nfssrv.acme.com
    * en el campo "Folder", pondremos el nombre del share que hemos configurado antes, p.e. /NFS01

Aqui podéis ver el artículo original.

Espero que os sirva de ayuda.

Un saludo.

miércoles, 11 de abril de 2007

Nota técnica: Virtualización asistida por hardware.

Mucho se habla (y más se hablará) sobre las ventajas e inconvenientes de la Virtualización asistida por Hardware. Los dos contendientes en la Chip Wars, AMD e Intel incorporan en sus chips nuevos juegos de instrucciones que facilitan la virtualización. Por un lado, AMD con Su codename Pacifica, y por otro, Intel con Vanderpool.

Pero antes de hablar sobre estas tecnologías, veamos los tres grandes tipos de virtualización: Emulación, Paravirtualización y traducción binaria.

El método de virtualización con el que creo todos estamos más familiarizados es la emulación. Todos hemos ejecutado el emulador de nintendo, o el de pocket PC, por poner ejemplos. Y todos sabemos cual es su principal problema: La lentitud. El overhead de simular byte a byte un hardware por software hace trabajar a las CPU de manera considerable. El desarrollo de emuladores es una tarea ardua y propensa a errores.

En el otro extremo está la Paravirtualización. La paravirtualización (PV) parte de la base de que el sistema operativo huesped "sabe" perfectamente que está siendo ejecutado en un entorno virtual, y modifica su comportamiento de acuerdo con esto. Los sistemas operativos necesitan ser modificados para adaptarse a un entorno "hardware" virtual, lo que implica que hay una relación directa entre cómo se escribe el kernel del sistema operativo y cómo virtualiza la capa de virtualización. Realmente la Paravirtualización no es virtualización pura, sino más bien una colaboración entre la capa de virtualización y el sistema operativo virtualizado. Esto funciona bastante bien en entornos abiertos, donde el kernel del sistema operativo (como linux o BSD) puede ser modificado para tener en cuenta que "debajo" hay una capa de virtualización, pero en el caso de otros OS'es (como es el caso de Windows), la cosa no está tan clara. En este caso, hablar de rendimiento nativo es realmente relativo, ya que un OS's virtualizado no ejecuta exactamente el mismo código ni opera igual que si corriera en hardware real.

En el medio de estas dos opciones encontramos la, que hasta el momento, parece ser la mejor opción: La traducción binaria. La traducción binaria. La traducción binaria parte de la base de la existencia de un monitor de máquinas virtuales (VMM) que monitoriza a cada segundo las instrucciones que el sistema operativo huesped envía al procesador. Si el VMM detecta una instrucción problemática (que puede afectar al entorno de virtualización, otras VMM o a la estabilidad del hardware hospedador - host), rápidamente la reescribe (muchas veces convirtiendo una sola instrucción en docenas de ellas), y devuelve el resultado al huesped, que interpreta que esa instrucción original ha sido ejecutada. El resto de instrucciones no problemáticas son pasadas directamente al procesador.

Es evidente que reescribir instrucciones no es la manera más rápida de virtualizar, pero sí nos garantiza la ejecución de cualquier OS soportado SIN necesidad de reescribir el kernel del mismo. También abre la puerta a la virtualización de OS's que corren en hardware distinto al de nuestra plataforma base (en este caso, x86, x64, i64)... imaginad AIX corriendo en una VM... o incluso el Cisco IOS... porqué no?

¿porqué es necesario hacer todo esto?... pues básicamente porque la arquitectura x86 no es virtualizable. Entendamos un poco cómo funciona nuestro PC.

Existen, al menos, 4 niveles de privilegio de acceso al procesador, llamados anillos y numerados del 0 al 3, cuya prioridad es inversa a su numeración, aunque en la práctica, sólo se usan el 0 y el 3 (el de mayor y menor prioridad, respectivamente). Los sistemas operativos usan típicamente el anillo 0, mientras que los programas usan, también típicamente, el anillo 3. De hecho, las extensiones de 64 bits de los procesadores x64 sacrifican, en muchos casos, los anilos 1 y 2... No hay demasiada gente que se haya preocupado por ello (¿vosotros lo notáis?)... salvo aquellos que trabajan desarrollando capas de virtualización.

Es evidente que las capas de virtualización (VMware ESX, por ejemplo) se ejecutan en el anillo 0, y para poder mantener constantemente el control del sistema, han de mantener al OS huésped fuera de él. La solución más obvia es, entonces, ejecutarlo en el anillo 1 (por ejemplo). Esto sería una solución gloriosa si no fuera por esa manía de los sistemas operativos de ejecutarse en el anillo 0. En entornos de paravirtualización no hay problema: como el huésped colabora con la capa de virtualización, este puede decidir ejecutarse en anillo 1, por ejemplo, si la capa de virtualización así se lo indica. En la traducción binaria, hay que "obligar" o "engañar" al huesped para que se ejecute en el anillo 1. Esto tampoco parece complicado, salvo porque hay determinadas instrucciones no funcionan o lo hacen de modo extraño si no se ejecutan en el anillo 0 del procesador. La traducción binaria hace eso exactamente: Mentirle al sistema operativo huesped.

La virtualización asistida por hardware entra precisamente en este punto mediante el nuevo modo VMX. Por resumirlo de una manera sencilla (aunque no totalmente exacta), tanto Vanderpool como Pacifica permiten a la capa de virtualización ejecutarse en un "anillo -1", es decir, con mayor prioridad que el 0, de forma que ya no es necesario engañar al sistema operativo. El Virtual Machine Monitor se ejecuta en modo VMX root, mientras las VM se ejecutan en modo VMX. El procesador alterna entre universos mediante los procesos "VM entry" y "VM exit."

Las tecnologías VT permiten movernos (mediante VM entry y VM exit) entre el modo VMX y el VMX root, aislando a nivel de procesador, los universos del Virtual Machine Monitor (VMM) y de la máquina virtual (VM).

¿Maravilloso, No? Pues no... El trabajo de recordar que estaban haciendo el VMM y todas las VM no está implementado a nivel de procesador. El procesador provee mecanismos simples que facilitan al VMM la conservación de estados, pero el trabajo sucio sigue siendo del VMM.

Para quien le interese enterarse en profundidad de qué va todo esto, le recomiendo el siguiente link de donde, y si mi inglés no me ha abandonado, he sacado parte de la información que ofrece este post.

Ahora bien... ¿Vanderpool o Pacífica? Aunque el mecanismo es el mismo, las instrucciones, e incluso el modo de operación, varía. Pacifica parece ser un superset de Vanderpool, ofreciendo más mecanismos en el chip para facilitar la vida de los VMM. Estos comandos extras se agrupan en tres tecnologías propias de AMD, Nested Table Pages, Device Exclusion Vector y el Tagged TLB. Este documento os cuenta más extensamente que hacen estas tecnologías.

Que conste que Pacífica aún no tiene implementadas del todo estas tecnologías, por lo que lo que obtendréis al pagar un AMD con Pacífica es poco más que lo que os dá Vanderpool.

Como resumen, parece ser que Pacífica le pondrá más fácil las cosas a los VMM, mientras que Vanderpool sacrifica funciones en favor de la velocidad.

¿porqué tanto ruido con la virtualización asistida por hardware? Respuesta fácil: es la única manera en que un entorno Paravirtualizado (como Xen o Viridian) pueda ejecutar un sistema operativo sin modificar el kernel. Básicamente el procesador permite a un OS sin modificar instalarse en el anillo 0, dejando el -1 para el VMM. Evidentemente, esto a VMware le hace bastante poca gracia, dado que, en teoría, la traducción binaria ya no haría falta. Digo en teoría porque se me ocurren un par de cositas que la traducción binaria puede solucionar y que me dá a mi que tal y como se llevan Intel y AMD la virtualización asistida no:


  • Diferencia entre procesadores: el uso masivo de VT generará una mayor dificultad para el movimiento de VM entre diferentes modelos de procesador. Actualmente VMware "soporta" ligeros cambios de serie (Especialmente en Opterones y Xeones, donde los cambios en los micros suelen estar relacionados con el anillo 0, que se gestiona por Traducción Binaria y no por VT).
  • Compatibilidad: La traducción binaria extiende el campo de la virtualización a prácticamente cualquier micro x86 de 32 bits. VT la limita a la incorporación de esta tecnología.
  • VT es una tecnología emergente, aún saliendo del horno. Intel ya habla de VT v2, VT v3 y VT v4.... ¿Será la compatibilidad descendente una rémora de rendimiento tal y como lo fueron los 16 bits?
  • VT está siendo desarrollada por fabricantes de hardware, no por fabricantes de VMM... y teniendo en cuenta pasadas colaboraciones.... no sé yo que pensar.
  • VT limita la virtualización a plataformas x86.... La traducción binaria puede abrir nuevas puertas para la virtualización de otras plataformas.

¿Intereses creados? Todos. A favor: Microsoft el primero, porque si no se olvida de competir con VMware. Xen Enterprise, los segundos porque así pueden ejecutar Windows. Intel y AMD, los terceros, ya que la virtualización les quita "negocio", al menos algo recuperarán con lo que está por venir. En contra: VMware, que ve a la competencia meterse en su nicho privado, que era hasta ahora la ejecución de Windows en una VM.

Mi opinión: Que sobrevivan las dos. Hasta VMware puede sacar partido de VT.

¿Pero es tan realmente importante eso? Yo, personalmente, creo que no. No pienso que lo más importante en un entorno virtualizado sea en qué anillo se ejecute el OS, o la velocidad de ejecución de las máquinas virtuales. Creo que hay cosas más importantes que valorar: Estabilidad, snapshots, movilidad entre hosts, opciones de HA.... se me ocurren mil cosas que pedir antes de mayor o menor velocidad.

¿a vosotros no?

PD. Gura, espero que esto fuera lo que querías, camarada.

martes, 27 de marzo de 2007

Nota técnica: Problemas con el reloj bajo VMware

Uno de los incidentes más habituales y que trae de cabeza a más de uno viene dado por el reloj de las máquinas virtuales. Alguno de vosotros ya habréis observado que el reloj de cualquier sistema operativo que virtualicéis bajo VMware Server y/o ESX (a mí en Workstation no me ha pasado aún) es que el reloj de la VM parece ir más lento ( o más rápido). Este problema es especialmente acuciante en VM's bajo Linux.

En el entorno Windows, incluso en VM's dentro de un dominio (donde el DC hace de servidor de tiempo), podemos sorprendernos encontrando un desfase de horas entre nuestras VM y las máquinas físicas. El Knowlegde Base de VMware (accesible desde la página principal de VMware) ofrece distintas soluciones, aunque he de reconocer que la presentación es bastante confusa.

Como norma general, vengan las siguientes recomendaciones:

  1. Utilizar una sola fuente de reloj: Es decir, si usáis ntp, desactivar el "Time sync" en las VMware Tools y viceversa.
  2. No uséis al host VMware como time server: El COS (Console Operating System) no está pensado para esto, y la ejecución del algún proceso en él puede afectar al reloj.
  3. En el caso de Linux, Los escenarios varían:
  • Si vuestro reloj se ralentiza bajo VI3, mirad este Link
  • Para el resto de los casos (reloj acelerado, otras plataformas), usad este otro

¿Quién dijo que sólo Microsoft tiene "particularidades" tontas?

Un saludo.