Archivo del blog

09 octubre 2026

Petete ya está en marcha: instalando Ollama sobre Proxmox con iGPU Intel

La instalación de Petete ha ido sorprendentemente bien. Que ya es decir, ahora  me ha tocado sudar lo que no está escrito para que me funcione con mi Proxmox, y no es por otra cosa que "sus bajos recursos" para lanzar una IA.

La base del proyecto es un contenedor LXC en Proxmox utilizando una imagen de Ubuntu. Una vez desplegado, le hemos asignado recursos sin demasiada compasión, actualizado todos los paquetes y preparado el terreno para empezar a jugar con la IA local.


Pero antes; ¿Qué es Ollama y para qué sirve?

Ollama permite ejecutar modelos de inteligencia artificial directamente en tu ordenador o servidor, sin depender de plataformas externas ni enviar tus conversaciones a servicios en la nube.

Con él puedes descargar y ejecutar modelos como Llama, Qwen, Gemma o DeepSeek, además de integrarlos en otras aplicaciones mediante una API. Si quieres una interfaz gráfica, puedes combinarlo con Open WebUI y tener tu propio asistente de IA accesible desde el navegador.

Lo mejor es que puedes montarlo en tu propio servidor Linux, controlar qué modelos utilizas y experimentar con inteligencia artificial en tu homelab sin necesidad de contratar servicios de pago.

Pero recuerda: El rendimiento dependerá del hardware y de la memoria disponibles.


Primer paso: instalar Ollama


La instalación es tan sencilla como ejecutar un comando por terminal, pero antes necesitamos tener instalado zstd, que es un algoritmo de compresión de datos, como ZIP o GZIP.

Así que primero vamos a instalarlo:

    sudo apt install zstd -y

Y con el zstd --version comprobamos que está


La instalación es tan sencilla como ejecutar:

    curl -fsSL https://ollama.com/install.sh | sh


Una vez completada la instalación, aprovechamos para instalar también el cliente SSH y dejar el entorno listo para trabajar cómodamente desde cualquier terminal.

Y con eso, primer objetivo cumplido: Ollama ya está instalado



Intentando aprovechar la iGPU

Como el equipo dispone de gráfica integrada Intel, la idea era intentar exprimirla para acelerar la ejecución de los modelos, ya que no tenemos una gráfica Nvidia ni una AMD.... así que vamos  a intentar aprovecharla.

Lo primero fue detener el servicio de Ollama y lanzarlo manualmente utilizando Vulkan:


Una vez parado ponemos:

    OLLAMA_VULKAN=1 ollama serve

El resultado fue prometedor: Ollama detectaba la GPU, sabía que existía... pero prácticamente la ignoraba por tratarse de una iGPU. Vamos, que la veía pero no quería salir con ella...


Forzando el uso de la gráfica integrada

Para convencer a Ollama de que la iGPU también merece amor, editamos el servicio:

    nano /etc/systemd/system/ollama.service

Y añadimos las siguientes líneas extras:

Environment="OLLAMA_VULKAN=1" 
Environment="OLLAMA_IGPU_ENABLE=1"


Tras reiniciar el servicio parecía que todo iba a funcionar... pero no. La GPU seguía resistiéndose.


El problema real: permisos


Después de varias pruebas, descubrimos que el verdadero problema no estaba en Vulkan ni en Ollama, sino en los permisos.

El usuario que ejecuta Ollama no pertenecía al grupo con acceso a los dispositivos gráficos, por lo que la aplicación simplemente no podía utilizarlos, así que un pequeño ajuste en los grupos del sistema, reinicio correspondiente y... ahora sí. Ollama podía acceder correctamente a la iGPU.



Y comprobamos que ahora el grupo ollama tiene acceso:


Primera prueba de fuego

Con todo funcionando, llegó el momento más satisfactorio de cualquier instalación: descargar el primer modelo.

Como estamos trabajando en un equipo modesto y sin una gráfica dedicada potente, la descarga y preparación inicial requiere algo de paciencia. Aproximadamente cinco minutos de espera para el primer arranque.

