SSD Nodes Learn 🎉 VPS desde $5.50/mes
Guías Matt ConnorPor Matt Connor · Actualizado 2026-08-12

Historia del VPS: de los mainframes a la virtualizacion

Conozca la evolucion del tiempo compartido desde el IBM VM/370 hasta KVM y Xen. Entienda por que el aislamiento de procesos sigue siendo el pilar de su VPS en la nube.

El origen de su VPS

La historia de la computación, desde los mainframes hasta la nube, es la historia de una idea que se vuelve más barata. Esa idea es el tiempo compartido: permitir que muchas personas utilicen una máquina costosa al mismo tiempo y ofrecer a cada una de ellas una vista privada de la misma. Se inventó alrededor de 1960 porque un ordenador costaba más que las personas que lo utilizaban. Cada parte del VPS que usted alquila hoy fue construida para resolver ese problema: el aislamiento entre usuarios, el planificador que distribuye el tiempo de CPU, el hypervisor y la factura que contabiliza las horas. El problema nunca desapareció. El hardware se volvió barato, por lo que una porción que antes requería una beca de investigación ahora cuesta unos pocos dólares al mes.

1959 a 1961: por qué se inventó el tiempo compartido

En la década de 1950, los ordenadores funcionaban por lotes. Se perforaba el programa en tarjetas, se entregaba el mazo a un operador y se regresaba más tarde para recoger la impresión. Un solo carácter mal escrito costaba un día de trabajo. La máquina permanecía ocupada, que era el objetivo principal, ya que un equipo como el IBM 7090 costaba millones de dólares y el tiempo de las personas que esperaban por él no aparecía en ninguna factura.

En enero de 1959, John McCarthy planteó el caso opuesto en un memorando en el MIT. La máquina debía esperar a la persona. Christopher Strachey describió una forma de tiempo compartido en una conferencia de la UNESCO ese mismo año, aunque se refería a un programador depurando mientras se ejecutaban otros trabajos, en lugar de muchas personas escribiendo al mismo tiempo. Durante el centenario del MIT en 1961, McCarthy fue más allá: la computación podría venderse como un servicio público, medido como la electricidad.

La objeción en aquel momento era que el tiempo compartido desperdicia la máquina. Cambiar entre usuarios consume ciclos, y los ciclos eran el recurso costoso. La objeción era correcta, pero dejó de importar porque el precio de un ciclo cayó durante sesenta años, mientras que el precio de una hora de atención humana no lo hizo.

Lo que CTSS tuvo que inventar

El grupo de Fernando Corbató en el Computation Center del MIT construyó el Compatible Time-Sharing System (CTSS) para resolver la disputa. Se demostró por primera vez en noviembre de 1961 en una IBM 709, dando servicio a cuatro usuarios y transfiriendo el trabajo de cada uno a su propia unidad de cinta magnética. "Compatible" significaba que la máquina aún podía ejecutar el antiguo sistema por lotes, porque nadie compra un ordenador que solo hace lo nuevo.

Cuatro usuarios es una cifra pequeña. La lista de problemas que hubo que resolver para alcanzarla no lo es, y es la misma lista que su kernel procesa en este preciso instante. CTSS necesitaba un planificador, para que un proceso largo no bloquease el resto de terminales. Necesitaba protección de memoria, para que un programa que fallase solo afectase a un usuario y no a todo el sistema. Necesitaba almacenamiento que sobreviviera al cierre de sesión, motivo por el cual CTSS tuvo uno de los primeros sistemas de archivos que un usuario moderno reconocería. Y necesitaba contraseñas, para que un usuario no pudiera leer los archivos de otro.

Cambie el nombre a esos componentes y tendrá una máquina Linux. El planificador es EEVDF, que reemplazó a CFS en Linux 6.6. La protección de memoria es la MMU (unidad de gestión de memoria), que otorga a cada proceso su propio espacio de direcciones virtuales. El almacenamiento que sobrevive al cierre de sesión es su directorio personal. El archivo de contraseñas todavía se llama /etc/passwd.

Multics y la utilidad informática

El siguiente sistema del MIT estaba destinado a ser la utilidad que McCarthy había descrito. El Project MAC comenzó en 1963, se firmó un contrato para un GE-645 de General Electric en agosto de 1964 y se publicaron los primeros documentos sobre Multics en 1965. El nombre contiene el argumento: Multiplexed Information and Computing Service. Servicio, como algo que se compra por horas.

