"Después del juego es antes del juego"
Sepp Herberger

Mostrando entradas con la etiqueta virtualbox. Mostrar todas las entradas
Mostrando entradas con la etiqueta virtualbox. Mostrar todas las entradas

miércoles, 24 de abril de 2024

Puppet: regla para instalar VirtualBox completo en Ubuntu 22

Si queremos instalar VirtualBox al completo (VirtualBox, Guest Additions y Extension Pack) de forma automatizada mediante puppet en los equipos de nuestra red las reglas serían:
   ...
   package {"virtualbox": ensure => installed }
   ->
   package {"virtualbox-guest-additions-iso": ensure => installed }
   ->
   exec { "accept-virtualbox-license":
            command => "/bin/sh -c \"echo virtualbox-ext-pack virtualbox-ext-pack/license select true | sudo debconf-set-selections\""
   }
   ->
   package {"virtualbox-ext-pack" : ensure => installed }
   ....
La parte mas exótica es el "accept-virtualbox-license", que permite instalar luego el paquete virtualbox-ext-pack de forma automática sin preguntas al usuario. Si no se pone la instalación es interactiva (pregunta si aceptamos la licencia) y la regla puppet falla. De esta manera preparamos la respuesta a la pregunta antes de instalar el paquete.

Es de agradecer que ahora la instalación es mucho más sencilla que antaño, gracias a que en Ubuntu 22 se ha metido el paquete "virtualbox-ext-pack", que busca y descarga las Extension Pack adecuadas. Antes había que hacerlo todo a mano.

jueves, 28 de marzo de 2019

VirtualBoxing Windows (Parte IV)

1. Introducción.

Venimos de aquí:


Voy a darle otra vuelta de tuerca al asunto porque me he encontrado con la tarea de montar un aula con 15 máquinas virtuales con Windows 10.

Podría haber hecho la configuración completa en cada una de las máquinas a mano, pero he preferido escribir una tarea puppet que automatice todo lo posible los pasos descritos en los enlaces anteriores por dos motivos:
  1. Me da pereza repetir lo mismo n veces. Soy administrador de sistemas: pienso que mi tarea consiste en trabajar construyendo cosas divertidas que me evitan trabajar repitiendo cosas aburridas.
  2. Porque en Xubuntu 18 me he propuesto hacer todo lo que pueda desde puppet para facilitar cualquier nueva instalación y la migración futura a Xubuntu 22.

2. Tarea puppet.

La tarea puppet tiene esta estructura:
├── files
│   ├── 15-vbox.conf
│   ├── Oracle_VM_VirtualBox_Extension_Pack-5.2.18.vbox-extpack
│   ├── run_vbox
│   ├── vbox_permisos
│   ├── VirtualBox.xml
│   └── Win10.vbox
└── manifests
    └── init.pp
Siendo el init.pp:
# cat init.pp                                                                           

import "/etc/puppet/defines/*.pp"

class xubuntu18_virtualbox {

        #Deja todo preparado para arrancar una máquina virtual con run_vbox
        #Solo haria falta instalar el fichero con permisos 777 .vdi en la ruta /datos/VirtualBox VMs/VirtualBox/Win10-Choco-Autocad-Office.vdi. Si se cambia hay que editar los ficheros Virtualbox.xml y Win10.box

        package {"virtualbox": ensure => installed}

        package {"virtualbox-guest-additions-iso": ensure => installed }

        line { entorno_virtualbox:
                file => "/etc/environment",
                line => 'export VBOX_USER_HOME="/datos/VirtualBox VMs/VirtualBox"',
                ensure => present
        }

        $dirs = [ "/datos", "/datos/VirtualBox VMs","/datos/VirtualBox VMs/VirtualBox","/datos/VirtualBox VMs/VirtualBox/Win10","/datos/VirtualBox VMs/VirtualBox/Win10/Logs" ]

