VM (часто: VM/CMS ) — семейство операционных систем виртуальных машин IBM , используемых на мэйнфреймах IBM System/370 , System/390 , zSeries , System z и совместимых системах, включая эмулятор Hercules для персональных компьютеров.
Сердцем архитектуры VM является управляющая программа или гипервизор, сокращенно CP, VM-CP и иногда, двусмысленно, VM. Она работает на физическом оборудовании и создает среду виртуальной машины . VM-CP обеспечивает полную виртуализацию физической машины, включая все операции ввода-вывода и другие привилегированные операции. Она выполняет совместное использование ресурсов системы, включая управление устройствами, диспетчеризацию, управление виртуальным хранилищем и другие традиционные задачи операционной системы. Каждому пользователю VM предоставляется отдельная виртуальная машина, имеющая собственное адресное пространство , виртуальные устройства и т. д., и которая способна запускать любое программное обеспечение, которое может быть запущено на автономной машине. Данный мэйнфрейм VM обычно запускает сотни или тысячи экземпляров виртуальных машин. VM-CP начал свою жизнь как CP-370, повторная реализация CP-67 , которая сама является повторной реализацией CP-40 .
Внутри каждой виртуальной машины работает другая операционная система, гостевая операционная система . Это может быть:
Известны следующие версии:
CMS в названии относится к Conversational Monitor System — компоненту продукта, представляющему собой однопользовательскую операционную систему, работающую на виртуальной машине и обеспечивающую разделение времени для разговоров в виртуальной среде.
IBM ввела термин «гипервизор» для 360/65 [13] и позже использовала его для обработчика DIAG CP-67.
Инструкция Diagnose ('83'x — без мнемоники) — это привилегированная инструкция, изначально предназначенная IBM для выполнения «встроенных диагностических функций или других функций, зависящих от модели». [14] IBM перепрофилировала DIAG для «связи между виртуальной машиной и CP». [15] [16] Инструкция содержит два четырехбитных номера регистра, называемых Rx и Ry, которые могут «содержать адреса хранения операндов или коды возврата, передаваемые интерфейсу DIAGNOSE», и двухбайтовый код, «который CP использует для определения того, какую функцию DIAGNOSE выполнять». [15] Доступные функции диагностики включают в себя:
Когда-то CMS могла работать на голой машине , как настоящая операционная система (хотя такая конфигурация была бы необычной). Теперь она работает только как гостевая ОС под VM. Это связано с тем, что CMS использует интерфейс гипервизора для VM-CP для выполнения операций с файловой системой и запроса других служб VM. Этот интерфейс паравиртуализации :
CMS и другие операционные системы часто предъявляют требования к DASD, намного меньшие, чем размеры реальных томов. По этой причине CP позволяет установке определять виртуальные диски любого размера вплоть до емкости устройства. Для томов CKD минидиск должен быть определен в полных цилиндрах. Минидиск имеет те же атрибуты, что и базовый реальный диск, за исключением того, что он обычно меньше, а начало каждого минидиска отображается на цилиндр или блок 0. К минидиску можно [a] получить доступ с помощью тех же канальных программ , что и к реальному диску.
Мини-диск, инициализированный с помощью файловой системы CMS, называется мини-диском CMS, хотя CMS — не единственная система, которая может их использовать.
Обычной практикой является определение минидисков полного тома для использования такими гостевыми операционными системами, как z/OS, вместо DEDICATEназначения тома определенной виртуальной машине. Кроме того, «ссылки полного пакета» часто определяются для каждого DASD в системе и принадлежат пользователю MAINT. Они используются для резервного копирования системы с помощью программы DASD Dump/Restore, где все содержимое DASD записывается на ленту (или другой DASD) в точности.
В современных версиях виртуальных машин большую часть системы можно установить на SFS, а несколько оставшихся мини-дисков — это те, которые абсолютно необходимы для запуска системы и принадлежат машинам-серверам файлового пула.
VM/SP Release 6 представила Shared File System [17] , которая значительно улучшила возможности хранения файлов CMS. Файловая система мини-дисков CMS вообще не поддерживает каталоги (папки), однако SFS поддерживает. SFS также вводит более гранулярную безопасность. С помощью мини-дисков CMS система может быть настроена на разрешение или запрет пользователям доступа только для чтения или чтения-записи к диску, но отдельные файлы не могут иметь ту же безопасность. SFS смягчает это и значительно повышает производительность.
SFS предоставляется виртуальными машинами служб. В современной системе VM обычно требуются три: VMSERVR, «машина восстановления», которая на самом деле не обслуживает никаких файлов; VMSERVS, сервер для пула файлов VMSYS; и VMSERVU, сервер для пула файлов VMSYSU (пользователь). [18] Машины сервера пула файлов владеют несколькими мини-дисками, обычно включая CMS A-диск (адрес виртуального устройства 191, содержащий файлы конфигурации пула файлов), управляющий диск, диск журнала и любое количество дисков данных, которые фактически хранят пользовательские файлы.
Если учетная запись пользователя настроена только на использование SFS (и не владеет ни одним мини-диском), A-диск пользователя будет FILEPOOL:USERID.и любые последующие каталоги, которые пользователь создаст, будут FILEPOOL:USERID.DIR1.DIR2.DIR3там, где эквивалентный путь к файлу UNIX — /dir1/dir2/dir3. Каталоги SFS могут иметь гораздо более детальный контроль доступа по сравнению с мини-дисками (которые, как упоминалось выше, часто могут иметь только пароль на чтение, пароль на запись и пароль на множественную запись). Каталоги SFS также решают проблемы, которые могут возникнуть, когда два пользователя одновременно записывают на один и тот же мини-диск CMS, что может привести к повреждению диска (поскольку виртуальная машина CMS, выполняющая запись, может не знать, что другой экземпляр CMS также записывает на мини-диск).
Машины сервера пула файлов также обслуживают тесно связанную файловую систему: Byte File System. BFS используется для хранения файлов в файловой системе в стиле UNIX. Ее основное применение — среда VM OpenExtensions POSIX для CMS. Сами виртуальные машины пользователей CMS взаимодействуют с виртуальными машинами сервера SFS через механизм IUCV. [19]
Ранняя история VM описана в статьях CP/CMS и History of CP/CMS . VM/370 является повторной реализацией CP/CMS и была выпущена в 1972 году как часть анонса IBM System/370 Advanced Function (который добавил виртуальную память и операционные системы к серии System/370 ). Ранние выпуски VM до VM/370 Release 6 продолжались в открытом исходном коде до 1981 года и сегодня считаются находящимися в общественном достоянии . Эта политика закончилась в 1977 году с платными обновлениями VM/SE и VM/BSE и в 1980 году с VM/System Product (VM/SP). Тем не менее, IBM продолжала предоставлять обновления в исходном виде для существующего кода в течение многих лет, хотя обновления для всех, кроме бесплатной базы, требовали лицензии. Как и в случае с CP-67, привилегированные инструкции в виртуальной машине вызывают прерывание программы, и CP имитировала поведение привилегированной инструкции. VM оставалась важной платформой в IBM, используемой для разработки операционных систем и использования в режиме разделения времени; но для клиентов она оставалась «другой операционной системой» IBM. Семейства ОС и DOS оставались стратегическими продуктами IBM, и клиентов не поощряли использовать VM. Те, кто это делал, сформировали тесные рабочие отношения, продолжая модель поддержки сообщества ранних пользователей CP/CMS. Тем временем система боролась с политическими распрями внутри IBM по поводу того, какие ресурсы должны быть доступны проекту по сравнению с другими усилиями IBM. Основная проблема с системой была замечена на уровне полевых продаж IBM: VM/CMS явно сокращала количество оборудования, необходимого для поддержки заданного числа пользователей в режиме разделения времени. IBM, в конце концов, занималась продажей компьютерных систем.
Мелинда Вариан приводит следующую захватывающую цитату, иллюстрирующую неожиданный успех VM: [20]
Маркетинговые прогнозы для VM/370 предсказывали, что не более одного 168 когда-либо будет работать под управлением VM в течение всего срока службы продукта. Фактически, первые 168, поставленные заказчику, работали только под управлением CP и CMS. Десять лет спустя десять процентов крупных процессоров, поставляемых из Покипси, будут предназначены для работы под управлением VM, как и весьма значительная часть машин среднего класса, которые будут построены в Эндикотте. Не прошло и пятнадцати лет, как лицензий VM будет больше, чем лицензий MVS.
Версия PC DOS , которая запускает CMS на XT/370 (и позже на AT/370), называется VM/PC. VM/PC 1.1 была основана на VM/SP release 3. Когда IBM представила процессорные карты P/370 и P/390, ПК теперь мог запускать полноценные системы VM, включая VM/370, VM/SP, VM/XA и VM/ESA (эти карты были полностью совместимы с мэйнфреймами S/370 и S/390 и могли запускать любую операционную систему S/370 из 31-битной эпохи, например, MVS/ESA, VSE/ESA).
В дополнение к базовым выпускам VM/SP, IBM также представила VM/SP HPO (High Performance Option). Это дополнение (устанавливаемое поверх базового выпуска VM/SP) улучшило несколько ключевых системных возможностей, включая возможность использования более 16 МБ памяти (ОЗУ) на поддерживаемых моделях (например, IBM 4381). С установленным VM/SP HPO новый предел составлял 64 МБ; однако один пользователь (или виртуальная машина) не мог использовать более 16 МБ. Функции файловой системы спула также были улучшены, что позволило создать 9900 файлов спула для одного пользователя, а не 9900 для всей системы. Архитектура файловой системы спула также была улучшена, каждый файл спула теперь имел уникальный идентификатор пользователя, связанный с ним, а блоки управления файлами чтения теперь хранились в виртуальном хранилище. Систему также можно было настроить на запрет доступа определенных пользователей к векторному объекту (с помощью записей в каталоге пользователя). [6]
Выпуски VM, начиная с VM/SP Release 1, поддерживали многопроцессорные системы. Версии System/370 VM (такие как VM/SP и VM/SP HPO) поддерживали максимум два процессора, при этом система работала в режиме UP (однопроцессорный), MP (многопроцессорный) или AP (присоединенный процессор). [21] Режим AP аналогичен режиму MP, за исключением того, что второй процессор не имеет возможности ввода-вывода. Выпуски System/370-XA VM (такие как VM/XA) поддерживали больше. Выпуски System/390 (такие как VM/ESA) почти полностью сняли ограничение, и некоторые современные системы z/VM могут иметь до 80 процессоров. [22] Лимит на VM для определенных процессоров составляет 64.
Когда IBM представила System/370 Extended Architecture на 3081 , клиенты столкнулись с необходимостью запускать производственную систему MVS/370 во время тестирования MVS/XA на той же машине. Решением IBM стало VM/XA Migration Aid, которое использовало новую инструкцию Start Interpretive Execution (SIE) для запуска виртуальной машины. SIE автоматически обрабатывал некоторые привилегированные инструкции и возвращался к CP в случаях, когда он не мог обработать. Processor Resource/System Manager (PR/SM) более позднего 3090 также использовал SIE. Было несколько продуктов VM/XA, прежде чем он был в конечном итоге вытеснен VM/ESA и z/VM.
В дополнение к сетям RSCS IBM также предоставила пользователям сети VTAM . ACF/VTAM для VM был полностью совместим с ACF/VTAM на MVS и VSE. [23] Как и RSCS, VTAM на VM работал под управлением специализированной операционной системы GCS. Однако VM также поддерживала сети TCP/IP. В конце 1980-х годов IBM выпустила стек TCP/IP для VM/SP и VM/XA. [24] Стек поддерживал сети IPv4 и различные системы сетевых интерфейсов (такие как межсетевые соединения каналов между мэйнфреймами или специализированный IBM RT PC, который ретранслировал трафик в сеть Token Ring или Ethernet ). Стек обеспечивал поддержку соединений Telnet либо с простых эмуляторов терминалов линейного режима, либо с эмуляторов, совместимых с VT100, либо с надлежащих эмуляторов терминалов IBM 3270. Стек также предоставлял FTP-сервер. IBM также выпустила дополнительный сервер NFS для VM; ранние версии были довольно примитивными, но современные версии намного более продвинуты. [25]
Также существовал четвертый вариант сети, известный как VM/Pass-Through Facility (или более часто называемый PVM). PVM, как и VTAM, позволял подключаться к удаленным системам VM/CMS, а также к другим системам IBM. [26] Если два узла VM/CMS были связаны между собой по каналу-каналу или бисинхронному каналу (возможно, с использованием модема коммутируемой линии или выделенной линии), пользователь мог удаленно подключиться к любой из систем, введя «DIAL PVM» на экране входа в VM, а затем введя имя системного узла (или выбрав его из списка доступных узлов). В качестве альтернативы пользователь, работающий с CMS, мог использовать программу PASSTHRU, которая была установлена вместе с PVM, что позволяло быстро получать доступ к удаленным системам без необходимости выхода из сеанса пользователя. PVM также поддерживал доступ к не-VM системам, используя технику эмуляции 3x74. Более поздние выпуски PVM также включали компонент, который мог принимать соединения из сети SNA .
VM также была краеугольным камнем операционной системы BITNET , поскольку система RSCS, доступная для VM, обеспечивала простую сеть, которую было легко реализовать и которая была достаточно надежной. Сайты VM были связаны между собой посредством RSCS VM на каждой системе VM, взаимодействующей друг с другом, и пользователи могли отправлять и получать сообщения, файлы и пакетные задания через RSCS. Команда "NOTE" использовала XEDIT для отображения диалогового окна для создания электронного письма, из которого пользователь мог его отправить. Если пользователь указывал адрес в виде user at node, файл электронного письма доставлялся в RSCS, который затем доставлял его целевому пользователю в целевой системе. Если на сайте установлен TCP/IP, RSCS мог работать с машиной службы SMTP для доставки заметок (электронных писем) удаленным системам, а также для их получения. Если пользователь указывал user at some.host.name, программа NOTE доставляла электронное письмо на машину службы SMTP, которая затем направляла его на целевой сайт в Интернете.
Роль VM изменилась в IBM, когда эволюция оборудования привела к значительным изменениям в архитектуре процессора. Обратная совместимость осталась краеугольным камнем семейства мэйнфреймов IBM , которое по-прежнему использует базовый набор инструкций, представленный в оригинальной System/360 ; но потребность в эффективном использовании 64-битной zSeries сделала подход VM гораздо более привлекательным. VM также использовалась в центрах обработки данных, переходящих с DOS/VSE на MVS, и полезна при работе мэйнфреймов AIX и Linux , платформ, которые должны были стать все более важными. Текущая платформа z/VM наконец-то получила признание в IBM, которое пользователи VM давно считали заслуженным. Некоторые сайты z/VM одновременно запускают тысячи пользователей виртуальных машин на одной системе. z/VM была впервые выпущена в октябре 2000 года [27] и продолжает активно использоваться и развиваться.
IBM и третьи стороны предложили множество приложений и инструментов, работающих под управлением VM. Примерами являются RAMIS , FOCUS , SPSS , NOMAD , DB2 , REXX , RACF и OfficeVision . Текущие предложения VM охватывают весь спектр приложений для мэйнфреймов, включая HTTP- серверы, менеджеры баз данных, инструменты анализа, инженерные пакеты и финансовые системы.
Начиная с версии 6, программа управления VM/370 имеет ряд команд для обычных пользователей, связанных с определением и управлением виртуальной машиной пользователя. Части команды в нижнем регистре необязательны [28]
Начиная с VM/ESA Version 2, IBM представила платную дополнительную функцию OpenEdition для VM/ESA Shell and Utilities Feature , [29] которая обеспечивает совместимость с POSIX для CMS. Выдающейся функцией была оболочка UNIX для CMS. Компилятор C для этой среды UNIX предоставляется либо C/370, либо C для VM/ESA. Ни файловая система CMS, ни стандартная VM Shared File System не поддерживают файлы и пути в стиле UNIX; вместо этого используется Byte File System. После создания экстента BFS в файловом пуле SFS пользователь может смонтировать его с помощью OPENVM MOUNT /../VMBFS:fileservername:filepoolname /path/to/mount/point. Пользователь также должен смонтировать корневую файловую систему, что делается с помощью OPENVM MOUNT /../VMBFS:VMSYS:ROOT/ /, затем можно запустить оболочку с помощью OPENVM SHELL. В отличие от обычной SFS, доступ к файловым системам BFS контролируется разрешениями POSIX (с помощью chmod и chown ).
Начиная с z/VM Version 3, IBM интегрировала OpenEdition в z/VM [30] и переименовала его в OpenExtensions. OpenEdition и OpenExtensions обеспечивают соответствие POSIX.2 для CMS. [31] Программы, скомпилированные для запуска в оболочке OpenExtensions, хранятся в том же формате, что и стандартные исполняемые модули CMS. Визуальные редакторы, такие как vi, недоступны, поскольку терминалы 3270 не поддерживают их. Пользователи могут использовать ed или XEDIT вместо vi.
В начале 1980-х годов группа VM в SHARE (группа пользователей IBM) искала талисман или логотип для принятия сообществом. Это было отчасти ответом на то, что пользователи MVS IBM выбрали индейку в качестве талисмана (выбранную, согласно легенде, MVS Performance Group в первые дни MVS, когда ее производительность была больной темой). В 1983 году плюшевый мишка стал фактическим талисманом VM на SHARE 60, когда наклейки с плюшевым мишкой были прикреплены к бейджам «старичков-милых», чтобы пометить их для новичков как «дружелюбных, если к ним подойти». Медведи стали хитом и вскоре появились широко. [32] Медведями награждали членов «Ордена рыцарей VM», людей, которые внесли «полезный вклад» в сообщество. [33] [34]
Концепция гипервизора была относительно простой. Она состояла из дополнения к программе эмулятора и аппаратной модификации на модели 65 с функцией совместимости. Аппаратная модификация разделила модель 65 на разделы, каждый из которых адресулся от 0 до n. Программное дополнение, наложив системные слова состояния программы (PSW) на свои собственные, стало обработчиком прерываний для всей системы. После определения того, какой раздел инициировал событие, вызывающее прерывание, управление передавалось соответствующим образом. Гипервизору требовались выделенные устройства ввода-вывода для каждого раздела, и из-за этого конфигурации ввода-вывода обычно были довольно большими и, следовательно, не подходили для большинства случаев использования.
В реальном процессоре инструкция DIAGNOSE выполняет зависящие от процессора диагностические функции. В виртуальной машине вы используете интерфейс DIAGNOSE, чтобы запросить, чтобы CP выполнил службы для вашей виртуальной машины. Когда ваша виртуальная машина пытается выполнить инструкцию DIAGNOSE, управление возвращается CP. CP использует информацию, предоставленную в кодовой части инструкции, чтобы определить, какую службу он должен выполнить. После предоставления этой службы управление возвращается виртуальной машине.