Nada dramático. Tiempo suficiente para un café y para pensar en la siguiente locura que vamos a intentar automatizar



Conclusiones


La instalación de Ollama sobre Proxmox ha resultado mucho más sencilla de lo esperado. La parte más delicada ha sido conseguir que la gráfica integrada Intel fuese realmente utilizable, pero una vez resuelto el tema de permisos, todo ha quedado funcionando correctamente.


Petete ya está vivo.



Porque, seamos sinceros, la inteligencia artificial está muy bien para generar imágenes espectaculares, escribir poemas o discutir sobre filosofía. Pero su verdadera prueba de fuego será evitar que vuelva a descubrir a las dos de la madrugada que el almacenamiento está al 100% y media infraestructura ha decidido declararse en huelga. Esa será su primera tarea. Y probablemente la más importante. 😅






19 septiembre 2026

Montando un controlador de dominio con Windows Server Core 2019 en Proxmox

Cuando monté mi laboratorio con Proxmox tenía una idea bastante clara: quería aprender, probar cosas y montar servicios que realmente me resultasen útiles.

Lo que no tenía tan claro era que, con el tiempo, ese pequeño servidor iba a acabar haciendo de todo.

Máquinas virtuales, contenedores, servicios, pruebas, Windows, Linux, Ansible… y cada vez que se me ocurre una idea nueva, hay que buscarle un hueco.

Mi Proxmox empieza estar al borde de un ataque de nervios. 😂

Y precisamente por eso, cuando llegó el momento de montar un controlador de dominio para el laboratorio, tenía claro que no quería añadir otro Windows Server con escritorio gráfico que estuviese consumiendo recursos simplemente para enseñarme un menú de inicio.

Así que decidí probar Windows Server Core 2019.

Sin escritorio.
Sin ventanas.
Sin menú de inicio.

Solo lo necesario para que el servidor haga su trabajo.

En este artículo vamos a instalar Windows Server Core 2019 en Proxmox y dejarlo preparado para convertirlo en el controlador de dominio de nuestro laboratorio.

Y aunque al principio pueda parecer un poco raro encontrarse con Windows y no tener dónde hacer clic, precisamente ahí está la gracia, y sobre todo para no caer en la tentación de usarlo para todo.

Porque si vamos a montar un laboratorio para aprender administración de sistemas, quizá también haya llegado el momento de dejar de darle al botón Siguiente, siguiente, siguiente. 😄

Así que vamos complicando este laboratorio poco a poco hasta que Proxmox pida la jubilación...

Paso 1 - Configuración inicial de Server Core

Antes de meternos en faena, quiero compartir un par de ideas que tuve cuando decidí montar este servidor.

  • La primera es que Server Core no está pensado para ser un Windows de escritorio sin escritorio. 😄 Su objetivo es precisamente reducir al mínimo todo aquello que no sea necesario para que el servidor cumpla su función.
  • La segunda es que, aunque al principio resulte extraño, administrar un servidor sin interfaz gráfica es una buena oportunidad para aprender otras formas de trabajar con Windows y, de paso, entender un poco mejor qué ocurre detrás de todos esos botones a los que estamos acostumbrados.

Dicho esto, vamos al lío.

A partir de aquí, la instalación es prácticamente la habitual de Windows Server: seleccionamos la edición Server Core, aceptamos la licencia, elegimos el disco de instalación y dejamos que Windows haga su trabajo.

reinicia, aparece una ventana negra... y ahí se acaba el Windows al que estamos acostumbrados😄

Bienvenidos a Server Core.

Cuando arranca por primera vez, nos pedirá la contraseña:



Una vez identificados, ponemos "sconfig" y le damos a intro.



Prácticamente vas a vivir aquí durante los primeros minutos de vida de nuestro servidor, ya que todo se gestiona con este menú:



1. Cambiar el nombre del servidor

Lo primero de todo vamos a cambiar el nombre, nada de WIN-4F7G8H2K9P; Vamos a ponerle algo que tenga sentido.

Por ejemplo: DC01 o el nombre que más prefieras para identificar al DC.

