VM (a menudo: VM/CMS ) es una familia de sistemas operativos de máquinas virtuales de IBM utilizados en los mainframes IBM System/370 , System/390 , zSeries , System z y sistemas compatibles, incluido el emulador Hercules para computadoras personales.
El corazón de la arquitectura de la VM es el Programa de Control o hipervisor abreviado CP, VM-CP y, a veces, de forma ambigua, VM. Se ejecuta en el hardware físico y crea el entorno de la máquina virtual . VM-CP proporciona virtualización completa de la máquina física, incluidas todas las operaciones de E/S y otras operaciones privilegiadas. Realiza el uso compartido de los recursos del sistema, incluida la gestión de dispositivos, el despacho, la gestión del almacenamiento virtual y otras tareas tradicionales del sistema operativo. A cada usuario de la VM se le proporciona una máquina virtual independiente que tiene su propio espacio de direcciones , dispositivos virtuales, etc., y que es capaz de ejecutar cualquier software que pueda ejecutarse en una máquina independiente. Un mainframe de VM determinado normalmente ejecuta cientos o miles de instancias de máquina virtual. VM-CP comenzó como CP-370, una reimplementación de CP-67 , a su vez una reimplementación de CP-40 .
Dentro de cada máquina virtual se ejecuta otro sistema operativo, un sistema operativo invitado . Este podría ser:
Se conocen las siguientes versiones:
El CMS en el nombre se refiere al Sistema de Monitoreo Conversacional, un componente del producto que es un sistema operativo de usuario único que se ejecuta en una máquina virtual y proporciona tiempo compartido conversacional en la VM.
IBM acuñó el término hipervisor para el 360/65 [13] y más tarde lo utilizó para el controlador DIAG del CP-67.
La instrucción Diagnose ('83'x—sin mnemónico) es una instrucción privilegiada originalmente pensada por IBM para realizar "funciones de diagnóstico integradas u otras funciones dependientes del modelo". [14] IBM readaptó DIAG para la "comunicación entre una máquina virtual y CP". [15] [16] La instrucción contiene dos números de registro de cuatro bits, llamados Rx y Ry, que pueden "contener direcciones de almacenamiento de operandos o códigos de retorno pasados a la interfaz DIAGNOSE", y un código de dos bytes "que CP utiliza para determinar qué función DIAGNOSE realizar". [15] Las funciones de diagnóstico disponibles incluyen:
En un momento dado, CMS podía ejecutarse en una máquina vacía como un verdadero sistema operativo (aunque una configuración de este tipo sería inusual). Ahora se ejecuta solo como un sistema operativo invitado en una máquina virtual. Esto se debe a que CMS depende de una interfaz de hipervisor para VM-CP, para realizar operaciones del sistema de archivos y solicitar otros servicios de la máquina virtual. Esta interfaz de paravirtualización :
Los CMS y otros sistemas operativos suelen tener requisitos DASD mucho más pequeños que los tamaños de los volúmenes reales. Por este motivo, CP permite que una instalación defina discos virtuales de cualquier tamaño hasta la capacidad del dispositivo. Para los volúmenes CKD, un minidisco debe definirse en cilindros completos. Un minidisco tiene los mismos atributos que el disco real subyacente, excepto que suele ser más pequeño y el comienzo de cada minidisco se asigna al cilindro o bloque 0. Se puede acceder al minidisco utilizando los mismos programas de canal que el disco real.
Un minidisco que se ha inicializado con un sistema de archivos CMS se denomina minidisco CMS, aunque CMS no es el único sistema que puede usarlos.
Es una práctica común definir minidiscos de volumen completo para que los utilicen sistemas operativos invitados como z/OS en lugar de DEDICATEasignar el volumen a una máquina virtual específica. Además, los "enlaces de paquete completo" suelen definirse para cada DASD del sistema y son propiedad del ID de usuario MAINT. Se utilizan para realizar copias de seguridad del sistema mediante el programa DASD Dump/Restore, donde todo el contenido de un DASD se escribe en cinta (u otro DASD) exactamente.
Con las versiones modernas de VM, la mayor parte del sistema se puede instalar en SFS, y los pocos minidiscos restantes son los absolutamente necesarios para que el sistema se inicie y los que pertenecen a las máquinas del servidor de archivos.
La versión 6 de VM/SP introdujo el sistema de archivos compartidos [17] , que mejoró enormemente las capacidades de almacenamiento de archivos de CMS. El sistema de archivos de minidiscos de CMS no admite directorios (carpetas) en absoluto, sin embargo, el SFS sí lo hace. SFS también introduce una seguridad más granular. Con los minidiscos de CMS, el sistema se puede configurar para permitir o denegar a los usuarios el acceso de solo lectura o de lectura y escritura a un disco, pero los archivos individuales no pueden tener la misma seguridad. SFS alivia esto y mejora enormemente el rendimiento.
El SFS lo proporcionan las máquinas virtuales de servicio. En un sistema de VM moderno, normalmente se requieren tres: VMSERVR, la "máquina de recuperación" que en realidad no sirve ningún archivo; VMSERVS, el servidor para el grupo de archivos VMSYS; y VMSERVU, el servidor para el grupo de archivos VMSYSU (usuario). [18] Las máquinas servidor del grupo de archivos poseen varios minidiscos, que normalmente incluyen un disco A de CMS (dirección de dispositivo virtual 191, que contiene los archivos de configuración del grupo de archivos), un disco de control, un disco de registro y cualquier cantidad de discos de datos que realmente almacenan archivos de usuario.
Si una cuenta de usuario está configurada para usar solo SFS (y no posee ningún minidisco), el disco A del usuario será FILEPOOL:USERID.y cualquier directorio posterior que el usuario cree será FILEPOOL:USERID.DIR1.DIR2.DIR3donde esté la ruta de archivo UNIX equivalente /dir1/dir2/dir3. Los directorios SFS pueden tener controles de acceso mucho más granulares en comparación con los minidiscos (que, como se mencionó anteriormente, a menudo solo pueden tener una contraseña de lectura, una contraseña de escritura y una contraseña de escritura múltiple). Los directorios SFS también resuelven los problemas que pueden surgir cuando dos usuarios escriben en el mismo minidisco CMS al mismo tiempo, lo que puede causar corrupción del disco (ya que la VM CMS que realiza las escrituras puede no saber que otra instancia CMS también está escribiendo en el minidisco).
Las máquinas servidoras de pool de archivos también sirven a un sistema de archivos estrechamente relacionado: el Byte File System. BFS se utiliza para almacenar archivos en un sistema de archivos de estilo UNIX. Su uso principal es para el entorno POSIX de VM OpenExtensions para CMS. Las máquinas virtuales de usuario de CMS se comunican con las máquinas virtuales del servidor SFS a través del mecanismo IUCV. [19]
La historia temprana de VM se describe en los artículos CP/CMS y History of CP/CMS . VM/370 es una reimplementación de CP/CMS y se puso a disposición en 1972 como parte del anuncio de IBM System/370 Advanced Function (que agregó hardware de memoria virtual y sistemas operativos a la serie System/370 ). Las primeras versiones de VM hasta VM/370 Release 6 continuaron en código abierto hasta 1981 y hoy se consideran de dominio público . Esta política terminó en 1977 con las actualizaciones de pago de VM/SE y VM/BSE y en 1980 con VM/System Product (VM/SP). Sin embargo, IBM continuó proporcionando actualizaciones en forma de fuente para el código existente durante muchos años, aunque las actualizaciones de todos los sistemas excepto la base gratuita requerían una licencia. Al igual que con CP-67, las instrucciones privilegiadas en una máquina virtual causan una interrupción del programa y CP simulaba el comportamiento de la instrucción privilegiada. VM siguió siendo una plataforma importante dentro de IBM, utilizada para el desarrollo de sistemas operativos y el uso compartido de tiempo; pero para los clientes siguió siendo el "otro sistema operativo" de IBM. Las familias OS y DOS siguieron siendo productos estratégicos de IBM, y no se animó a los clientes a utilizar VM. Aquellos que lo hicieron establecieron relaciones de trabajo estrechas, continuando el modelo de soporte comunitario de los primeros usuarios de CP/CMS. Mientras tanto, el sistema se enfrentó a luchas políticas internas dentro de IBM sobre qué recursos deberían estar disponibles para el proyecto, en comparación con otros esfuerzos de IBM. Un problema básico con el sistema se vio a nivel de ventas de campo de IBM: VM/CMS redujo de manera demostrable la cantidad de hardware necesario para soportar un número determinado de usuarios de tiempo compartido. Después de todo, IBM estaba en el negocio de vender sistemas informáticos.
Melinda Varian ofrece esta fascinante cita que ilustra el éxito inesperado de VM: [20]
Las previsiones de marketing para el VM/370 predecían que no habría más de un procesador 168 que pudiera ejecutar VM durante toda la vida útil del producto. De hecho, el primer procesador 168 que se entregó a un cliente sólo ejecutaba CP y CMS. Diez años después, el diez por ciento de los procesadores grandes que se enviaban desde Poughkeepsie se destinarían a ejecutar VM, al igual que una parte muy sustancial de las máquinas de gama media que se fabricaban en Endicott. Antes de que transcurrieran quince años, habría más licencias VM que licencias MVS.
Una versión para PC DOS que ejecuta CMS en el XT/370 (y más tarde en el AT/370) se llama VM/PC. VM/PC 1.1 se basó en la versión 3 de VM/SP. Cuando IBM presentó las tarjetas de procesador P/370 y P/390, una PC podía ejecutar sistemas VM completos, incluidos VM/370, VM/SP, VM/XA y VM/ESA (estas tarjetas eran totalmente compatibles con los mainframes S/370 y S/390, y podían ejecutar cualquier sistema operativo S/370 de la era de 31 bits, por ejemplo, MVS/ESA, VSE/ESA).
Además de las versiones base de VM/SP, IBM también introdujo VM/SP HPO (High Performance Option). Este complemento (que se instala sobre la versión base de VM/SP) mejoró varias funciones clave del sistema, incluida la posibilidad de utilizar más de 16 MB de almacenamiento (RAM) en los modelos compatibles (como el IBM 4381). Con VM/SP HPO instalado, el nuevo límite era de 64 MB; sin embargo, un solo usuario (o máquina virtual) no podía utilizar más de 16 MB. También se mejoraron las funciones del sistema de archivos de spool, lo que permitió crear 9900 archivos de spool por usuario, en lugar de 9900 para todo el sistema. También se mejoró la arquitectura del sistema de archivos de spool: cada archivo de spool tenía ahora un identificador de usuario único asociado y los bloques de control de archivos de lectura se guardaban ahora en un almacenamiento virtual. El sistema también podía configurarse para denegar a ciertos usuarios el acceso a la función de vector (por medio de entradas de directorio de usuarios). [6]
Las versiones de VM posteriores a VM/SP Release 1 admitían sistemas multiprocesador. Las versiones System/370 de VM (como VM/SP y VM/SP HPO) admitían un máximo de dos procesadores, con el sistema funcionando en modo UP (monoprocesador), modo MP (multiprocesador) o modo AP (procesador conectado). [21] El modo AP es el mismo que el modo MP, excepto que el segundo procesador carece de capacidad de E/S. Las versiones System/370-XA de VM (como VM/XA) admitían más. Las versiones System/390 (como VM/ESA) eliminaron casi por completo el límite, y algunos sistemas z/VM modernos pueden tener hasta 80 procesadores. [22] El límite por VM para procesadores definidos es 64.
Cuando IBM introdujo la arquitectura extendida System/370 en el 3081 , los clientes se enfrentaron a la necesidad de ejecutar un sistema MVS/370 de producción mientras probaban MVS/XA en la misma máquina. La solución de IBM fue VM/XA Migration Aid, que utilizaba la nueva instrucción Start Interpretive Execution (SIE) para ejecutar la máquina virtual. SIE manejaba automáticamente algunas instrucciones privilegiadas y regresaba a CP para los casos que no podía manejar. El Processor Resource/System Manager (PR/SM) del posterior 3090 también utilizaba SIE. Hubo varios productos VM/XA antes de que finalmente fuera reemplazado por VM/ESA y z/VM.
Además de la red RSCS , IBM también proporcionó a los usuarios la red VTAM . ACF/VTAM para VM era totalmente compatible con ACF/VTAM en MVS y VSE. [23] Al igual que RSCS, VTAM en VM se ejecutaba bajo el sistema operativo especializado GCS. Sin embargo, VM también admitía redes TCP/IP. A fines de la década de 1980, IBM produjo una pila TCP/IP para VM/SP y VM/XA. [24] La pila admitía redes IPv4 y una variedad de sistemas de interfaz de red (como enlaces canal a canal entre mainframes o una IBM RT PC especializada que retransmitiría el tráfico a una red Token Ring o Ethernet ). La pila brindaba soporte para conexiones Telnet , ya sea desde emuladores de terminal de modo de línea simples o emuladores compatibles con VT100, o emuladores de terminal IBM 3270 adecuados. La pila también proporcionaba un servidor FTP. IBM también produjo un servidor NFS opcional para VM; las primeras versiones eran bastante primitivas, pero las versiones modernas son mucho más avanzadas. [25]
También existía una cuarta opción de red, conocida como VM/Pass-Through Facility (o más comúnmente llamada, PVM). PVM, al igual que VTAM, permitía conexiones a sistemas VM/CMS remotos, así como a otros sistemas IBM. [26] Si dos nodos VM/CMS estaban conectados entre sí a través de un enlace de canal a canal o un enlace bisync (posiblemente utilizando un módem de acceso telefónico o una línea alquilada), un usuario podía conectarse de forma remota a cualquiera de los sistemas ingresando "DIAL PVM" en la pantalla de inicio de sesión de VM y luego ingresando el nombre del nodo del sistema (o eligiéndolo de una lista de nodos disponibles). Alternativamente, un usuario que ejecutaba CMS podía usar el programa PASSTHRU que se instalaba junto con PVM, lo que permitía un acceso rápido a sistemas remotos sin tener que cerrar la sesión del usuario. PVM también admitía el acceso a sistemas que no fueran VM, utilizando una técnica de emulación 3x74. Las versiones posteriores de PVM también presentaban un componente que podía aceptar conexiones desde una red SNA .
VM también fue el sistema operativo fundamental de BITNET , ya que el sistema RSCS disponible para VM proporcionaba una red sencilla que era fácil de implementar y algo fiable. Los sitios VM estaban interconectados por medio de una VM RSCS en cada sistema VM que se comunicaba entre sí, y los usuarios podían enviar y recibir mensajes, archivos y trabajos por lotes a través de RSCS. El comando "NOTE" utilizaba XEDIT para mostrar un cuadro de diálogo para crear un correo electrónico, desde el que el usuario podía enviarlo. Si el usuario especificaba una dirección en forma de user at node, el archivo de correo electrónico se entregaría a RSCS, que luego lo entregaría al usuario de destino en el sistema de destino. Si el sitio tiene TCP/IP instalado, RSCS podría trabajar con la máquina de servicio SMTP para entregar notas (correos electrónicos) a sistemas remotos, así como para recibirlos. Si el usuario especificaba user at some.host.name, el programa NOTE entregaría el correo electrónico a la máquina de servicio SMTP, que luego lo enrutaría al sitio de destino en Internet.
El papel de VM cambió dentro de IBM cuando la evolución del hardware condujo a cambios significativos en la arquitectura del procesador. La compatibilidad con versiones anteriores siguió siendo una piedra angular de la familia de mainframes de IBM , que todavía utiliza el conjunto de instrucciones básicas introducido con el System/360 original; pero la necesidad de un uso eficiente de la zSeries de 64 bits hizo que el enfoque VM fuera mucho más atractivo. VM también se utilizó en centros de datos que convertían de DOS/VSE a MVS y es útil cuando se ejecutan mainframes AIX y Linux , plataformas que se volverían cada vez más importantes. La plataforma z/VM actual finalmente ha logrado el reconocimiento dentro de IBM que los usuarios de VM sintieron que merecía durante mucho tiempo. Algunos sitios z/VM ejecutan miles de usuarios de máquinas virtuales simultáneos en un solo sistema. z/VM se lanzó por primera vez en octubre de 2000 [27] y continúa en uso y desarrollo activos.
IBM y terceros han ofrecido muchas aplicaciones y herramientas que se ejecutan en VM. Algunos ejemplos incluyen RAMIS , FOCUS , SPSS , NOMAD , DB2 , REXX , RACF y OfficeVision . Las ofertas actuales de VM abarcan toda la gama de aplicaciones de mainframe, incluidos servidores HTTP , administradores de bases de datos, herramientas de análisis, paquetes de ingeniería y sistemas financieros.
A partir de la versión 6, el programa de control VM/370 tiene una serie de comandos para usuarios generales, relacionados con la definición y el control de la máquina virtual del usuario. Las partes en minúscula del comando son opcionales [28]
A partir de la versión 2 de VM/ESA, IBM introdujo la característica opcional de pago OpenEdition for VM/ESA Shell and Utilities Feature [29] , que proporciona compatibilidad POSIX para CMS. La característica destacada fue un shell UNIX para CMS. El compilador C para este entorno UNIX lo proporciona C/370 o C for VM/ESA. Ni el sistema de archivos CMS ni el sistema de archivos compartidos VM estándar tienen soporte para archivos y rutas de estilo UNIX; en su lugar, se utiliza el sistema de archivos Byte. Una vez que se crea una extensión BFS en un grupo de archivos SFS, el usuario puede montarla utilizando OPENVM MOUNT /../VMBFS:fileservername:filepoolname /path/to/mount/point. El usuario también debe montar el sistema de archivos raíz, hecho con OPENVM MOUNT /../VMBFS:VMSYS:ROOT/ /, luego se puede iniciar un shell con OPENVM SHELL. A diferencia del SFS normal, el acceso a los sistemas de archivos BFS está controlado por permisos POSIX (con chmod y chown ).
A partir de la versión 3 de z/VM, IBM integró OpenEdition en z/VM [30] y lo renombró OpenExtensions. OpenEdition y OpenExtensions proporcionan compatibilidad con POSIX.2 a CMS. [31] Los programas compilados para ejecutarse bajo el shell OpenExtensions se almacenan en el mismo formato que los módulos ejecutables estándar de CMS. Los editores visuales, como vi, no están disponibles, ya que los terminales 3270 no son compatibles. Los usuarios pueden utilizar ed o XEDIT en lugar de vi.
A principios de los años 1980, el grupo VM dentro de SHARE (el grupo de usuarios de IBM) buscó una mascota o logotipo para que la comunidad lo adoptara. Esto fue en parte una respuesta a la elección del pavo como mascota por parte de los usuarios de MVS de IBM (elegido, según la leyenda, por el MVS Performance Group en los primeros días de MVS, cuando su rendimiento era un tema delicado). En 1983, el osito de peluche se convirtió en la mascota de facto de VM en SHARE 60, cuando se colocaron pegatinas de ositos de peluche en las etiquetas con los nombres de los "viejos más cariñosos" para señalarlos a los recién llegados como "amistosos si se les acercaba". Los ositos fueron un éxito y pronto aparecieron por todas partes. [32] Los osos se entregaban a los miembros de la "Orden de los Caballeros de VM", individuos que hacían "contribuciones útiles" a la comunidad. [33] [34]
El concepto de hipervisor era relativamente simple. Consistía en un apéndice al programa emulador y una modificación de hardware en un Modelo 65 que tenía una función de compatibilidad. La modificación de hardware dividió el Modelo 65 en particiones, cada una direccionable de 0 a n. El apéndice del programa, tras haber superpuesto las palabras de estado del programa (PSW) del sistema con las suyas propias, se convirtió en el controlador de interrupciones para todo el sistema. Después de determinar qué partición había iniciado el evento que causaba la interrupción, el control se transfirió en consecuencia. El hipervisor requería dispositivos de E/S dedicados para cada partición y, debido a esto, las configuraciones de E/S solían ser bastante grandes y, por lo tanto, prohibitivas para la mayoría de los usos.
En un procesador real, la instrucción DIAGNOSE realiza funciones de diagnóstico dependientes del procesador. En una máquina virtual, se utiliza la interfaz DIAGNOSE para solicitar que CP realice servicios para su máquina virtual. Cuando su máquina virtual intenta ejecutar una instrucción DIAGNOSE, el control se devuelve a CP. CP utiliza la información proporcionada en la parte de código de la instrucción para determinar qué servicio debe realizar. Una vez que se proporciona este servicio, el control regresa a la máquina virtual.