Multics tardó mucho más de lo previsto. Los prototipos de las máquinas GE-645 llegaron al MIT y a Bell Labs en enero de 1967. Bell Labs abandonó el proyecto en abril de 1969. Multics se abrió a los clientes del MIT Information Processing Center el 1 de octubre de 1969, y funcionó en producción en algún lugar durante treinta y un años. El último sistema Multics activo, en el Departamento de Defensa Nacional de Canadá en Halifax, Nueva Escocia, se apagó el 30 de octubre de 2000.

A menudo se clasifica a Multics como un fracaso porque llegó tarde y funcionaba con lentitud. El vocabulario dice lo contrario. Nos dio el sistema de archivos jerárquico de directorios dentro de directorios, una lista de control de acceso en cada archivo, memoria virtual segmentada que permitía a un programa direccionar un archivo como si fuera memoria, y anillos de protección que clasificaban el código según su nivel de confianza. Los anillos siguen estando en el silicio frente a usted. El ring 0 para el kernel y el ring 3 para el código de usuario es vocabulario de Multics, y la virtualización por hardware añadió más tarde un modo por debajo del ring 0 para el hipervisor, al que la gente llama informalmente ring -1.

Unix: tiempo compartido en una máquina asequible

Abandonar Multics dejó a Ken Thompson en Bell Labs sin un sistema que quisiera utilizar. En 1969 comenzó uno mucho más pequeño en una PDP-7 desechada. El primer Unix Programmer's Manual tiene fecha de noviembre de 1971, momento en el cual el trabajo se había trasladado a una PDP-11. En 1973, Thompson y Dennis Ritchie reescribieron el kernel en C, de modo que el sistema pudiera trasladarse a nuevo hardware sin necesidad de ser escrito de nuevo manualmente.

Esa es la razón por la que usted escribe en un descendiente de Unix y no en uno de Multics. Multics necesitaba hardware construido para Multics. Unix funcionaba en cualquier cosa que fuera barata y estuviera disponible, y eso resultó ser la característica decisiva.

"The UNIX Time-Sharing System" de Ritchie y Thompson apareció en Communications of the ACM en julio de 1974. El documento describe su VPS: procesos, un sistema de archivos jerárquico, archivos como flujos de bytes planos, fork, usuarios y grupos con bits de permisos, y un shell que es un programa ordinario en lugar de parte del kernel. Cincuenta y dos años después, esa interfaz ha sido extendida, nunca reemplazada.

¿Realmente ejecutaban las mainframes máquinas virtuales en 1972?

Sí, y esta es la parte de la historia que la mayoría de la gente pasa por alto. Mientras el MIT construía Multics, el Cambridge Scientific Center de IBM abordó el mismo objetivo desde el extremo opuesto. En lugar de un sistema operativo que atendiera a muchos usuarios, Robert Creasy y Les Comeau crearon un programa de control que proporcionaba a cada usuario una computadora simulada completa. CP-40 entró en producción en enero de 1967. Cada usuario obtenía un System/360 virtual y ejecutaba un pequeño sistema operativo monousuario, CMS, dentro de él.

CP-40 se convirtió en CP-67 en el System/360-67 en 1968, e IBM anunció VM/370 el 2 de agosto de 1972. Se trata de un hipervisor comercial, vendido a clientes de pago, hace cincuenta y cuatro años. Un programa de control multiplexaba el hardware real, y los sistemas operativos invitados se ejecutaban sin modificaciones dentro de máquinas virtuales que creían poseer la máquina.

La teoría llegó dos años después, en el mismo número de julio de 1974 de Communications of the ACM que contenía el artículo sobre Unix. El trabajo de Gerald Popek y Robert Goldberg, "Formal Requirements for Virtualizable Third Generation Architectures", estableció lo que un procesador debe hacer para ser virtualizable. La regla fundamental es breve. Cada instrucción que pueda leer o cambiar el estado de la máquina debe generar una interrupción (trap) cuando un invitado la ejecuta fuera del modo kernel, de modo que el hipervisor tome el control y responda con la versión privada del estado de ese invitado. Esto se denomina trap and emulate. El hardware de IBM obedecía esta regla.

Por qué la minicomputadora rompió el modelo

DEC presentó la PDP-8 el 22 de marzo de 1965 por un precio aproximado de 18,000 dólares de la época. Fue la primera minicomputadora con un precio inferior a 20,000 dólares y llegó a vender más de 50,000 unidades. Posteriormente, el microprocesador redujo el precio aún más. Una vez que un departamento pudo comprar su propia máquina, y más tarde una persona, compartir una computadora central pareció un problema resuelto que ya no requería solución. Durante las décadas de 1980 y 1990, la computación se trasladó a los escritorios y a racks de pequeños servidores x86.