Entramos en sconfig, y escogemos la opción "(2) Nombre de equipo:" que es cambiar el nombre del equipo:



y escribimos el nombre que deseamos, en mi caso he puesto "ADCore1" y reiniciamos tras completar el cambio de nombre.



2. Configurar IP fija


Un controlador de dominio jamás debería depender de DHCP, más que nada para no tener sustos.

Por ejemplo, pondremos los siguientes datos:

  • IP: 192.168.1.98
  • Mascara: 255.255.255.0
  • Gateway: 192.168.1.1

Desde la opción de red: (8) Network settings



Pulsamos luego en 1 y definimos nuestra configuración, en 1 porque solo tenemos una tarjeta de red:



Si seguimos las opciones, configuramos nuestra red del servidor, tras tenerlo configurado, reiniciaremos también:



* Con la opción 13, reiniciamos el equipo:



3. Configurar DNS


Ahora nos toca configurar los DNS, pondremos la IP del servidor como primario, Sí, a sí mismo, ya que cuando promocionemos a DC será también el servidor DNS y tendremos dos pájaros de un tiro.

En mi laboratorio he configurado temporalmente otro servidor DNS adicional basado en Pi-hole para determinadas pruebas.



4. Actualizar el servidor


Vale, y antes de continuar con la configuración, vamos a actualizar el Windows a tope, yo en mi caso he utilizado una MV, pero si usas un hierro, mira también de ponerle los últimos drivers al equipo.
  1. sconfig
  2. Pulsamos en la opción "(6) Download and Install Updates"



Pulsamos sobre la opción "a" de todas, y dejamos que se ponga al día nuestro Windows:



Y aprovecharía para tomar un café, ya que es posible que tarde un poquito en completarse.

5. Configurar la zona horaria


Parece una tontería, algo muy simple, hasta que Kerberos deja de funcionar, o los del Helpdesk no pueden planchar equipos porque la hora no esta correcta, las contraseñas caducan antes de tiempo, etc
He visto de todo por culpa de esto.

Para comprobarlo, abrimos un powershell y ponemos:

Get-Date y Get-TimeZone





Si la VM arranca con una fecha rara o con la zona horario de las China popular, ahora es el momento de arreglarlo.

6. Activar administración remota


Volvemos a entrar en "sconfig" y vamos habilitar la administración remota, que es lo que más nos interesa:



Escogeremos la opción (1) que es la más segura:



Aunque todavía no vamos a utilizar Ansible, es un buen momento para dejar preparado WinRM. Más adelante lo necesitaremos para administrar el servidor de forma remota desde PowerShell, Windows Admin Center o Ansible.

Y ahora podemos proceder a promover el DC sin problema.

Promover el DC.

Instalar el rol de Active Directory

Comprobar los roles disponibles con el comando: Get-WindowsFeature AD*


Y ahora vamos a instalar el rol AD DS con el comando:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools



Y ahora revisamos que ya lo tenemos instalado:


Si vienes de una instalación con interfaz gráfica, es fácil pensar que existe una opción en sconfig para promocionar el servidor. Sin embargo, la instalación de Active Directory en Server Core se realiza mediante PowerShell, algo que encaja perfectamente con la filosofía de este tipo de despliegues.

Así que nos toca aparcarlo por ahora y continuar con nuestro "amigo" el PowerShell

Ahora vamos a promoverlo con el comando: 

Install-ADDSForest -DomainName "lab.justohorrillo.local"


Recuerda que Durante el asistente te pedirá que pongas la contraseña SafeModeAdministratorPassword, la contraseña DSRM (Directory Services Restore Mode) que es una contraseña especial del controlador de dominio. 

Piensa en ella como el "modo recuperación" de Active Directory.

Piensa que tardará unos minutos en volver a estar disponible. Es un momento perfecto para ese segundo café del día. ☕☕☕☕


Tras acabar la configuración se va a reiniciar, entramos en el equipo y ponemos en powershell:

(Get-WmiObject Win32_ComputerSystem).Domain

Nos devolverá la siguiente información:


