Cómo utilizar PowerShell Direct paso a paso en Hyper-V

Si trabajas con máquinas virtuales en Hyper-V y te pasas el día peleándote con redes, firewalls y políticas que cortan el acceso remoto, PowerShell Direct te va a ahorrar muchos disgustos. Es una de esas funciones que, cuando la pruebas, te preguntas cómo has podido vivir sin ella hasta ahora.

Con PowerShell Direct puedes lanzar comandos y scripts directamente dentro de una máquina virtual desde el host, sin depender de que haya conexión de red, sin abrir puertos y sin configurar WinRM. Todo viaja por el bus interno de la VM, de forma local y bastante transparente para el administrador.

Qué es exactamente PowerShell Direct

PowerShell Direct es una característica introducida en Windows 10 y Windows Server 2016 que permite abrir una sesión de PowerShell directamente contra una máquina virtual que se está ejecutando en el mismo host Hyper-V, utilizando el canal interno que ofrece el propio hipervisor en lugar de la red.

Gracias a este mecanismo, no hace falta que la máquina virtual tenga adaptador de red, ni que esté conectada a ningún conmutador virtual, ni que hayas configurado administración remota o reglas específicas de firewall. Mientras la VM esté encendida y el sistema operativo invitado haya arrancado correctamente, puedes administrarla con PowerShell Direct.

En la práctica esto significa que ya no dependes de la conectividad IP para tareas de automatización, configuración inicial, pruebas de laboratorio, demos o resolución de problemas cuando una mala configuración de red te ha dejado “a oscuras”. Puedes seguir trabajando sin tener que ir a la consola gráfica de Hyper-V para teclearlo todo a mano.

Antes de que existiera esta funcionalidad, la única forma de ejecutar comandos PowerShell en una VM Hyper-V era a través de la red con Invoke-Command o Enter-PSSession, pasando el nombre de equipo o la dirección IP (-ComputerName). Si la máquina estaba en una red aislada, con firewall muy restrictivo o simplemente sin tarjeta de red, te tocaba usar la consola de la VM y listo.

Con PowerShell Direct cambian las reglas del juego: ahora puedes usar cmdlets clásicos de remoting pero apuntando al nombre de la máquina virtual o a su GUID (-VMName o -VMId) en lugar del nombre de equipo de red, y todo el tráfico va por el bus interno gestionado por Hyper-V.

Requisitos para poder usar PowerShell Direct

Antes de lanzarte a probarlo, conviene asegurarse de que cumples con los requisitos mínimos de sistema operativo y configuración, tanto en el host como en las máquinas virtuales.

En cuanto al sistema operativo del host Hyper-V, necesitas Windows 10, Windows 11 o Windows Server 2016 en adelante, siempre con el rol de Hyper-V instalado y funcionando. Versiones anteriores de Windows Server o ediciones de cliente sin soporte para esta característica no exponen los parámetros -VMName y -VMId en los cmdlets de remoting.

Respecto a los sistemas invitados, PowerShell Direct requiere que la máquina virtual ejecute también Windows 10, Windows 11 o Windows Server 2016 o superior. Si estás administrando VMs con Windows más antiguos, tendrás que seguir tirando de VMConnect o de la administración remota tradicional por red.

Además, la VM debe estar alojada y ejecutándose en el mismo host Hyper-V desde el que vas a conectarte. No sirve para gestionar VMs que residen en otro servidor Hyper-V remoto; en esos casos tendrás que combinar PowerShell remoto clásico hacia el host y algún otro mecanismo.

Otro requisito importante es que la máquina virtual esté encendida y con al menos un perfil de usuario configurado en el sistema operativo invitado. Si el SO no ha terminado de arrancar o se ha quedado bloqueado pidiendo intervención del usuario, la conexión por PowerShell Direct no llegará a establecerse correctamente.

En el lado del host, tendrás que abrir la consola de PowerShell con privilegios de administrador de Hyper-V. Es decir, tu cuenta debe pertenecer al grupo de administradores de Hyper-V para que los cmdlets que usan -VMName o -VMId puedan acceder a la información de las VMs y al canal interno que las conecta con el host.

Por último, para entrar en la sesión del sistema invitado tendrás que proporcionar unas credenciales válidas de usuario dentro de la máquina virtual. No hay acceso “mágico” sin autenticación: el host no obtiene permisos de administrador automático en la VM, así que deberás indicar usuario y contraseña de una cuenta válida (normalmente una cuenta local o de dominio con privilegios de administrador dentro de la VM).