El desperdicio regresó bajo una forma distinta. Una aplicación por servidor es fácil de gestionar, pero deja la mayor parte del hardware inactivo mientras se paga el consumo eléctrico y el espacio en el rack en su totalidad. Es el problema de CTSS de nuevo, pero a otra escala, donde el recurso costoso ahora es la sala y la electricidad en lugar del procesador. La respuesta fue la misma de siempre: compartir la máquina.

¿Por qué fue tan difícil virtualizar x86?

Porque x86 incumplía la regla de Popek y Goldberg. En el 9º Simposio de Seguridad USENIX en agosto de 2000, John Scott Robin y Cynthia Irvine analizaron el conjunto de instrucciones de Pentium y encontraron diecisiete instrucciones que leen o modifican el estado privilegiado sin generar un fallo cuando el código en modo usuario las ejecuta. popf es el ejemplo estándar. Si se ejecuta en modo usuario, el procesador ignora silenciosamente los bits que el programa no tiene permiso para establecer, en lugar de generar una excepción. Por tanto, un hipervisor basado en la técnica de "captura y emulación" (trap and emulate) nunca detecta que el invitado lo intentó.

Surgieron dos respuestas antes de que el hardware fuera corregido. VMware, fundada en 1998 a partir de la investigación Disco de Stanford, inspeccionaba el código del kernel invitado y reescribía las instrucciones problemáticas antes de su ejecución, una técnica llamada traducción binaria. Xen, del Laboratorio de Computación de la Universidad de Cambridge, modificó al invitado en su lugar. El artículo "Xen and the Art of Virtualization", presentado en SOSP en octubre de 2003, describió la paravirtualización: un kernel invitado modificado llama al hipervisor deliberadamente en lugar de ejecutar instrucciones que el hipervisor no puede interceptar.

Después, el hardware fue corregido, de la misma forma que IBM lo hizo en la década de 1960. Intel lanzó VT-x en dos modelos de Pentium 4 el 14 de noviembre de 2005, y AMD lanzó AMD-V en mayo de 2006. Ambos añaden un modo de procesador por debajo del kernel del invitado, de modo que este ejecuta su propio kernel a máxima velocidad mientras el hipervisor mantiene el control de los eventos que solicita. Esto permitió que un hipervisor fuera lo suficientemente pequeño como para residir dentro de un sistema operativo convencional, y el KVM de Avi Kivity en Qumranet hizo exactamente eso: convirtió al propio kernel de Linux en el hipervisor. KVM se integró en Linux 2.6.20, lanzado en febrero de 2007, y es lo que utiliza hoy una gran parte de los proveedores de VPS.

Origen del nombre del VPS

Dos líneas convergieron a principios de la década de 2000. La primera era la máquina virtual completa en x86, un invitado que arranca su propio kernel. La segunda era la virtualización a nivel de sistema operativo: un único kernel de Linux compartido dividido en entornos separados, cada uno con su propio usuario root y su propia tabla de procesos. Linux-VServer y Virtuozzo de SWsoft aparecieron en 2001, y SWsoft publicó parte de Virtuozzo como el software de código abierto OpenVZ en 2005. La frase "virtual private server" proviene de esa rama de la familia, formada por analogía con la red privada virtual (VPN).

Amazon convirtió el alquiler en una llamada a una API. S3 se lanzó el 14 de marzo de 2006 y EC2 se abrió como una beta pública limitada el 25 de agosto de 2006 con un único tipo de instancia, ejecutándose sobre Xen. Comprar capacidad de cómputo dejó de ser un contrato con una oficina de servicios y se convirtió en una solicitud que se completa en un minuto.

Ambas líneas sobreviven, y la división sigue determinando lo que puede hacer con el servidor que alquila. Un VPS basado en KVM arranca su propio kernel, por lo que puede cargar módulos del kernel e incluso ejecutar un hipervisor dentro de su VPS. Un plan basado en contenedores comparte el kernel del host y no puede hacerlo. Sesenta años de historia respaldan esa única línea en una página de precios, por lo que vale la pena entender las diferencias entre un VPS, una VM y una VPC antes de elegir uno.

Qué cambió desde el mainframe hasta su VPS, y qué no

Cuatro cosas cambiaron. La máquina no está en su edificio. La terminal es un programa en lugar de un mueble. La unidad que usted alquila es una computadora completa con su propio kernel, en lugar de una cuenta en el sistema operativo de otra persona. Y el precio bajó lo suficiente como para que la compra sea un pago con tarjeta en lugar de un proceso de adquisición.