        file {$dirs:
                ensure => 'directory',
                owner  => 'root',
                group  => 'root',
                mode   => '0777',
                before => [File ["/datos/VirtualBox VMs/VirtualBox/VirtualBox.xml"], File ["/datos/VirtualBox VMs/VirtualBox/Win10/Win10.vbox"], File ["extpack"] ]
        }

        file { "/datos/VirtualBox VMs/VirtualBox/VirtualBox.xml":
                owner => root , group => root , mode => 644 ,
                source => "puppet:///modules/xubuntu18_virtualbox/VirtualBox.xml",
        }

        file { "/datos/VirtualBox VMs/VirtualBox/Win10/Win10.vbox":
                owner => root , group => root , mode => 644 ,
                source => "puppet:///modules/xubuntu18_virtualbox/Win10.vbox",
        }

        file { "extpack":
                path =>"/datos/VirtualBox VMs/VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-5.2.18.vbox-extpack",
                owner => root , group => root , mode => 644 ,
                source => "puppet:///modules/xubuntu18_virtualbox/Oracle_VM_VirtualBox_Extension_Pack-5.2.18.vbox-extpack",
                notify => Exec ["install_extpack"],
                }

        #El accept-license del extpack para instalacion desatendida se consigue instalando una vez a mano y cogiendo el código que nos muestra
        exec { "install_extpack":
                path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                command => 'vboxmanage extpack install --replace --accept-license=56be48f923303c8cababb0bb4c478284b688ed23f16d775d729b89a2e8e5f9eb "/datos/VirtualBox VMs/VirtualBox/Oracle_VM_VirtualBox_Extension_Pack-5.2.18.vbox-extpack"',              
                refreshonly => true,
        }


        #El fichero win.desktop para ir a /usr/share/applications se mete desde la tarea pupet xubuntu18_xfce4, junto con el icono. Aqui no lo haremos.

        file {"/usr/bin/run_vbox":
                owner => root , group => root , mode => 777 ,
                source => "puppet:///modules/xubuntu18_virtualbox/run_vbox"
        }

        file {"/usr/bin/vbox_permisos":
                owner => root , group => root , mode => 777 ,
                source => "puppet:///modules/xubuntu18_virtualbox/vbox_permisos"
        }


        case $uso {
                "infolab" : {
                        file {"/etc/lightdm/lightdm.conf.d/15-vbox.conf":
                                owner => root , group => root , mode => 644 ,
                                source => "puppet:///modules/xubuntu18_virtualbox/15-vbox.conf"
                        }
                }
                "siatic"  : {
                        line { permisos:
                                file => "/usr/lib/siatic/poweron.sh",
                                line => "/usr/bin/vbox_permisos",
                                ensure => present
                        }
                        #En las siatic el directorio /datos se monta sobre el disco duro secundario. En los infolabs va en el raiz, ya que hay espacio de sobra en él.
                        line { disco_secundario:
                                file => "/etc/fstab",
                                line => "/dev/sdb1 /datos ext4 rw,relatime,data=ordered 0 0",
                                ensure => present
                        }
                }
                default: { }
        }

}
Básicamente:
  • Instala los paquetes de virtualbox y su "extension pack" (en este caso la 5.2.18, habría que cambiarlo en función del tu Virtualbox).
  • Crea el árbol de directorios /datos/VirtualBox VMs/VirtualBox/Win10, se configura el entorno para que virtualbox trabaje con esos directorios y pone en ellos los ficheros que definen la máquina virtual de Windows 10. Estos 2 ficheros son VirtualBox.xml y Win10.vbox, extraídos de una configuración manual de un virtualbox donde se prepara todo. Aquí cada cual pondrá lo que necesite según su caso.
  • Se instalan los scripts run_vbox, que abrirá la máquina virtual, y vbox_permisos, que en el inicio de sesión configurará los permisos del usuario para hacer funcionar todo.
  • Si es necesario y en función de la máquina, configuramos en fstab la ruta /datos para que se monte sobre la partición de mayor tamaño.

