Volver al blogKVM y un VPS clásico de contenedores OpenVZ permiten alojar a varios clientes en un mismo servidor físico. La diferencia decisiva es el kernel, el núcleo del sistema operativo: el contenedor OpenVZ comparte el kernel Linux del servidor anfitrión; la máquina virtual KVM arranca el suyo. Esto cambia qué puedes instalar, cómo administras el servidor y dónde está el límite de seguridad.
EDIS ofreció OpenVZ en el pasado. Hoy toda nuestra gama VPS utiliza KVM. Estas respuestas explican las diferencias prácticas sin convertir la tecnología en una promesa absoluta.
KVM y OpenVZ de un vistazo
- Kernel: un contenedor OpenVZ clásico utiliza el del anfitrión; una VM KVM arranca su propio kernel.
- Recursos: ambas tecnologías pueden imponer límites. Lo que se garantiza depende de la política del proveedor. EDIS asigna vCPU, RAM garantizada y almacenamiento del plan a sus VPS KVM.
- Sistemas operativos: los contenedores OpenVZ clásicos ejecutan entornos Linux compatibles con el kernel anfitrión. KVM admite huéspedes Linux o Windows compatibles e imágenes propias admitidas.
- Aislamiento: los contenedores separan procesos y archivos mediante el mismo kernel. KVM ofrece a cada huésped su propio entorno de hardware virtual.
¿Qué distingue un VPS KVM de uno OpenVZ?
Un VPS OpenVZ clásico es un contenedor de sistema operativo. Sus aplicaciones son procesos del anfitrión que reciben una vista separada de archivos, red e identificadores de procesos. Parece un servidor independiente, pero no tiene un kernel propio. Un VPS KVM es una máquina virtual completa: presenta CPU, memoria y disco virtuales a un sistema operativo huésped que arranca de forma independiente.
Aquí comparamos KVM con los antiguos productos OpenVZ basados en contenedores. La plataforma OpenVZ más amplia también llegó a admitir máquinas virtuales basadas en KVM; su nombre, por sí solo, no significa que cualquier producto sea un contenedor.
¿Puedo ejecutar mi propio kernel o cargar módulos?
Con KVM controlas el kernel del huésped. Puedes actualizarlo, elegir otro compatible y utilizar sus funciones o módulos dentro de la VM, según el hardware virtual y la configuración. El acceso root te da control dentro de tu VM, no sobre el servidor físico.
Un contenedor OpenVZ clásico depende del kernel del anfitrión. Desde el contenedor no puedes sustituirlo ni cargar módulos arbitrarios en él. Por eso, algunos requisitos de software aparentemente sencillos necesitaban intervención del proveedor.
¿Son dedicados la CPU, la RAM y el disco?
KVM asigna CPU virtuales, memoria y un disco virtual a cada VM. Eso no significa por sí solo que cada vCPU tenga un núcleo físico exclusivo ni que todo el servidor físico sea de un cliente. Los procesadores, los dispositivos de almacenamiento y los enlaces de red siguen siendo infraestructura compartida. Importan el plan y la forma en que el proveedor asigna recursos.
OpenVZ también podía limitar CPU, RAM y disco, aunque muchos planes antiguos utilizaban otras reglas de contabilidad y ráfagas. Cada plan KVM de EDIS incluye su asignación de vCPU, RAM garantizada y capacidad de disco provisionada. Comprueba la ficha del plan y la ubicación: la palabra KVM no promete por sí sola un rendimiento ni una velocidad de red determinados.
¿Qué sistemas operativos puedo instalar?
Un contenedor OpenVZ clásico ejecuta un entorno Linux sobre el kernel Linux del anfitrión. Puede ofrecer plantillas Linux compatibles, pero no arrancar Windows como contenedor ni elegir un kernel totalmente independiente.
KVM puede arrancar huéspedes Linux y Windows compatibles porque cada VM tiene hardware virtual y su propio kernel. EDIS ofrece imágenes Linux, Windows en planes adecuados e instalación con ISO propia. Comprueba la imagen, el modo de arranque, los controladores y la licencia del plan. Para Windows Server recomendamos al menos 4 GB de RAM y 2 vCPU.
¿En qué cambia el aislamiento de seguridad?
Los contenedores OpenVZ sí tenían aislamiento: separaban listas de procesos, vistas del sistema de archivos y otros recursos. La limitación fundamental era compartir el kernel del anfitrión. Una vulnerabilidad que permita romper esa barrera puede poner en riesgo otros contenedores del mismo servidor. Una aplicación comprometida no abre automáticamente todos los vecinos, pero el kernel compartido amplía el posible alcance del daño.
KVM añade un kernel huésped separado y una barrera de virtualización asistida por hardware para cada VPS. Un cliente normalmente no puede inspeccionar los procesos o archivos de otro huésped desde su VM. También existen posibles fallos del hipervisor o el anfitrión; un aislamiento fuerte no significa seguridad absoluta. Siguen siendo necesarios los parches y los controles de acceso.
¿Pueden otros clientes, o EDIS, ver lo que ejecuto?
Otros clientes no pueden recorrer normalmente la lista de procesos o los archivos montados de tu VM KVM como si estuvieran en su propio servidor. Cada huésped tiene su propia vista y sistema operativo. Es una diferencia relevante frente a procesos y árboles de archivos gestionados directamente por un host de contenedores.
Sería incorrecto afirmar que nadie puede ver jamás el interior de una VM. Un administrador con acceso privilegiado al host o al almacenamiento podría potencialmente inspeccionar un disco virtual o la memoria de una VM en ejecución. KVM separa a los clientes entre sí; EDIS sigue operando y protegiendo la infraestructura subyacente. La confianza en el proveedor y sus controles de acceso también importa.
¿Puedo cifrar el disco de un VPS KVM?
Sí. Puedes configurar cifrado desde el sistema huésped, por ejemplo Linux LUKS, en discos virtuales compatibles. Si controlas la clave, ayuda a proteger los datos almacenados frente a accesos sin conexión. Planifica el desbloqueo después de reiniciar, conserva las claves de recuperación y prueba la restauración. KVM no activa el cifrado automáticamente.
El cifrado del disco no oculta una VM en funcionamiento a un administrador privilegiado del host: el huésped necesita datos descifrados y claves en memoria. Tampoco sustituye copias de seguridad cifradas, seguridad de aplicaciones o buena gestión de claves. Comprueba el procedimiento de arranque y recuperación antes de usarlo en producción.
¿Qué fue Waveride y por qué EDIS dejó OpenVZ?
Hace muchos años, EDIS gestionó un popular proyecto OpenVZ llamado Waveride. Su antigua web lo presentaba como «an EDIS company» y anunciaba VPS económicos en Viena, Ámsterdam y Chicago. El pingüino que surfeaba lo hacía inolvidable. Nos divertimos con el proyecto; el panel SolusVM y otras opciones de control disponibles entonces no eran ideales para nosotros.
En nuestra instalación antigua, el contenedor se parecía más a procesos y árboles de archivos gestionados por el host que a una máquina autónoma. Queríamos más control del kernel y una separación más fuerte para los clientes. Por ello, hace aproximadamente diez años dejamos de ofrecer VPS OpenVZ y migramos completamente a KVM. Esta es nuestra historia; no implica que los contenedores modernos carezcan de aislamiento ni que todas las versiones OpenVZ guarden sus archivos como directorios: algunas posteriores usan imágenes de disco.
¿Por qué EDIS Global ofrece hoy solo KVM?
Queremos que cada VPS arranque su propio sistema huésped, permita controlar el kernel y se sitúe detrás de una sólida barrera de máquina virtual. KVM se ajusta a ese modelo y nos permite provisionar las vCPU, la RAM y el disco del plan, con Linux y configuraciones Windows adecuadas. Es una tecnología madura y actual para el alojamiento VPS multiusuario.
Los contenedores siguen siendo útiles si controlas el host y buscas empaquetar aplicaciones con pocos recursos. Para un VPS de cliente que necesite un kernel independiente y mayor separación entre usuarios, elegimos KVM. Compara los planes y ubicaciones VPS KVM de EDIS Global antes de contratar.