Otra comprobación interesante consiste en ejecutar los comandos Get-ADDomain y dcdiag. Ambos nos permitirán verificar que Active Directory, DNS y el resto de servicios asociados funcionan correctamente antes de continuar ampliando el laboratorio.


Montar un controlador de dominio sobre Server Core ha sido una excelente forma de salir de la zona de confort. Más allá de reducir el consumo de recursos del laboratorio, obliga a entender mejor cómo funciona Windows Server y a apoyarse en herramientas como PowerShell o incluso el famoso Windows Admin Cente desde un SAW, en lugar de depender siempre de la interfaz gráfica.

Y esto no ha hecho más que empezar. Este servidor será la base sobre la que crecerá el laboratorio con nuevos clientes, automatización y algún que otro experimento. Pero eso lo veremos en próximos artículos... siempre que Proxmox no pida la jubilación antes. 😄

25 agosto 2026

Ansible: Poniendo orden en mi laboratorio Proxmox

Automatiza la gestión de tus máquinas virtuales y contenedores sin esfuerzo.

Tengo ya cómo unas diez máquinas Linux funcionando en Proxmox: Debian, Ubuntu y Alpine, cada una haciendo sus tareas diarias. Además, un Windows 11 y un Windows Server Core 2019 para las pruebas de SSCM y Azure que estoy haciendo.

Al principio no supone demasiado trabajo mantenerlas. Pero cuando empiezas a tener varias máquinas, repetir las mismas tareas una y otra vez empieza a ser bastante aburrido. Y aburrido, en este oficio, significa peligroso (porque acabas haciendo las cosas a lo loco).

Así que decidí probar Ansible. Y este es el manual de cómo lo estoy montando, con sus fallos y sus soluciones.


¿Qué quiero conseguir? 

La idea no es montar una infraestructura empresarial ni complicarnos la vida, eso ya lo hacemos en el trabajo. Quiero poder administrar mi laboratorio desde un único sitio. Nada más. Y nada menos.

 

Tabla de objetivos (con su estado real):

ObjetivoEstado
Comprobar que todas las máquinas están disponibles✅ Hecho
Actualizar Debian y Ubuntu (apt)✅ Hecho
Actualizar Alpine (apk)✅ Hecho
Gestionar servicios (start/stop/restart)🔄 En progreso
Instalar software🔄 En progreso
Crear usuarios🔄 En progreso
Ejecutar comandos remotos✅ Hecho
Automatizar tareas repetitivas🔄 En progreso
Actualizar Windows⏳ Pendiente (requiere WinRM)
Registrar qué ha ocurrido (logs)🔄 En progreso


Mi laboratorio

Para este manual voy a utilizar un escenario bastante parecido al que podemos encontrar en un laboratorio doméstico o de pruebas:

                         PROXMOX
                            │
             ┌──────────────┴──────────────┐
             │                             │
       ANSIBLE CONTROLLER              OTRAS VM/LXC
          Debian Linux                     │
             │                             │
      ┌──────┼────────┬─────────┐          │
      │      │        │         │          │
    Debian  Ubuntu  Alpine    Debian     Windows
      │      │        │         │        ┌───┴────┐
      │      │        │         │        │        │
     VM/LXC VM/LXC  VM/LXC    VM/LXC    Win11  WServerCore2019

No hace falta que todas las máquinas sean iguales para que esto funcione, de hecho, esa es precisamente la gracia. Tenemos diferentes distribuciones, diferentes servicios y también Windows.


¿Por qué necesito Ansible?

Imaginemos que quiero actualizar todos mis Debian y Ubuntu.

Sin Ansible:

SSH → Debian 1 → apt update &&  apt full-upgrade -y
SSH → Debian 2 → apt update &&  apt full-upgrade -y
SSH → Ubuntu 1 → apt update &&  apt full-upgrade -y
SSH → Debian 3 → apt update &&  apt full-upgrade -y
...

Y si tengo diez máquinas, acabamos haciendo lo mismo diez veces.

Con Ansible:

ansible servidores -m apt -a "update_cache=yes"