Aquí está el enlace a la tarea puppet completa, con todos los ficheros excepto el .vdi, evidentemente.

La carpeta /datos tiene este contenido (en negrita los ficheros significativos, el resto son creados de forma automática):
datos
└── VirtualBox VMs
        └── VirtualBox
                ├── compreg.dat
                ├── Oracle_VM_VirtualBox_Extension_Pack-5.2.18.vbox-extpack
                ├── selectorwindow.log
                ├── selectorwindow.log.1
                ├── VBoxSVC.log
                ├── VBoxSVC.log.1
                ├── VBoxSVC.log.2
                ├── VBoxSVC.log.3
                ├── VBoxSVC.log.4
                ├── VBoxSVC.log.5
                ├── VBoxSVC.log.6
                ├── VBoxSVC.log.7
                ├── VirtualBox.xml
                ├── VirtualBox.xml-prev
                ├── Win10
                │   ├── Logs
                │   │   ├── VBox.log
                │   │   ├── VBox.log.1
                │   │   └── VBox.log.2
                │   ├── Win10.vbox
                │   └── Win10.vbox-prev
                ├── Win10-Original.vdi
                ├── Win10.vdi
                └── xpti.dat


El fichero Wind10.vdi es la imagen de disco .vdi con el sistema operativo, enlazada desde dentro de Win10.vbox. El fichero Win10-Original.vdi es una copia que hago cada vez que actualizo Win10.vdi, que queda como un fichero de backup por si se estropease la máquina original tener una copia funcional en poco tiempo.

3. Distribución rápida de imágenes vdi.

Los ficheros .vdi son basante pesados (en mi caso una imagen de 27Gb) y distribuirlos por la red entre diferentes máquinas cuando se añade algo y hay que actualizar en todos los puestos se hace interminable.

Para evitarlo lo mejor es que, si tenemos la opción, hagamos esta distribución usando udpcast, que nos permite copiar por multicast una imagen en 15, 20 o más puestos a casi la misma velocidad que si fuese a un único puesto.

La única condición es que todas las máquinas estén conectadas al mismo switch y esté esté configurado para permitir multicast (con IGM Snooping activado y con ciertos controles -dependientes del modelo del switch- para evitar tormentas de red desactivados). Si todo está bien, la transferencia se realizará hacia todas la máquinas receptoras a unos 80-90Mbps, lo cual nos permitirá distribuir la imagen completa en todo el aula en menos de una hora.

La forma de hacerlo es instalar el paquete udpcast en todas las máquinas y en la máquina emisora (que puede ser cualquier PC del aula) hacer:
# udp-sender --file "/datos/VirtualBox VMs/VirtualBox/Win10.vdi" --interface eno1 --min-receivers 15
Mandamos por la tarjeta de red "eno1" hacia 15 receptores.

En los receptores hacemos:
# udp-receiver --file "/datos/VirtualBox VMs/VirtualBox/Win10.vdi" --interface eno1
Como teclear este comando en todos y cada uno de los receptores es bastante aburrido, aconsejo fervientemente usar tmux-cssh recomendado por mi compañero Esteban para abrir una sesión ssh en todos los receptores y escribir/ejecutar en paralelo las órdenes en los 15 puestos. Una pequeña maravilla.

Una vez hecha la copia de la imagen .vdi no hay que olvidar hacer una copia de seguridad en cada máquina y dar permisos 777 a "Win10.vdi" para permitir su acceso desde cualquier usuario que inicie sesión.

Nota: en mi caso he tenido un problema con la transmisión multicast que hacia que la velocidad de copia se redujese a 2-3Mbps. El problema es que en el aula donde estaba trabajando tenía un punto wifi Dlink DIR-860L configurado además como enlace de red entre el emisor y los receptores. El punto wifi limitaba el tráfico sin que yo cayese en ello, y nos ha hecho perder tiempo a mí y a mi compañero David pensando que el problema estaba en el switch del aula. Ojo por tanto con cualquier dispositivo adicional de electrónica de red que pudiera haber el aula, ya que el tráfico multicast puede ser penalizado al pasar por él.