Cómo funciona PowerShell Direct a nivel práctico

A la hora de usarlo en el día a día, PowerShell Direct se apoya en los mismos cmdlets de PowerShell Remoting, pero añade parámetros específicos para Hyper-V que sustituyen al clásico -ComputerName. Los cmdlets clave son:

• Enter-PSSession para crear una sesión interactiva.
• Invoke-Command para ejecutar uno o varios comandos o scripts.
• New-PSSession para generar sesiones persistentes reutilizables.
• Copy-Item combinado con sesiones para mover archivos entre el host y la VM.

En lugar de usar el nombre de equipo de red, con PowerShell Direct se trabaja con -VMName o -VMId, que hacen referencia al nombre de la máquina virtual en Hyper-V o a su identificador único (GUID). Para localizarlos rápidamente puedes usar:

Get-VM | Select Name, Id

A partir de ahí, cualquier comando de remoting que soporte estos parámetros puede abrir una sesión directamente contra la VM, siempre que se cumplan las condiciones de versión y permisos que hemos comentado.

Crear y cerrar una sesión interactiva con Enter-PSSession

La forma más cómoda de empezar a trabajar con PowerShell Direct suele ser establecer una sesión interactiva, donde todo lo que tecleas en la consola del host se ejecuta como si estuvieras dentro de una ventana de PowerShell en la propia VM.

El primer paso es abrir una consola de PowerShell en el host Hyper-V ejecutándola como administrador. Desde ahí, puedes iniciar la sesión de varias maneras, por ejemplo usando el nombre de la VM:

Enter-PSSession -VMName "NombreDeLaVM" -Credential (Get-Credential)

Si lo prefieres, puedes emplear el GUID de la máquina virtual que obtienes con Get-VM, usando el parámetro -VMId en lugar de -VMName:

Enter-PSSession -VMId <VMId> -Credential (Get-Credential)

Al lanzar cualquiera de estos comandos, PowerShell te pedirá las credenciales del sistema invitado. Introduce usuario y contraseña de una cuenta válida dentro de la VM y, si todo está correcto, verás que el prompt cambia, mostrando el nombre de la máquina virtual como prefijo, algo similar a:

: PS C:\>

A partir de ese momento, todo lo que ejecutes se lleva a cabo dentro de la máquina virtual. Puedes hacer pruebas sencillas como lanzar hostname o ipconfig para comprobar que realmente estás dentro del entorno invitado y no en el host.

Cuando hayas terminado, basta con cerrar la sesión interactiva usando el cmdlet Exit-PSSession. Con esto vuelves al prompt del host y se cierra la conexión PowerShell Direct con la VM.

Ejecutar comandos o scripts puntuales con Invoke-Command

En muchos escenarios no necesitas abrir una sesión interactiva prolongada, sino simplemente lanzar uno o varios comandos y recoger la salida. Para eso, Invoke-Command es la opción más flexible trabajando con PowerShell Direct.

Si quieres ejecutar un único comando en una máquina virtual sin mantener la sesión abierta, puedes hacerlo desde el host así:

Invoke-Command -VMName "NombreDeLaVM" -ScriptBlock { Get-Process }

O bien utilizando el identificador de la VM, si prefieres trabajar con el GUID que muestra Hyper-V:

Invoke-Command -VMId <VMId> -ScriptBlock { Get-Process }

En ambos casos, PowerShell te solicitará las credenciales de la máquina virtual si aún no tienes una sesión establecida. Una vez autenticado, el comando se ejecuta dentro de la VM y la salida se muestra en la consola del host. Cuando termina, la conexión se cierra automáticamente.

Si en lugar de un comando suelto quieres ejecutar un script completo que resides en el host, puedes referenciarlo con el parámetro -FilePath de Invoke-Command. El script se envía y se lanza dentro de la máquina virtual:

Invoke-Command -VMName "NombreDeLaVM" -FilePath C:\host\scripts\config.ps1

También puedes usar la variante basada en el Id de la VM, manteniendo la misma idea: el fichero está en el host, pero se ejecuta dentro del invitado, lo que simplifica mucho las tareas de configuración automatizada en laboratorios y entornos de pruebas.

Usar sesiones persistentes y copiar archivos con New-PSSession y Copy-Item

Además de las sesiones interactivas o de los comandos puntuales, PowerShell Direct brilla cuando se combina con sesiones persistentes creadas mediante New-PSSession. Estas sesiones permanecen en segundo plano y pueden reutilizarse cuantas veces necesites, conservando estado y variables entre invocaciones.