Y Ansible se encarga del resto.

Una orden. Todas las máquinas. Más tiempo para mí.


Pero tengo Alpine...

Aquí aparece una situación interesante de nuestro laboratorio.

Alpine Linux utiliza apk, mientras que Debian y Ubuntu utilizan apt.

No podemos tratar todas las máquinas exactamente igual.

Podemos organizar el inventario:

[debian]
debian01
debian02
debian03

[ubuntu]
ubuntu01
ubuntu02

[alpine]
alpine01
alpine02

[windows]
windows11
servercore2019

Ahora podemos decidir qué hacer con cada grupo.

Por ejemplo:

Debian/Ubuntu → apt
Alpine        → apk
Windows       → WinRM

Y esto nos permite empezar a ver por qué Ansible resulta tan interesante cuando nuestro laboratorio empieza a crecer.


¿Y Windows?

También vamos a tocar Windows.

En nuestro laboratorio tenemos:

  • Windows 11 Pro
  • Windows Server Core 2019

Ansible puede administrar Windows, aunque la comunicación y algunas tareas son diferentes a Linux.

Esto nos permitirá ver algo bastante útil:

                    Ansible
                       │
          ┌────────────┴────────────┐
          │                         │
        Linux                     Windows
          │                         │
    ┌─────┼─────┐              ┌────┴─────┐
    │     │     │              │          │
  Debian Ubuntu Alpine        Win11   Server Core

Así que el manual no será simplemente:

"Instala Ansible y ejecuta ping".

La idea será llevarlo desde cero hasta utilizarlo realmente en un laboratorio heterogéneo.


El objetivo del manual

Al terminar tendremos algo parecido a esto:

                    ┌─────────────────┐
                    │    PROXMOX      │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │ Debian Ansible  │
                    │    Controller   │
                    └────────┬────────┘
                             │
             ┌───────────────┼────────────────┐
             │               │                │
             ▼               ▼                ▼
          Linux           Linux           Windows
        Debian/Ubuntu     Alpine          Win11
                                          Server 2019

Y desde nuestro Debian podremos hacer cosas como:

Actualizar servidores

ansible linux -m ...

Comprobar máquinas

ansible all -m ping

Instalar paquetes

ansible debian -m ...

Gestionar servicios

ansible linux -m ...

Y, sobre todo, empezar a crear Playbooks, que serán los que realmente nos permitirán automatizar nuestro laboratorio.

Lo primero: instalar Ansible en el nodo controlador

Un solo nodo Debian será el “jefe” que habla con todos los demás.

Requisitos previos:

  • Un Debian 12 recién instalado (o cualquiera que tengas).
  • Acceso por SSH a todas las máquinas objetivo (con clave pública, no contraseña).
  • Python 3 (viene por defecto en Debian 12).

Instalación (en el nodo controlador):

# Actualiza el sistema
sudo apt update && sudo apt upgrade -y # Instala Ansible (desde los repos oficiales de Debian)
sudo apt install -y ansible # Verifica la instalación
ansible --versión # Verifica la versión de Phyton
python3 --version


🔑 Paso 2: Generar clave SSH para Ansible


Objetivo: Ansible se autentica sin contraseña hacia Debian/Ubuntu/Alpine y también más adelante hacia Windows (WinRM aparte).

Ahora en el controller, que en nuestro caso es en la MV Debian que tenemos en Proxmox, tenemos que ejecutar el código:


ssh-keygen -t ed25519 -b 4096 -C "ansible-controller" -f ~/.ssh/id_ed25519


    Te va a pedir passphrase: Pero lo dejamos en blanco para el laboratorio, aunque en producción tendrías que usar un usuario y contraseña segura.

📤 Paso 3: Copiar la clave pública a todas las VMs/LXC

Vamos por lo simple: ssh-copy-id

Asumiendo que el usuario destino en Linux es el mismo en todas (ej. debian/ubuntu/alpine), por ejemplo:

*NdelA: En un entorno de producción, el usuario no debe de ser nunca el "root" o Administrador en Windows por seguridad, en el lab, pues lo dejamos como queramos ;-)