jueves, 22 de junio de 2017

Proxmox (V): importación de una máquina virtual preexistente / uso de SPICE.

Continuamos esta serie con otra cuestión que quería probar: en el centro tengo varias máquinas virtuales montadas para ser utilizadas de forma local mediante VirtualBox. Una de ellas es una máquina con Windows XP que ejecuta la vetusta aplicacion Geiwin-IES2000, usada para la gestión del alumnado del centro antes de la llegada de Rayuela. Durante la implantación de Rayuela hubo datos antiguos que se "olvidaron" de trasladar y es necesario tener esa aplicación de los 90 para consultar antiguos expedientes.

Hasta hora tenía una máquina virtual que arrancaban los PC de administración desde su Ubuntu cuando querían acceder a los datos. El problema es que tarda un rato en arrancar la máquina para una simple consulta y, por otro lado, tenerla siempre abierta consume recursos del PC local. Esta máquina es una firme candidata a ser exportada a Proxmox, para tenerla siempre encendida y poder conectar a ella de forma rápida cuando se requiera.

Partimos de un fichero .vdi con la imagen de la máquina virtual en VirtualBox (sería la imagen de un Windows XP que ya tengo preparado con Geiwin/IES2000 y alguna otra aplicación viejuna instalada y en funcionamiento) y el objetivo es llavarla a Proxmox. Existe documentación sobre ello, pero voy a contar los pasos que he dado por mi parte y los problemas que he ido encontrando. A grandes rasgos lo que haremos es:

  1. Convertir el fichero de imagen de disco .vdi con la máquina virtual en formato propio de VirtualBox en un fichero .img, con la imagen de disco en formato raw, que es el formato que necesita Proxmox al estar basado internamente en KVM.
  2. Crear la máquina Windows XP en Proxmox, especificando un disco duro en formato .raw alojado en storage->local (en lugar del habitual storage->local-lvm).
  3. Subir la imagen raw de disco al storage de Proxmox sobreescribendo la creada en el paso anterior.
  4. Arrancar y configurar la máquina con el hardware virtual propio de Proxmox.
  5. Configurar SPICE para permitir acceder a la máquina virtual desde un PC remoto de una forma rápida. La idea es verificar si Spice hace tan rápido y ligero el escritorio remoto como cuentan las crónicas.

Vayamos paso a paso.

0. Antes del inicio.

Antes de empezar por el primer paso de conversión del fichero .vdi hay que tomar precauciones para evitar tener un pantallazo azul típico de Windows en el paso nº 4. Como ya comenté en el blog hace siglos (apartado 3 de esta entrada), Windows XP lleva fatal que le cambies de hardware y se venga en forma de pantallazos al arrancar. Da igual que le cambies de una máquina física a otra usando una herramienta de clonado o de un modelo hipervisor para máquinas virtuales a otro, el Windows XP detecta un cambio de hardware y muestra su hermosa pantalla azul.

En nuestro caso vamos a pasar de VirtualBox a Proxmox/KVM y he podido confirmar que no defrauda: un BSOD al arrancar. En versiones modernas de Windows esto se ha ido paliando y es díficil encontrarnos con estas pantallas azules, pero recordemos que estamos tratando con un XP.

La causa de esto son los drivers de la controladora IDE del disco duro. Al arrancar en el nuevo hardware y ver que la controladora IDE ha cambiado no pone una genérica o intenta sortear el problema: da el pantallazo azul y te quedas ahí con cara de tonto. La solución pasa por, antes de mover el Windows XP, ejecutar un programa o script que instala los drivers IDE genéricos mas básicos. Al arrancar en el nuevo sistema no hay fallo e inmediatamente los cambia por unos drivers mas avanzados y adecuados al nuevo hardware.