Para crear una sesión persistente hacia una máquina virtual usando PowerShell Direct, puedes hacer algo tan sencillo como:

$s = New-PSSession -VMName "NombreDeLaVM" -Credential (Get-Credential)

Si trabajas con el GUID, cambiarías el parámetro a -VMId y mantendrías el resto igual, guardando la sesión resultante en una variable para poder referenciarla después en otros cmdlets:

$s = New-PSSession -VMId <VMId> -Credential (Get-Credential)

Una vez que tienes la sesión creada, puedes reutilizarla con Invoke-Command, Enter-PSSession o, muy interesante, para transferir archivos usando Copy-Item, sin necesidad de compartir carpetas de red ni montar ISOs o discos adicionales.

Por ejemplo, para copiar un archivo desde el host hacia la máquina virtual, usarías el parámetro -ToSession apuntando a la sesión que creaste previamente:

Copy-Item -ToSession $s -Path C:\host_path\data.txt -Destination C:\guest_path\

Del mismo modo, si quieres traer un archivo desde la VM al host, usarías la variante -FromSession de Copy-Item, especificando la ruta de origen en la máquina invitada y la carpeta de destino en el host:

Copy-Item -FromSession $s -Path C:\guest_path\data.txt -Destination C:\host_path\

Cuando ya no necesites seguir utilizando esa sesión persistente, es buena práctica cerrarla con Remove-PSSession para liberar recursos tanto en el host como en el sistema operativo invitado:

Remove-PSSession $s

Ventajas reales de usar PowerShell Direct en el día a día

Más allá de la teoría, donde PowerShell Direct marca la diferencia es en escenarios de administración y laboratorio que suelen ser delicados por culpa de la red. Si te dedicas a montar POCs, demos, entornos de pruebas o formación, sabes lo pesado que puede ser depender constantemente de la conectividad.

Uno de los casos típicos es cuando estás ajustando configuraciones de red dentro de la VM y, por un error en una IP, una VLAN o una ruta, pierdes el acceso remoto. Antes te tocaba abrir la consola de Hyper-V y arreglarlo a mano. Ahora, mientras el sistema operativo siga arrancando bien, puedes conectarte con PowerShell Direct y corregir la configuración sin necesidad de que la VM tenga red operativa.

Algo parecido pasa cuando aplicas políticas de dominio que cambian reglas de firewall o ajustes de seguridad. Un GPO mal afinado podía dejarte sin PowerShell Remoting clásico. Con esta característica, sigues teniendo una vía directa al sistema invitado para revisar qué política ha roto qué cosa y revertirlo.

También resulta especialmente cómodo para automatizar instalaciones y primeros arranques de máquinas virtuales, evitando trucos como RunOnce o scripts pegados en el sysprep. Puedes preparar tus scripts de configuración en el host y lanzarlos en cuanto la VM esté encendida, sin tener que depender de que obtenga IP o resuelva nombres.

Desde el punto de vista de los proveedores de servicios y entornos de nube basados en Hyper-V, PowerShell Direct está claramente pensado para simplificar la gestión masiva de VMs. Permite a los administradores mantener un canal de administración incluso en redes aisladas o muy segmentadas, haciéndolo ideal para entornos multi-tenant o con fuertes requisitos de seguridad.

Mensajes de error habituales y cómo diagnosticarlos

Como cualquier tecnología, PowerShell Direct no está libre de problemas. Hay una serie de mensajes de error bastante frecuentes que merece la pena conocer para poder reaccionar rápido cuando aparezcan.

Uno de los más comunes es que los cmdlets Enter-PSSession, Invoke-Command o New-PSSession no muestren los parámetros -VMName o -VMId. Si te pasa esto, lo más probable es que tu sistema operativo host no soporte esta característica, porque estás en una versión anterior de Windows que aún no la incorporaba.

Para comprobar la versión de Windows en el host puedes utilizar en PowerShell el siguiente comando, que muestra el número de compilación del sistema:

::OSVersion.Version

También es importante confirmar que la versión de PowerShell sea 5 o superior, ya que PowerShell Direct y funcionalidades relacionadas como JEA requieren al menos esa versión principal. Puedes verificarlo con:

$PSVersionTable.PSVersion