ssh-copy-id -i ~/.ssh/id_ed25519.pub debian@debian01

ssh-copy-id -i ~/.ssh/id_ed25519.pub ubuntu@ubuntu01

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@alpine01

y así en todos los equipos que tengamos...


📌 Ojo: Revisa esto antes de empezar con el SSH.

Resulta que tenemos bloqueado el SSH con el usuario root, para habilitarlo tenemos que hacer esto:

nano /etc/ssh/sshd_config y descomentamos la línea: PasswordAuthentication y le ponemos un YES en vez de lo que tiene: 



Verás que en el Alpine, no viene configurado el Python3, viene bastante pelado por defecto, por lo que tendremos que instalarlo para que funcione:

apk update && apk add python3


Luego hacemos un python3 --version para ver si lo tenemos instalado:


🗂️ Paso 5: Inventario Ansible (para que luego todo encaje)

Ahora vamos a crear un inventario sencillo, por ejemplo:

Vamos a crear una carpeta ~/ansible-lab y dentro hacemos el fichero: inventory.ini con los nodos.



y creamos el fichero inventory.ini



Y lo probamos:

ansible pihole -i inventory.ini -m ping


Nos aparece un hermoso Warning, no te alarmes, es un aviso de Ansible sobre el descubrimiento automático de Python.
Mientras vemos que tenemos un pong, nos alegra ver que funciona.

Si te molesta el warning dichoso como a mí, en el inventory.ini, tienes que añadir una línea
que indique explícitamente qué intérprete Python debe usar Ansible.

[linux:vars]
ansible_python_interpreter=/usr/bin/python3


Y con eso ya no nos sale el warning.

Ejecutamos el ansible linux -i inventory.ini -m setup -a 'filter=ansible_distribution'
y nos dice las máquinas que tenemos online:


Playbooks


Ahora vamos con los playbooks con lo que queremos que hagan:

Primer creamos una carpeta dentro en la misma altura donde teníamos creado el inventory.ini:


Y aquí empieza lo bueno: vamos a crear un único Playbook que:
Detecte el sistema operativo.
Use apt en Debian/Ubuntu.
Use apk en Alpine.
Actualice los paquetes.
Nos muestre claramente qué ha hecho.
No ejecute nada en Windows.


creamos nuestro primer yml, lo vamos a llamar update-linux.yml con el contenido:



y una vez creado vamos a ejecutarlo:

ansible-playbook -i inventory.ini playbooks/update-linux.yml


Y ya tenemos los equipos actualizados.

Y como guinda del pastel, creamos una tarea para que lo lance semanalmente

 

Y con esto tenemos ya un laboratorio Linux completamente gestionado desde Ansible.

Hemos aprendido a:

✅ Instalar Ansible en nuestro controlador Debian
✅ Configurar acceso SSH mediante claves
✅ Crear un inventario organizado por grupos
✅ Ejecutar comandos remotos
✅ Comprobar el estado de las máquinas
✅ Detectar distribuciones automáticamente
✅ Actualizar Debian, Ubuntu y Alpine desde un único Playbook

Todo ello desde una sola consola y sin necesidad de ir conectándonos máquina por máquina.


¿Y Windows?

Windows se ha quedado aparcado por ahora.

No porque Ansible no pueda gestionarlo, sino porque requiere una configuración adicional mediante WinRM, certificados, reglas de firewall y algunos ajustes que merece la pena explicar con calma para no volvernos locos a la primera prueba.

Además, quiero enseñarlo funcionando tanto contra Windows 11 como contra Windows Server Core 2019, que es donde realmente se pone interesante.

Pero si le dais cariño al post, prometo hacer una segunda vuelta.
De momento sigo de vacaciones, así que toca disfrutar un poco antes de volver a pelearme
con WinRM... 😄

Petete ya está en marcha: instalando Ollama sobre Proxmox con iGPU Intel

La instalación de Petete ha ido sorprendentemente bien. Que ya es decir, ahora  me ha tocado sudar lo que no está escrito para que me funcio...