La herramienta adecuada para esto es la ofrecida en la web de Proxmox llamada mergeide.zip, que encontramos aquí. La descargamos en la máquina virtual VirtualBox antes de copiar el fichero .vdi y la ejecutamos. Modificará el registro para establecer unos driver IDE genéricos. A continuación apagamos la máquina virtual y, sin encenderla de nuevo, convertimos el .vdi a .img según el paso siguiente.

1. Convertir de .vdi a .raw

Esta es sencilla: en la máquina física donde tenemos el VirtualBox ejecutamos:
# VBoxManage clonehd --format RAW Win.vdi Win.img
Siendo Win.vdi la imagen de disco duro origen e .img el disco destino. Tardará un rato en hacerse y generará una imagen .img más grande ya que la .vdi está siempre comprimida.

2. Crear en Proxmox la máquina virtual para Windows XP.

Creamos la máquina de la misma forma que hemos creado cualquier otra, indicando que es un Windows XP y dándole 1Gb de RAM, más que suficiente.



Aquí hay otro problema: el disco duro debe estar en Storage->local en lugar de en Storage->local-lvm. La causa de esto es que luego vamos a dar el cambiazo y sobreescribir la imagen Win.img del paso anterior sobre el disco duro creado por defecto durante la creación de la máquina virtual, de tal manera que el Windows XP ya configurado y preparado va a aparecer allí de golpe. Aquí se ve en el detalle:


