Live Debugging de Máquinas Virtuales con Hyper-V

El hecho de que una máquina sea virtual no implica que un gran número de las operaciones que sobre ellas se realizan tenga porqué ser diferente a lo que hemos venido haciendo hasta el momento con entornos "físicos". El diagnóstico y la resolución de problemas es uno de esos casos, al igual que cierto tipo de tareas y operaciones de mantenimiento, que pueden depender fuertemente de las aplicaciones o servicios albergados en la máquina virtual, como en el caso de los controladores de dominio de un Directorio Activo.

En ocasiones recibo consultas acerca de si tal o cual problema puede deberse a tener el producto o el servicio corriendo en entornos virtualizados. Lo cierto es que en rarísimas ocasiones la pila de virtualización será la causante de nuestras desdichas, por lo que en la gran parte de las ocasiones deben aplicarse las técnicas y herramientas tradicionales de diagnóstico y resolución de problemas.

La depuración de equipos en caliente es un conjunto de técnicas que se utilizan en muy pocas ocasiones, y por lo general se hace como último recurso para problemas muy determinados o extremadamente rebeldes. Sin embargo esta técnica es una buena herramienta para aprender el funcionamiento de un sistema operativo a bajo nivel y complementa el uso de las herramientas de depuración para el análisis de volcados de memoria y depuración de procesos.

La depuración en vivo del kernel puede hacerse de dos formas. En local o en remoto. La depuración local tiene el problema de que el depurador corre por encima del sistema operativo de la máquina que estamos depurando, y por tanto tiene ciertas limitaciones y corremos el riesgo de perder totalmente el control del equipo. La depuración en remoto se ha venido realizando tradicionalmente a través de modems o cables serie nulos, y con ello logramos tener control total sobre la casi totalidad del sistema operativo del "target" remoto.

Vamos a ver como hacer esto último con máquinas virtuales. La idea es sencilla. Se trata de instruir al sistema operativo para que se active el depurador del kernel, que se encargará de enviar la información por un puerto serie, y hacer que la pila de virtualización "mapee" ese puerto serie de la máquina virtual a una pipe, al otro lado de la cual estará escuchando el depurador. Este podrá estar instalado en el propio host de virtualización, o en otra máquina donde tengamos el entorno de depuración configurado.

Preparación el SO de la máquina virtual

