VM (a menudo: VM/CMS ) es una familia de sistemas operativos de máquinas virtuales IBM utilizados en mainframes IBM System/370 , System/390 , zSeries , System z y sistemas compatibles, incluido el emulador Hercules para computadoras personales.
Se conocen las siguientes versiones:
El CMS en el nombre se refiere al Conversational Monitor System, 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 VM.
El corazón de la arquitectura VM es el Programa de Control o hipervisor abreviado CP , VM-CP y, en ocasiones, 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 E/S y otras operaciones privilegiadas. Realiza el intercambio de recursos del sistema, incluida la administración de dispositivos, el envío, la administración de almacenamiento virtual y otras tareas tradicionales del sistema operativo. A cada usuario de VM se le proporciona una máquina virtual separada 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áquinas virtuales. VM-CP comenzó su vida como CP-370, una reimplementación de CP-67 , que a su vez era una reimplementación de CP-40 .
Dentro de cada máquina virtual se ejecuta otro sistema operativo, un sistema operativo invitado . Esto podría ser:
IBM acuñó el término hipervisor para 360/65 [13] y luego lo usó para el controlador DIAG de CP-67.
La instrucción Diagnóstico ('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 reutilizó DIAG para "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 de DIAGNÓSTICO realizar." [15] A continuación se enumeran algunas de las funciones de diagnóstico disponibles.
Hubo un tiempo en que CMS era capaz de ejecutarse en una máquina básica , como un verdadero sistema operativo (aunque tal configuración sería inusual). Ahora se ejecuta sólo como sistema operativo invitado en VM. Esto se debe a que CMS se basa en una interfaz de hipervisor para VM-CP para realizar operaciones del sistema de archivos y solicitar otros servicios de VM. 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 esta razón CP permite que una instalación defina discos virtuales de cualquier tamaño hasta la capacidad del dispositivo. Para volúmenes CKD, se debe definir un minidisco en cilindros completos. Un minidisco tiene los mismos atributos que el disco real subyacente, excepto que generalmente es más pequeño y el comienzo de cada minidisco está asignado al cilindro o bloque 0. Se puede acceder al minidisco usando 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 utilizarlos.
Es una práctica común definir minidiscos de volumen completo para su uso en sistemas operativos invitados como z/OS en lugar de usarlos DEDICATEpara asignar el volumen a una máquina virtual específica. Además, los "enlaces de paquete completo" a menudo se definen para cada DASD del sistema y son propiedad del ID de usuario MAINT. Estos se utilizan para hacer una copia de seguridad del sistema usando el programa DASD Dump/Restore, donde todo el contenido de un DASD se escribe exactamente en una cinta (u otro DASD).
VM/SP versión 6 introdujo el sistema de archivos compartido [17] que mejoró enormemente las capacidades de almacenamiento de archivos CMS. El sistema de archivos de minidisco CMS no admite directorios (carpetas) en absoluto; sin embargo, SFS sí. SFS también introduce una seguridad más granular. Con los minidiscos CMS, el sistema se puede configurar para permitir o denegar a los usuarios acceso de solo lectura o 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 máquinas virtuales de servicio. En un sistema 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 del servidor del grupo de archivos poseen varios minidiscos, que generalmente incluyen un disco A 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 número de discos de datos que realmente almacenan. Archivos de usuario.
Con las versiones modernas de VM, la mayor parte del sistema se puede instalar en SFS, siendo los pocos minidiscos restantes los absolutamente necesarios para que el sistema se inicie y los que pertenecen a las máquinas del servidor del grupo de archivos.
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 se encuentre 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 daños en el disco (ya que la máquina virtual CMS que realiza las escrituras puede no saber que otra instancia CMS también está escribiendo en el minidisco). .
Las máquinas servidor del grupo 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 estilo UNIX. Su uso principal es para el entorno VM OpenExtensions POSIX para CMS. Las propias máquinas virtuales de los usuarios 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 e Historia de CP/CMS . VM/370 es una reimplementación de CP/CMS y estuvo disponible en 1972 como parte del anuncio de función avanzada System/370 de IBM (que agregó hardware de memoria virtual y sistemas operativos a la serie System/370 ). Las primeras versiones de VM hasta VM/370 versión 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 VM/SE y VM/BSE y en 1980 con VM/Producto del sistema (VM/SP). Sin embargo, IBM continuó proporcionando actualizaciones en formato fuente para el código existente durante muchos años, aunque las actualizaciones de todos menos la base gratuita requerían una licencia. Al igual que con CP-67, las instrucciones privilegiadas en una máquina virtual provocan una interrupción del programa y CP simuló el comportamiento de la instrucción privilegiada.
VM siguió siendo una plataforma importante dentro de IBM, utilizada para el desarrollo de sistemas operativos y uso de tiempo compartido; pero para los clientes seguía siendo el "otro sistema operativo" de IBM. Las familias OS y DOS siguieron siendo los productos estratégicos de IBM y no se animaba a los clientes a ejecutar VM. Aquellos que lo hicieron formaron estrechas relaciones de trabajo, continuando el modelo de apoyo comunitario de los primeros usuarios de CP/CMS. Mientras tanto, el sistema luchaba con 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 observó en el nivel de ventas de campo de IBM: VM/CMS redujo de manera demostrable la cantidad de hardware necesaria para soportar un número determinado de usuarios de tiempo compartido. Después de todo, IBM se dedicaba a la venta de sistemas informáticos.
Melinda Varian ofrece esta fascinante cita que ilustra el inesperado éxito de VM:
Las previsiones de marketing para VM/370 predijeron que no más de un 168 ejecutaría VM durante toda la vida útil del producto. De hecho, los primeros 168 entregados a un cliente sólo ejecutaban CP y CMS. Diez años más tarde, el diez por ciento de los grandes procesadores que se enviaban desde Poughkeepsie estarían destinados a ejecutar VM, al igual que una parte muy sustancial de las máquinas de gama media que se construyeron en Endicott. Antes de que pasaran quince años, habría más licencias de VM que de MVS. [20]
Una versión de PC DOS que ejecuta CMS en el XT/370 (y posteriormente en el AT/370) se llama VM/PC. VM/PC 1.1 se basó en la versión 3 de VM/SP. Cuando IBM introdujo las tarjetas de procesador P/370 y P/390, una PC ahora podía ejecutar sistemas VM completos, incluidos VM/370, VM/SP, VM/XA y VM/ESA (estas tarjetas eran totalmente compatibles con 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 básicas de VM/SP, IBM también presentó VM/SP HPO (opción de alto rendimiento). Este complemento (que se instala sobre la versión base VM/SP) mejoró varias funciones clave del sistema, incluido permitir el uso de más de 16 MB de almacenamiento (RAM) en modelos compatibles (como el IBM 4381). Con VM/SP HPO instalado, el nuevo límite era 64 MB; sin embargo, un solo usuario (o máquina virtual) no puede utilizar más de 16 MB. También se mejoraron las funciones del sistema de archivos spool, permitiendo crear 9900 archivos spool por usuario, en lugar de 9900 para todo el sistema. También se mejoró la arquitectura del sistema de archivos spool, cada archivo spool ahora tenía una identificación de usuario única asociada y los bloques de control de archivos del lector ahora se guardaban en un almacenamiento virtual. El sistema también podría configurarse para negar a ciertos usuarios el acceso a la instalación de vectores (mediante entradas del directorio de usuarios). [3]
Las versiones de VM desde VM/SP Versión 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 (uniprocesador), 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) son más compatibles. Las versiones System/390 (como VM/ESA) casi eliminaron el límite por completo, 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 manejó automáticamente algunas instrucciones privilegiadas y las devolvió a CP en los casos que no podía manejar. El Administrador de recursos/sistema del procesador (PR/SM) del último 3090 también usaba SIE. Hubo varios productos VM/XA antes de que finalmente fuera reemplazado por VM/ESA y z/VM.
Además de las redes RSCS , IBM también proporcionó a los usuarios redes VTAM . ACF/VTAM para VM era totalmente compatible con ACF/VTAM en MVS y VSE. [23] Al igual que RSCS, VTAM en VM se ejecutó bajo el sistema operativo especializado GCS. Sin embargo, VM también admitía redes TCP/IP. A finales 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 de canal a canal entre mainframes o una PC IBM RT especializada que retransmitiría el tráfico a una red Token Ring o Ethernet ). La pila proporcionó soporte para conexiones Telnet , ya sea desde emuladores de terminal en modo de línea simples o emuladores compatibles con VT100, o emuladores de terminal IBM 3270 adecuados. La pila también proporcionó 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 había una cuarta opción de red, conocida como VM/Pass-Through Facility (o más comúnmente llamada PVM). PVM, como VTAM, permitía conexiones a sistemas VM/CMS remotos, así como a otros sistemas IBM. [26] Si dos nodos VM/CMS estuvieran vinculados entre sí a través de un enlace de canal a canal o un enlace bisincrónico (posiblemente usando un módem de acceso telefónico o una línea arrendada), un usuario podría conectarse de forma remota a cualquiera de los sistemas ingresando "DIAL PVM" en el pantalla de inicio de sesión de VM, luego ingrese el nombre del nodo del sistema (o elíjalo de una lista de nodos disponibles). Alternativamente, un usuario que ejecute CMS podría usar el programa PASSTHRU que se instaló junto con PVM, lo que permite 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 eran VM mediante la utilización de una técnica de emulación 3x74. Las versiones posteriores de PVM también incluyeron 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 simple, fácil de implementar y algo confiable. Los sitios de VM estaban interconectados mediante 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 "NOTA" usaba XEDIT para mostrar un cuadro de diálogo para crear un correo electrónico, desde el cual el usuario podía enviarlo. Si el usuario especificaba una dirección en formato 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 del servicio SMTP para entregar notas (correos electrónicos) a sistemas remotos, así como también recibirlas. Si el usuario especifica user at some.host.name, el programa NOTA entregará el correo electrónico a la máquina del servicio SMTP, que luego lo enrutará al sitio de destino en Internet.
El papel de la 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 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 zSeries de 64 bits hizo que el enfoque de 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 ejecuta mainframe AIX y Linux , plataformas que llegarían a ser cada vez más importantes. La actual plataforma z/VM 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áneamente en un único sistema. z/VM se lanzó por primera vez en octubre de 2000 [27] y permanece en uso y desarrollo activo.
IBM y terceros han ofrecido muchas aplicaciones y herramientas que se ejecutan en VM. Los 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 definir y controlar la máquina virtual del usuario. Las partes en minúsculas del comando son opcionales [28]
A partir de VM/ESA Versión 2, IBM introdujo la característica opcional de pago OpenEdition para 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 de C para este entorno UNIX lo proporciona C/370 o C para VM/ESA. Ni el sistema de archivos CMS ni el sistema de archivos compartido VM estándar son compatibles con archivos y rutas de estilo UNIX; en su lugar, se utiliza el sistema de archivos de bytes. Una vez que se crea una extensión BFS en un grupo de archivos SFS, el usuario puede montarla usando el archivo 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 z/VM Versión 3, IBM integró OpenEdition en z/VM [30] y le cambió el nombre a OpenExtensions. OpenEdition y OpenExtensions proporcionan compatibilidad con POSIX.2 para CMS. [31] Los programas compilados para ejecutarse bajo el shell OpenExtensions se almacenan en el mismo formato que los módulos ejecutables CMS estándar. Los editores visuales, como vi, no están disponibles, ya que los terminales 3270 no son compatibles. Los usuarios pueden usar ed o XEDIT en lugar de vi.
A principios de la década de 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 que los usuarios de MVS de IBM seleccionaran al pavo como mascota (elegido, según la leyenda, por MVS Performance Group en los primeros días de MVS, cuando su rendimiento era un tema delicado). En 1983, el oso 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 "veteranos más cariñosos" para señalarlos a los recién llegados como "amigables si se les acercaba". Los osos fueron un éxito y pronto aparecieron ampliamente. [32] Los osos se otorgaron a los miembros de la "Orden de los Caballeros de VM", personas que hicieron "contribuciones útiles" a la comunidad. [33] [34]
Si bien VM era relativamente liviano (en comparación con sus contrapartes, como MVS), VM era algo inestable en sus inicios. Se consideró toda una hazaña mantener un sistema VM/370 en funcionamiento durante más de una semana. Los usuarios también criticaron el sistema de archivos CMS, señalando que otros sistemas operativos de mediados de la década de 1980 tenían directorios, enlaces simbólicos y otras características clave; CMS no tuvo nada de esto hasta 1988, cuando salió la versión 6 de VM/SP, que introdujo el sistema de archivos compartido y alivió estos problemas.
Algunos usuarios también notaron que VM OpenEdition era algo "innecesario".
El concepto de hipervisor era relativamente simple. Consistía en un complemento al programa emulador y una modificación del hardware en un Modelo 65 que tenía una función de compatibilidad. La modificación del hardware dividió el Modelo 65 en particiones, cada una de ellas direccionable de 0 a n. El apéndice del programa, que superpuso 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 provocó la interrupción, se transfirió el control en consecuencia. El hipervisor requería dispositivos de E/S dedicados para cada partición y, debido a esto, las configuraciones de E/S generalmente eran 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, 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 regresa al CP. CP utiliza la información proporcionada en la parte del código de la instrucción para determinar qué servicio debe realizar. Una vez que se proporciona este servicio, el control vuelve a la máquina virtual.