Cuando la imagen de disco duro se crea en Storage->local-lvm, se guarda en un "limbo" (el volumen LVM) al cual no podemos acceder directamente para dar el cambiazo. En cambio si se crea en Storage->local, se guarda en la ruta proxmox:/var/lib/vz/imagenes/id-maquina/*.raw, lo cual hace fácil la sustitución de la imagen.

El problema está en que Proxmox por defecto no permite crear las imágenes de disco duro en Storage->local, solo permite crearlas en Storage->local-lvm. Podemos verlo en la siguiente captura realizada durante la creación de la máquina virtual:


Pero buscando un poco en Internet, aquí aparece la solución. El truco está en editar el fichero /etc/pve/storage.cfg y añadir la parte en negrita:

root@proxmox:~# cat /etc/pve/storage.cfg 
dir: local
 path /var/lib/vz
 content iso,vztmpl,backup,images

lvmthin: local-lvm
 thinpool data
 vgname pve
 content rootdir,images
root@proxmox:~# 

Con esto logramos poder crear el disco duro asi:


Con lo cual tendremos fichero .raw que representa la imagen del disco duro en la ruta var/lib/vz/images/id-vm/...

3. Subir la imagen y sobreescribirla.

Esta parte es sencilla, copiamos el fichero .img a la máquina con Proxmox:
# scp Win.img root@proxmox:/root
Y sobreescribimos el fichero ya dentro de Proxmox:
root@proxmox:~# cp /root/Win.img /var/lib/vz/images/102/vm-102-disk-1.raw
Ahora encendemos la máquina con el botón "Start VM" y hará una arranque correcto sin pantallazos azules. Desde "_Console" podremos ver su escritorio:


4. Arrancar y configurar la imagen con los drivers.

En el primer arranque, tras conectar mediante la consola y entrar como administrador del Windows XP veremos que se realiza una autodetección de hardware, debido a que la máquina KVM/Proxmox tiene sus propios dispositivos virtuales (al igual que las tienen las máquinas VirtualBox y Vmware, por ejemplo), para los cuales hay que instalar los drivers adecuados.

Como se ve en la siguiente captura del Administrador de Dispositivos una vez instalados los drivers adecuados, ahí están los dispositivos "Virtio" (serial, balloon y printer).


Para instalar los drivers descargamos la versión estable (a fecha de hoy, la 0.132, probé con otras mas actualizadas y me dieron problemas con Windows XP) de las Spice Guest Tools del enlace siguiente. Aquí está el enlace directo a dicho software.

También podemos bajarnos la imagen ISO con los "drivers Virtio" sueltos desde aquí.

Una vez descargadas las spice-guest-tools las instalamos, quedando así:


Si reiniciamos la máquina virtual ahora si detectará bien todo el hardware e instalará los drivers correctos, quedando como en la captura anterior: todo el hardware detectado sin símbolos de error o aviso.

Un vez hecho esto ya si podemos trabajar con Geiwin y su interfaz tan grunge:


Para que los usuarios rasos de la administración accedan a la máquina virtual y Geiwin hay varias opciones. La más sencilla es que el Windows virtualizado tenga habilitado el escritorio remoto y tenga una ip pública fija configurada en el servidor DHCP, como ya hicimos para Zentyal y RSAT en anteriores entradas. En ese caso los usuarios entrarán con un:
# rdesktop -u usuarioxp -p passwordxp -N -z -P -g 1024x768+0+0  ip-maquina-xp
Simplemente poniendo un acceso directo en el escritorio que ejecute el comando anterior conseguiremos entrar remotamente desde nuestro escritorio Linux.


Si queremos que puedan entrar varios usuarios a la vez no tenemos nada mas que habilitar el acceso concurrente mediante Remote Desktop.

La otra opción de acceso es que entren a través del navegador Web, usando la consola VNC de Proxmox. Evidentemente no les vamos a dar las credenciales del administrador del servidor, pero si podemos crear un usuario ad-hoc dentro del servidor que pueda conectar con la máquina virtual XP.

Para ello creamos un usuario propio de PVE según la siguiente captura:


y luego nos vamos a nuestra máquina virtual con XP y le damos permiso a dicho usuario para acceder a ella con el rol PVEVMUser, que significa que solo puede interactuar con la máquina virtual, pero no modificar su configuración ni la del Proxmox.


Los usuarios cargarán en su navegador la URL https://ip-proxmox:8006 y pondrán las credenciales del usuario limitado (ojo al seleccionar la validación contra Proxmox VE y no contra PAM en la lista desplegable "Realm") y tendrán una visión limitada del entorno, con la máquina accesible mediante la consola:



En ambos casos es interesante deshabilitar a los usuarios regulares la posibilidad de apagar la máquina virtual, que debe estar siempre encendida. Eso lo logro siguiendo estas instrucciones.

La tercera opción, que es usar SPICE, la veremos en el siguiente apartado.

5. Configurar acceso por Spice.

Desde que empecé a mirar esto de Proxmox y KVM he encontrado referencias a SPICE, que se define como un protocolo para conectar de forma remota con el escritorio de las máquinas virtuales a una velocidad que da impresión de ser un escritorio local. Según se dice, SPICE detecta de forma inteligente incluso areas de vídeo y las manda como un stream de vídeo. Copio el fragmento de aquí:
Video Compression

Spice uses loss-less compression for images sent to the client. However, video streams are handled differently. Spice server heuristically identifies video areas and sends them as a video stream coded using M-JPEG. This handling saves a lot of traffic, improving Spice performance, especially in a WAN environment. However, in some circumstances the heuristic behavior might cause low quality images (e.g. identifying updated text area as a video stream). Video streaming can be chosen on server initiation and dynamically at run-time.
Suena prometedor...¿verdad?. Hasta ahora los escritorios remotos que he probado (VNC, Remote Desktop, x2goclient) flaqueaban en el tema de la reproducción de vídeos, tanto de Youtube como por vlc. Tengo curiosidad por ver si SPICE resuelve esto.

Lo primero que debemos hacer es activar SPICE en la configuración de la tarjeta gráfica de la máquina virtual XP (hace falta tenerla detenida):


A continuación arrancamos la máquina XP y nos detecta un cambio en la tarjeta de vídeo, que pasa a identificar con Red Hat QXL GPU, activando el driver SPICE (ya instalado previamente con las Spice-guest-tools) para manejar de forma optimizada el escritorio remoto:


Ahora en la máquina local desde la que conectamos a Proxmox hay que instalar un "cliente SPICE" (que seria similar a un cliente VNC) para poder conectar. Hay clientes para Windows, Linux, Android, OSX, etc.

Como nuestra máquina es Ubuntu instalamos el cliente desde los repositorios con:
# apt-get install virt-viewer
Para acceder basta con abrir Proxmox, ir a la máquina virtual y abrir la lista asociada al botón "_Console", seleccionando la opción "SPICE". Esto descargará un fichero (una especie de "cookie de sesión") que al ejecutarse abrirá el visor remoto.



Al abrir el fichero descargado se ejecutará virt-viewer y tendremos una conexión de escritorio remoto (nótese que tiene un menú que nos permite cosas interesantes, como cambiar la resolución o enviar combinaciones de teclas especiales a la máquina remota):


Después de varias pruebas, incluyendo vídeos, puedo atestiguar que va mas rápido que cualquier escritorio remoto que haya visto antes. El vídeo se reproduce sin saltos y con calidad, como se ve en la captura, donde reproduzco a la vez vídeos de youtube y vlc con tanta fluidez como el QE de un Banco Central.


Si abrimos el administrador de tareas de Windows XP veremos que hay un par de procesos llamados vdagent.exe/vdservice.exe que se encargan de realizar la comunicación optimizada con el virt-viewer. Son los encargados de redirigir vídeo, ratón, teclado y otros dispositivos hardware entre máquina virtual y cliente remoto.

Conectar mediante el interfaz web puede ser un poco engorroso para un usuario raso. Existe la opción de entrar directamente usando un script que realmente simula mediante wget/curl las peticiones web. El script lo descargamos de aquí desde este epígrafe de la Wiki de Proxmox.

Una vez descargado el script, lo guardo con el nombre "spice" y permisos 755. Los parámetros del script son:
 Uso: spice [-u ] [-p ] vmid [node [proxy]]"

   -u username. Default root@pam
   -p password. Default ''
    
    vmid: id for VM
    node: Proxmox cluster node name
    proxy: DNS or IP (use  as default)
Para invocarlo en mi caso haré:
# ./spice -u usuario@pve -p password 102 proxmox64 172.X.Y.Z
Usando el usuario que creamos anteriormente (para permitir la entrada a proxmox de usuarios rasos), suponiendo que la máquina virtual tiene un id 102 y poniendo el nombre del cluster e IP del servidor Proxmox. Vemos como ahora se abre el virt-viewer con el escritorio remoto sin necesidad de utilizar la interfaz web de proxmox:


Como comenté con rdesktop, lo ideal es crear un acceso directo en el escritorio del usuario que ejecute el "/..../spice -u usuario@pve -p password 102 proxmox64 172.X.Y.Z".

Un tema que me quedo en el tintero de momento es que SPICE no solo exporta la parte gráfica del escritorio, también permite exportar el audio y los puertos USB, tal como se comenta aquí. Esta parte no me interesa ahora y la voy a quedar pendiente.

Ya que no son todo alegrías, hay que comentar un problema inesperado: al activar SPICE en la máquina virtual el ratón en el acceso VNC desde Console ya no funciona correctamente, está como descalibrado. No quedará otra opción que usar SPICE o rdesktop una vez activado SPICE en el hardware de la máquina.

Bueno, pues colorín&colorado, la primera temporada de esta serie se ha acabado. Me queda por explorar en un futuro: el tema del audio/usb en SPICE, el uso de del PCI Passthrough para acelerar aún mas el vídeo e indagar la posibilidad de establecer varias sesiones SPICE a la vez contra la misma máquina virtual.