El mecanismo no cambió en absoluto.

  • Su sesión ssh es una terminal de tiempo compartido. Usted obtiene un inicio de sesión y un shell, y un planificador decide cuándo se ejecuta su proceso a continuación.
  • El aislamiento sigue siendo aplicado por el hardware. La MMU y los niveles de privilegio del procesador hacen el trabajo, exactamente como CP-40 lo necesitaba en 1967.
  • Usted sigue recibiendo facturas por una parte de una máquina según el tiempo transcurrido, de la misma forma en que las oficinas de servicios facturaban las horas de conexión.
  • Usted sigue sintiendo a los otros inquilinos. Cuando un host está sobresuscrito, su invitado espera por una CPU física, y Linux reporta esa espera como tiempo de robo de CPU de un vecino ruidoso.

Ese último punto es el resumen honesto de toda la historia. Compartir una máquina es un intercambio. Fue aceptado en 1961 porque la computadora costaba más que las personas, y es aceptado en 2026 porque un servidor funcionando al diez por ciento de su capacidad es dinero quemado. Si usted prefiere estar del lado del operador en ese intercambio, ejecutar Proxmox en hardware propio le entrega el hipervisor y los problemas del operador al mismo tiempo.

Tenga en cuenta la proporción. CTSS servía a cuatro usuarios en una máquina que costaba millones de dólares de 1961 y llenaba una habitación. Su VPS, por unos pocos dólares al mes en 2026, es una computadora mucho mejor que la que el equipo de Corbató estaba racionando, y usted la tiene para usted solo. La razón por la que puede alquilarla es una idea de hace sesenta y cinco años que finalmente se encontró con hardware barato. Si está decidiendo qué instalar en ella, comience con lo que un VPS le ofrece realmente y luego lo que la gente ejecuta en uno.

FAQ

¿Cuál fue el primer sistema informático de tiempo compartido?

CTSS, el Compatible Time-Sharing System, construido por el grupo de Fernando Corbató en el MIT Computation Center. Se demostró por primera vez en noviembre de 1961 en un IBM 709 y daba servicio a cuatro usuarios, cada uno de ellos intercambiado a una unidad de cinta independiente. El primer servicio de tiempo compartido para toda una comunidad fue el Dartmouth Time-Sharing System: el 1 de mayo de 1964, John Kemeny y un estudiante programador ejecutaron programas en BASIC al mismo tiempo en dos terminales y ambos obtuvieron respuestas correctas.

¿Se inventaron realmente las máquinas virtuales en la década de 1960?

Sí. El Cambridge Scientific Center de IBM puso en producción el CP-40 en enero de 1967, proporcionando a cada usuario un System/360 virtual completo con el sistema operativo CMS ejecutándose en su interior. El CP-67 le siguió en 1968 en el System/360-67, e IBM anunció el VM/370 el 2 de agosto de 1972. Se trata de hipervisores reales que ejecutan sistemas operativos invitados sin modificar, vendidos comercialmente décadas antes de que el hardware x86 pudiera hacer lo mismo.

¿Por qué era difícil virtualizar x86 cuando los mainframes no lo eran?

La regla de Popek y Goldberg de 1974 establece que cada instrucción que pueda leer o cambiar el estado de la máquina debe generar una excepción (trap) cuando un invitado la ejecuta fuera del modo kernel. x86 rompió esa regla. Robin e Irvine contaron diecisiete instrucciones de Pentium que fallan silenciosamente en modo usuario en lugar de generar una excepción, por lo que un hipervisor clásico de tipo trap-and-emulate nunca las detecta, y popf es el ejemplo habitual. VMware lo solucionó con traducción binaria y Xen con paravirtualización, hasta que Intel VT-x en noviembre de 2005 y AMD-V en mayo de 2006 añadieron un modo de hardware para el hipervisor.

¿Es alquilar un VPS lo mismo que tener una cuenta de tiempo compartido?

El modelo de facturación y el problema de aislamiento son los mismos. La unidad es diferente. Un usuario de tiempo compartido obtenía una cuenta en un sistema operativo compartido con todos los demás, por lo que el administrador era alguien del centro de cálculo. Un VPS KVM le proporciona una máquina virtual con su propio kernel y su propia cuenta root, por lo que el administrador es usted. Un VPS basado en contenedores se sitúa entre ambos, ya que comparte el kernel del host mientras le sigue proporcionando acceso root dentro de su propio entorno.

#history#computing#virtualization#mainframe#vps