Pool de Recursos del Hipervisor PPN

La capa de hipervisor de la Red Privada PointSav (PPN) está diseñada para gestionar un pool de CPU y RAM por nodo, asignando dinámicamente esos recursos a través de las máquinas virtuales que ejecuta. Este sería el mecanismo por el cual la PPN otorgaría mayor o menor capacidad de cómputo a cada VM de Totebox Archive en respuesta a la demanda de carga de trabajo. Ninguno de los dos mecanismos descritos abajo está construido todavía — el código real de arranque de os-infrastructure es un stub Multiboot2 sin más (salida de texto por framebuffer y un escaneo mDNS de pares), sin lógica de pooling de recursos, y no existe código virtio_balloon ni cgroups v2 cpu.weight en ningún lugar del crate. Este artículo describe el diseño planificado.

Un pool por nodo físico

Cada nodo físico de PPN — una instancia GCP, un servidor en las instalaciones, una máquina arrendada — controla un pool limitado por su propio hardware. El pool no se comparte entre nodos. Un nodo con 31 GB de RAM gestiona 31 GB; no toma prestado de un nodo vecino.

La colocación de carga de trabajo entre nodos es una preocupación separada: la Capa de Orquestación de Totebox (gateway-orchestration-command-1) decide en qué nodo físico se ejecuta una instancia cluster-totebox, basándose en el emparejamiento MBA y las señales de capacidad disponible. Una vez tomada esa decisión, el hipervisor del nodo receptor gestiona el pool de recursos local para esa VM. El pool de PPN y el planificador de Totebox son ortogonales.

Pool de memoria: virtio_balloon (planificado)

El mecanismo principal de recuperación de memoria previsto es el dispositivo paravirtual virtio_balloon. Una vez construido, cada VM aprovisionada por os-infrastructure se iniciaría con un controlador de balloon, ejecutándose como un módulo estándar del kernel dentro del sistema operativo invitado.

Cómo funciona la inflación (recuperar memoria):

1. El hipervisor (controlador de balloon) señala al controlador de balloon que se inflate en N páginas.
2. El controlador asigna esas páginas dentro del invitado, eliminándolas del espacio de direcciones utilizables del invitado.
3. El hipervisor recupera esas páginas físicas para el pool a nivel de nodo.
4. El pool crece en N páginas; la RAM disponible del invitado disminuye en N páginas.

Cómo funciona la deflación (devolver memoria):

1. El hipervisor señala al controlador de balloon que se deflate.
2. El controlador libera las páginas del balloon de vuelta a la lista libre del invitado.
3. La RAM disponible del invitado crece; el pool disminuye.

El pool en cualquier instante:

pool_disponible = ram_física − Σ(balloon_mínimo en todas las VMs)

Cada VM tiene una reserva mínima de balloon por debajo de la cual el controlador no inflará. Esto evita que una VM sea privada de memoria cuando el nodo está bajo presión.

Pool de CPU: pesos de planificación de vCPU (planificado)

La gestión del pool de CPU está diseñada alrededor de la interfaz cpu.weight de cgroups v2 de Linux. Cada proceso QEMU (uno por VM) se colocaría en un cgroup con un peso tomado del ledger de capacidades. Bajo contención de CPU, el planificador distribuiría el tiempo de vCPU proporcionalmente a esos pesos; cuando el nodo no está bajo contención, todas las VMs correrían a máxima velocidad independientemente del peso.

Una VM cluster-totebox que ejecuta una carga de trabajo de inferencia activa (a través de service-slm) podría recibir un peso más alto que una VM de archivo inactiva. La entrada del ledger sería el peso autoritativo, aplicado por os-infrastructure en el lanzamiento de la VM y ajustable en vivo — una vez construido este mecanismo.

Relación con os-orchestration

os-orchestration es un agregador de capa de datos. Está diseñado para agregar acceso a datos a través de Totebox Archives mediante consultas basadas en capacidades que devuelven solo filas de resultados, nunca registros sin procesar. Es sin estado y no posee claves de archivos.

os-orchestration no asigna CPU. No ajusta la memoria. No se comunica con el controlador de balloon del hipervisor. Las dos capas están diseñadas para ser ciegas entre sí:

• El hipervisor sabe que una VM está consumiendo N páginas y Y por ciento de vCPU. No sabe si la VM está ejecutando os-totebox, os-orchestration o cualquier otra cosa.
• El Totebox Archive dentro de la VM no sabe nada sobre la inflación del balloon, los pesos de cgroup, ni en qué nodo físico se encuentra.

