velxio/backend
David Montero Crespo b7a191eaab feat(pi): techo de capacidad para los guests QEMU (multiusuario)
Cada guest es un proceso QEMU con su propia RAM (1-2 GB segun placa) y
sus hilos de vCPU, asi que el limite lo pone la maquina, no el codigo.
No habia ningun tope: el usuario N simplemente empujaba la caja a swap y
la sesion de TODOS se volvia lenta, que es peor que decirle al usuario N
que espere un minuto.

  VELXIO_PI_MAX_INSTANCES   (6)  guests simultaneos en la maquina
  VELXIO_PI_MAX_PER_OWNER   (2)  guests por persona

El "owner" es el hash de la cookie de sesion: sirve solo para contar, no
se guarda ni se lee de vuelta, y cae al host del cliente cuando no hay
cookie (sidecar de escritorio, tests). Sin identidad solo aplica el tope
global.

El rechazo llega como un mensaje que dice que hacer ("prueba en un
minuto" / "para una de tus sesiones"), no como un fallo mudo, y se
comprueba ANTES de lanzar el proceso.
2026-07-29 21:15:04 +02:00
..
app feat(pi): techo de capacidad para los guests QEMU (multiusuario) 2026-07-29 21:15:04 +02:00
board-indexes fix(docker): vendor drazzy.com board index + seed missing indexes at boot 2026-07-17 06:41:44 +02:00
scripts
sdk feat(chips): programmable retro CPU chips with external ROM 2026-05-18 23:38:18 -03:00
tests feat(pi): techo de capacidad para los guests QEMU (multiusuario) 2026-07-29 21:15:04 +02:00
.env.example
Dockerfile fix(docker): vendor drazzy.com board index + seed missing indexes at boot 2026-07-17 06:41:44 +02:00
debug_qemu.py
mcp_server.py
mcp_sse_server.py
requirements.txt