En esta configuración de ejemplo vamos a configurar sistemas operativos XP, 2003, Vista y 2008 para ser depuradas en remoto a través de su COM2. Esta configuración es idéntica tanto de si el SO está instalado en un equipo real como si lo está en una máquina virtual. Debido a los cambios introducidos en los boot loaders de Vista y 2008, los pasos son diferentes en estos sistemas con respecto a XP y 2003. Resumiendo, esto es lo que hay que hacer (resumido/fusilado de https://msdn.microsoft.com/en-us/library/ms791527.aspx)

• En Windows XP y Windows Server 2003: Basta agregar las opciones /DEBUG /DEBUGPORT y /BAUDRATE al boot.ini. Lo ideal es duplicar la entrada por defecto del boot.ini agregando estos modificadores para poder elegir en el arranque. Por ejemplo:

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP SP3" /fastdetect

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP SP3 (Kernel Debug en COM2)" /fastdetect /DEBUG /DEBUGPORT=COM2/BAUDRATE=115200

• En Windows Vista y Windows Server 2008. Utilizando bcdedit o bien modificamos directamente la entrada por defecto, o la copiamos y modificamos la copia para agregarle los mismos parámetros. Tenéis más información en https://www.microsoft.com/whdc/driver/tips/debug_vista.mspx
  • Copiamos la entrada por defecto, apuntándonos el nuevo identificador ({ID}) que se le asigna: bcdedit /copy {current} /d "Windows Vista/2008 Debug (COM2)"
  • Establecemos las opciones de debug que necesitamos: bcdedit /dbgsettings serial debugport:2
  • Habilitamos esas opciones en la nueva entrada, usando el ID del primer paso: bcdedit /debug {ID} ON

Configuración de la Máquina Virtual en Hyper-V

En las propiedades de la Máquina Virtual simplemente establecemos la configuración de la pipe a la que queremos redirigir el COM2. Esta pipe puede referirse al equipo local (el depurador esta instalado en el host con Hyper-V), o a un equipo remoto donde tenemos preparado el entorno de depuración, que será lo más probable en el caso de que el host de virtualización este solamente dedicado a eso, con una instalación "Server Core"

Como se puede observar, la única diferencia es la manera en la que se construye la ruta. Se utiliza en nombre del servidor remoto en el que tenemos instalado el depurador (derecha), o un punto (.) para referirnos al servidor local (izquierda). El nombre de la pipe (canalización) puede elegirse a voluntad y en este caso es "SerieCOM2". Esta misma configuración se puede llevar a cabo igualmente en Virtual PC y Virtual Server, siguiendo los pasos de este KB: https://support.microsoft.com/kb/871171/en-us/. En otros entornos de virtualización que permitan esta redirección de los puertos COM o USB, es posible igualmente

Conexión del depurador

Ya solo nos queda conectar el depurador mediante una sesión de Kernel Debug a la máquina virtual mediante la pipe configurada en el paso anterior, manteniendo lógicamente la misma nomenclatura. Puede hacerse de diferentes maneras dependiendo del depurador que estemos utilizando. En el caso de WinDBG podemos usar tanto la interfaz gráfica como una línea de comandos:

• WinDBG, mediante la Interfaz Gráfica:

 

• WinDBG, por línea de comandos: windbg -k com:pipe,port=\\.\pipe\SerieCOM2

Como dice la documentación, los parámetros "Reconnect" y "Resets" están indicados para cuando las máquinas Virtuales estén ejecutándose en Virtual PC. Bastaría marcar la casilla o agregar ,resets=0,reconnect a la línea anterior.

NOTA: Los usuarios con UAC activado, deben tener la precaución de lanzar el depurador con privilegios elevados.

Una vez hecho esto nos encontraremos con que el depurador se queda esperando que le llegue la información de depuración de la máquina virtual.

y solo tendremos que mandar un Ctrl-Break (Ctrl-Pausa) para tener la máquina virtual totalmente a nuestra merced:

En ese momento, el depurador está esperando que le demos algún comando, y la máquina virtual está completamente congelada, como lo estaría igualmente un servidor físico que estuviésemos depurando mediante un cable nulo, USB o IEEE 1394. Si queremos que continúe su ejecución normal, simplemente tendremos que darle al depurador la orden de "Go" (g), y esperar a la ocasión en la que queramos volver a detenerla con un nuevo Ctrl-Break. Mientras tanto veremos que el "Debugee is running" en la ventana del depurador, situación en la que también puede cerrarse y dejar la depuración en vivo para mejor ocasión:

Vale, pero, ¿y ahora que?. Pues la verdad es que como ya comente en un post anterior, este mundo es muy amplio y las cosas que se pueden averiguar casi ilimitadas. Aquí van algunos comandillos para ir abriendo boca

• Información de sesiones: !session y !logonsession 0
• Sacar información sobre los procesos en ejecución: !process 0 0
  • Listar los procesos por sesión: !process /s <session ID> 0 0
• Listar los módulos cargados: lm, lm t n
• Sacar más información de un módulo: !lmi <Base Address> (obtenida del comando anterior)
• Estado de la memoria: !vm y !memusage (este tarda un rato)
• Causar un volcado completo de memoria:
  • Limpiamente: .dump
  • A lo bruto: .crash (muy útil para que la gente se entretenga en sacar fotos durante una charla)
• Forzar un reinicio (frio) del equipo: .reboot

Se puede encontrar más información sobre todo esto en los siguientes temas de la ayuda de las Debugging Tools:

• Attaching to a Virtual Machine (Kernel Mode)
• Boot Parameters to Enable Debugging

Como decía al principio, esto no es una herramienta para uso frecuente, aunque si un buen recurso para aprender y "tocar" los entresijos del sistema operativo. Solo algunos iluminados son capaces de sacarle todo el partido

Saludos

David Cervigón

Comments

• Anonymous
  January 01, 2003
  Como continuación al post " Virtualización para Dummies ", (imprescindible su lectura para sacar mas

• Anonymous
  January 01, 2003
  Pues no hay manera de hacerlo directamente. Lo que puede intentarse es enchufar ese modem a la partición padre y usar ICS + Routing. La gente suele hacer estas cosas para hacer que las VMs salgan por la Wireless del portátil, ya que por lo general los modems y las WLAN no se pueden convertir en un switch virtual para su uso directo por las VMs Saludos

• Anonymous
  January 01, 2003
  Hola No conozco manera. Los COM de la VM se mapean a una pipe en el servidor local o un servidor remoto. Desconozco si es posible que redirigir esa pipe a un COM físico real Saludos

• Anonymous
  November 15, 2008
  David, tengo que conectar un modem a un servidor virtual w2008 montado en hyper-v de w2008, y no se como capturar el puerto com4 donde esta el modem configurado de la maquina Host. Te agradecería enormemente alguna información, link, ... Gracias.

• Anonymous
  November 21, 2008
  Gracias, eso que me comentas es lo que había leido, ¿pero entonces como puedo ponerle un modem usb a la maquina virtual?. De todas formas si no tienes información muchas gracias. Saludos