Este es el invariante de aislamiento: el hipervisor no tiene capacidad de lectura sobre el estado interno de la VM.

Archivos libremente transferibles

Debido a que el hipervisor está diseñado para gestionar solo el ciclo de vida de la VM y la asignación de recursos — no los datos dentro de las VMs — un Totebox Archive puede detenerse, copiar la imagen de disco a otro nodo y reiniciarse allí sin ningún cambio en sus datos ni en su identidad; esta propiedad se sostiene independientemente de si los mecanismos de pooling descritos arriba están construidos. El hipervisor del nodo de destino asignaría recursos de su propio pool para la VM reubicada, una vez que ese mecanismo de pool exista.

Esta es la propiedad de transferencia libre de los Totebox Archives: la imagen de disco de arranque es el archivo; el pool de recursos es la infraestructura del nodo. Mover la imagen mueve el archivo. El pool del nuevo nodo absorbe la carga de trabajo.

Estado de implementación

El indicador de dispositivo virtio_balloon está disponible en QEMU 7.x y puede añadirse a un comando de lanzamiento de VM para instalar el controlador de balloon en un invitado — como capacidad autónoma de QEMU, independiente de si os-infrastructure la usa. Hoy no la usa: ningún código del crate añade el indicador, infla o deflacta un balloon, ni aplica un peso cgroups v2. Un script de demostración autónomo y aparte ejerce el mecanismo manualmente a través del monitor QEMU, lanzando una única VM de prueba con el dispositivo de balloon presente desde el arranque y dejando que un operador lo maneje a mano:

(qemu) info balloon      # mostrar la RAM visible por el invitado actualmente
(qemu) balloon 128       # solicitar al invitado que devuelva memoria hasta 128 MB
(qemu) info balloon      # confirmar la recuperación

Ese script prueba que el mecanismo subyacente de QEMU funciona; no es evidencia de que os-infrastructure lo haya integrado. El controlador de balloon — el componente que decidiría cuándo inflar o deflatar el balloon de cada VM en respuesta a señales de demanda — y la asignación de peso cgroups v2 descrita arriba son ambos trabajo planificado, aún sin comenzar.

Planificado: extensión de recursos entre nodos

El pool por nodo es la capa implementada. La extensión distribuida planificada tiene como objetivo permitir que las VMs tomen prestado cómputo de otros nodos físicos de la malla cuando la capacidad local esté bajo presión.

No se requiere reinicio. Las operaciones estándar del pool — inflación, deflación del balloon y cambios de peso en cgroups v2 — son dinámicas. El controlador de balloon señala al controlador dentro del invitado; el controlador responde; el pool del nodo se ajusta. No se necesita reiniciar el invitado ni el anfitrión. Esto aplica tanto al flujo manual del operador (monitor QEMU) como al controlador automatizado planificado.

virtio-mem (kernel Linux desde la versión 5.8; QEMU desde 5.1) es el mecanismo previsto para la capa entre nodos. Donde virtio_balloon infla y deflacta un único dispositivo, virtio-mem admite la conexión y desconexión en caliente de bloques de memoria individuales. El modelo previsto: un nodo prestamista anuncia bloques no utilizados a una VM solicitante en otro nodo a través de la malla WireGuard. Se prevé que el modelo de capacidades de seL4 garantice que el nodo prestamista no retenga capacidad de lectura sobre los bloques que presta.

Las decisiones de colocación entre nodos se prevé que permanezcan en gateway-orchestration-command-1 (capa de Orquestación de Totebox). El ledger de capacidades distribuido — planificado para desarrollo en moonshot-protocol y moonshot-database — tiene como objetivo transportar concesiones de préstamo firmadas criptográficamente, vinculadas a la identidad de la ceremonia de emparejamiento de cada nodo. Se prevé que la revocación se propague como un chisme Merkle DAG a través de la malla sin depender de una autoridad central.

El controlador automático de balloon — el componente dentro de os-infrastructure que dispararía la inflación y deflación en respuesta a señales de demanda — es un hito planificado que precede a la capa de préstamo entre nodos.

Véase también

• os-infrastructure — Sistema Operativo de Nodo PPN — el hipervisor Tipo I que implementa el controlador de balloon
• Totebox Archive — la bóveda soberana de datos que se ejecuta dentro de cada VM
• Tejido VM Distribuido PPN — la extensión entre nodos planificada: préstamo virtio-mem, ledger de capacidades distribuido, planificador entre nodos
• Malla Soberana — la capa de transporte WireGuard que conecta los nodos PPN