Otro error típico es el mensaje indicando que “se ha producido un error que PowerShell no puede controlar. Es posible que una sesión remota haya finalizado” al usar Enter-PSSession o New-PSSession contra una VM. Este problema suele deberse a que la máquina virtual existe pero no está en ejecución, o a que el sistema invitado no soporta PowerShell Direct porque no cumple los requisitos de versión.

En otras ocasiones, el fallo se debe a que PowerShell aún no está disponible dentro de la VM porque el sistema operativo sigue arrancando, tiene algún error crítico de inicio o está esperando alguna entrada de usuario en la consola. Para comprobar rápidamente qué VMs están en ejecución en el host puedes usar:

Get-VM

Hay un caso particular donde se produce el mismo mensaje de error con New-PSSession debido a un bug que obliga a pasar siempre credenciales con -Credential. Cuando esto ocurre, el servicio relacionado con las sesiones de VM dentro del invitado puede quedarse bloqueado y es necesario reiniciarlo desde dentro de la propia máquina.

Para solventar esa situación, entra en la VM con VMConnect, abre PowerShell y reinicia el servicio vmicvmsession con este comando:

Restart-Service -Name vmicvmsession

Otro mensaje que aparece con cierta frecuencia es que “el conjunto de parámetros no puede resolverse” al intentar usar Enter-PSSession con opciones que no son compatibles con máquinas virtuales, como el parámetro -RunAsAdministrator, que sí se aplica en el caso de contenedores de Windows, pero no en VMs.

En el contexto de PowerShell Direct, debes evitar usar -RunAsAdministrator al conectarte a máquinas virtuales y, en su lugar, proporcionar explícitamente las credenciales de una cuenta con permisos de administrador en el sistema invitado, bien con -Credential o bien introduciéndolas cuando PowerShell lo pida por pantalla.

Por último, es bastante común encontrarse con errores del tipo “las credenciales no son válidas” o mensajes que indican que el parámetro VMName no coincide con ninguna máquina virtual. En el primer caso, revisa que el usuario y la contraseña existan y sean correctos dentro de la VM, y que la cuenta de administrador local no esté deshabilitada si estás intentando conectarte con ella.

En el segundo caso, suele significar que la VM no existe en el host o que tu usuario no es administrador de Hyper-V. De nuevo, puedes usar Get-VM para ver el listado de máquinas virtuales disponibles y comprobar si tus credenciales tienen la función de administrador de Hyper-V necesaria.

Buenas prácticas y usos avanzados con PowerShell Direct

Una vez que dominas los conceptos básicos, es fácil sacarle mucho más partido a PowerShell Direct combinándolo con scripts de automatización, JEA y sesiones compartidas en entornos de administración delegada.

Por ejemplo, puedes definir funciones que abstraigan la lógica repetitiva de conexión a VMs por -VMName o -VMId, de forma que tus scripts orquesten cambios en múltiples máquinas virtuales sin que tengas que repetir una y otra vez el mismo bloque de código para autenticación y selección de VM.

También puedes integrarlo con Administración Just Enough Administration (JEA) para exponer a otros operadores un conjunto muy limitado de comandos que se pueden lanzar contra las máquinas virtuales, manteniendo un alto nivel de seguridad pero sin renunciar a la comodidad de usar el canal directo de Hyper-V.

En escenarios más complejos, es habitual utilizar sesiones persistentes New-PSSession hacia varias VMs en paralelo, guardando cada sesión en una variable, y luego invocar comandos coordinados usando Invoke-Command sobre varias sesiones a la vez. De este modo puedes desplegar configuraciones simultáneas sin necesidad de abrir conexiones de red tradicionales.

PowerShell Direct también resulta muy práctico cuando necesitas copiar grandes ficheros ISO, instaladores o paquetes de configuración hacia VMs que no tienen acceso de red a los repositorios habituales. Al usar Copy-Item con -ToSession y -FromSession, sorteas la dependencia de SMB, HTTP o cualquier otro protocolo de transporte clásico.

En definitiva, se trata de una herramienta que, usada con cabeza, simplifica muchísimo la administración de entornos Hyper-V, reduce el tiempo perdido en tareas repetitivas y te da mucha más flexibilidad cuando algo se tuerce en la capa de red o en las políticas de seguridad.

PowerShell Direct se ha consolidado como una pieza clave en la caja de herramientas de cualquiera que administre Hyper-V, porque ofrece un canal de gestión fiable incluso en las peores condiciones de red, permite ejecutar comandos y scripts directamente dentro de las VMs, facilita la transferencia de archivos y aporta un plus importante de agilidad en entornos de laboratorio, producción y nube privada.