Немного истории.

За время существования Единой Системы Электронных Вычислительных Машин (ЕС ЭВМ),, а это менее 30 лет и почти 17000 машин типа ИБМ МФ, было выпущено довольно видов и редакций разных ОС и одна СВМ.

Конечно ни одна из этих ОС и СВМ не были полностью уникальными разработками специалистов СЭВ (соцлагеря как принято было говорить). Но тем не менее в СССР были системы которым можно было "доверять" и иметь полную поддержку. В каждом крупном регионе СССР были региональные ПО в составе ВО СоюзЭВМкомплекса и более мелкие локальны центры. В Челябинском центре ПО "Конус" (одно из отделений СоюзЭВМкомплекс, состоявшего из ЦентрЭВМкомлекс, ЗападЭВМкомплекс, СибирьЭВМкомплес и т.д. ... и ПО "Конус") автор этой статьи проработал с августа 1984 года по апрель 1992 года в должности начальника бюро системного обеспечения.

Помню на складе у меня стояло несколько ящиков 2'x2'x2' а в них несколько бобин магнитных лент и несколько десятков книг техдокументации. Стоило это рублей этак 800 (первое что пришло на память. Точно не помню). В этих ящиках были ОС 7 ЕС. Не помню чтобы кто-то их купил, а если и купил то не забрал никто. Речь идет конечно об организациях, не частных лицах. Сами мы тоже ни одной ленты из этих ящиков не брали. У нас были гораздо более свежие версии ОС 7 ЕС непосредственно от разработчиков (НИИ ЭВМ и НИЦЭВТ). А в ящиках были какие-то старые версии.

Первое издание ОС 7 ЕС появилось в 1983 году, но распространение этой системы началось по моим воспоминаниям позже, с издания 3. К этому моменту основной системой была ОС ЕС 6.1, но уже начали появляются на ВЦ и СВМ ЕС. На виртуальных машинах под СВМ ЕС ставились ОС ЕС 6.1. При этом существенно падала производительность.

Существенно исправило это неприятное свойство виртуализации появление Базовой Операционной Системы (БОС) представлявшую основную фишку ОС 7 ЕС.

Структура ОС 7 ЕС.

ОС 7 ЕС состоит из СВМ ЕС и БОС. СВМ ЕС представлен на рисунке в составе Монитора Виртуальных Машин (Control Program CP) и Подсистемы Диалоговой Обработки (Conversational Monitor System CMS). На самом деле в составе СВМ имелось больше чем только ПДО, но это в данном случае не имеет особого значения.

Базовая Операционная Система (БОС):

..... создает ОС, являющуюся дальнейшим развитием (при обеспечении совместимости снизу вверх для программ пользователей ЭВМ) операционной среды управляющей программы SVS ОС ЕС издания 6.1. При этом она обеспечивает использование основной памяти виртуальной машины объемом до 16 Мб, но не реализует собственную виртуализацию памяти.

. Вот здесь начинается самое интересное. ОС ЕС 6.1 могла работать в одном из трех режимов: MFT, MVT и SVS. Первые два режима не образовывали виртуальной памяти и поддерживали мультипрограммую среду ("М") с фиксированным числом задач ("FT") и переменным числом задач ("VT"). SVS это режим MVT с виртуальной памятью 16 MB.

БОС была полностью программно совместима с ОС ЕС 6.1 и выполнялась только на виртуальных машинах. Как правило нескольких одновременно. Более подробно и по современному можно узнать здесь: https://phantom.sannata.org/viewtopic.php?t=42293 .

В этой статье важно то что под управлением СВМ (z/VM) существовали полноценные системы созданные специально для загрузки и работе на ВМ.

Сделано это было конечно же с целью сокращения издержек виртуализации. Первым делом под нож шел механизм виртуализации памяти. В самом деле зачем это на виртуальной машине если память ВМ и так виртуальная и ее можно сделать какой угодно. Это давало большой эффект.

Кроме того раз ВМ может быть много то не надо заморачиваться с множественными виртуальными пространствами как в Windows, Linus, и MVS (z/OS). Тем более в первом и втором случае это по всей видимости не доведено до ума до сих пор. Иначе чем объяснить стремление разделять программные комплексы на множества физических серверов и лишать себяб например, прелести коммуникаций между составными частями через память, а не через внешнюю сеть, которая не резиновая..

Но это еще не все. Вместо того чтобы грузить ОС ВМ с индивидуальных устройств загрузки, в СВМ имеется механизм хранимых систем и разделяемых сегментов. Это однажды созданные и сохраненные на диске образы памяти однажды загруженной той или иной системы с диска, остановленной и сохраненной в специальной области хранимых систем и сегментов СВМ (z/VM). После того как это сделано (однажды после инсталляции или обновления ОС ВМ), загрузка ОС ВМ происходит с хранимой системы, одной и той же для всех ВМ использующих ту или иную систему.

В ОС 7 ЕС такими системами были ПДО (CMC) и БОС (аналога в z/VM не было и нет, но есть нечто другое. Об этом ниже). Это весьма сохраняет реальную память и сокращает страничный обмен за счет того что во многих ВМ используется одна и таже копия ядра и участков памяти с кодами системных и пользовательских реентерабельных программ.

Но и это еще не все. В предыдущих статьях я, а в комментариях к ним мой коллега @SIISIIписали что ввод-вывод МФ весьма удобен и эффективен для виртуализации. Тем не менее эмуляция ввода-вывода в CP вызывает определенные издержки. В ряде случаев эти издержки можно сократить используя некоторые "договоренности" ОС ВМ с CP. Осуществляется это через инструкцию процессора МФ DIAGNOSE:

В реальном процессоре инструкция DIAGNOSE выполняет диагностические функции, зависящие от процессора. В виртуальной машине интерфейс DIAGNOSE используется для запроса на выполнение служб вашей виртуальной машины. Когда виртуальная машина пытается выполнить инструкцию DIAGNOSE, управление возвращается к CP. CP использует информацию, предоставленную в кодовой части инструкции, для определения того, какую службу следует выполнить. После выполнения этой службы управление возвращается к виртуальной машине.

Таким образом, поскольку инструкция DIAGNOSE, выполненная в виртуальной машине, приводит только к возврату управления к CP, а не к выполнению функций DIAGNOSE реального процессора, коды DIAGNOSE можно рассматривать как способ передачи требований виртуальной машины к CP.

В самом деле в среде виртуальных машин мы имеем два уровня ОС: ОС ВМ и z/VM (CP). Системные функции ОС ВМ в общем случае будут выполняться в СР. Каждая привилегированная команда будет вызывать прерывание и передачу управления СР. Ряд типовых функций любой ОС МФ может быть и в самом деле делегируется для выполнения в СР.

Почему инструкция DIAGNOSE? В ОС реальной машина на МФ для вызова системных функций используется непривилегированная команда SVC (Supervisor Call). Хотя эта инструкция и не привилегированная она вызывает прерывание работы процессора, т.н. SVC прерывание. Оно обрабатывается как и любое другое прерывание, а именно аппаратное переключение в режим Супервизор и передачу управления обработчику SVC прерываний. Обработчик SVC прерывания ОС использует код прерывания (номер SVC - параметр инструкции SVC) для передачи управления программе обработчику кода прерывания. Для этого ядро ОС использует таблицу кодов SVC. В этой таблице входом является код SVC, выходом адрес обработчика кода.

В условиях системы виртуальных машин (z/VM/CP) SVC прерывание в ВМ "отражается" в ОС ВМ, и управление передается не обработчику SVC прерываний СР, а обработчику SVC прерываний ОС ВМ.

Поэтому использовать обычный путь вызова CP через SVC не представляется возможным. Для этого используется инструкция DIAGNOSE как опсано выше в цитате. А именно вызывает прерывание по привилегированной инструкции и передачу управления СР. СР анализирует код, сопровождающий инструкцию DIAGNOSE, и передает управление соответствующей программе обработчику кода также как описано выше для SVC.

Я насчитал примерно 70 кодов инструкции DIAGNOSE распознаваемых CP. Вот пара примеров:

Код DIAGNOSE X'2A8' устанавливает сетевое соединение на имитируемом сетевом устройстве z/VM® для передачи и приёма Ethernet-кадров. Он предоставляет виртуальной машине аппаратно-независимый доступ к имитируемой сетевой карте, созданной с помощью команды CP DEFINE NIC, которая связана с гостевой локальной сетью Ethernet VSWITCH или Ethernet QDIO командой CP COUPLE.

Используйте код DIAGNOSE X'60' для определения установленного размера хранилища вашей виртуальной машины, то есть для определения размера первичного адресного пространства хоста вашей виртуальной машины, исключая любые несмежные сохраненные сегменты или памяти хранимых систем, загруженное сверх определенного размера.

Есть служба коммуникации между виртуальными машинами. Без выхода во внешнюю или внутреннюю сеть. Широко используется в конфигурациях когда несколько машин объединяются в комплекс (не кластер) для выполнения сложных работ. Также используется для внутрисистемного обслуживания по типу клиент-сервер:

The Inter-User Communications Vehicle (IUCV) — это средство связи, позволяющее программе, работающей в виртуальной машине, взаимодействовать с другими виртуальными машинами, со службой системы CP и самой собой. Обмен данными по IUCV осуществляется между исходным и целевым коммуникаторами. Взаимодействие осуществляется по предопределенному каналу связи, называемому путем. Каждый коммуникатор может иметь несколько путей и может одновременно получать или отправлять несколько сообщений по одному и тому же пути.

Есть и другие службы СР, которыми может пользоваться любая ВМ. Всё вместе это называется средства сотрудничества. Эти средства не только уменьшают издержки виртуализации, но и создают возможности извлекать из виртуализации больше чем всего лишь возможность запускать на одном сервере много виртуальных машин. Пусть даже с возмоностью мигрировать ВМ с одного сервера на другой.

Но для этого надо чтобы ОС ВМ их использовали. В некоторых случаях делалось так что ОС ВМ различала что она запускается не на реальной, а на виртуальной машине и в этом случае использовала средства сотрудничества. В противном случае нет.

Другие ОС изначально разрабатывались для ВМ и не могли быть загружены на реальной машине. В ОС 7 ЕС это БОС и ПДО. В z/VM это CMS и GCS - Group Control System - усеченный по функциональности, но оптимизированный вариант MVS для ВМ.

Заключение.

В статье показано наличие в z/VM широкого спектра средств сотрудничества ВМ с СР и между собой. Таким образом к ранее сделанному определению о полной виртуализации как полном функциональном аналоге реальной машины можно добавить наличие средств сотрудничества внутри системы виртуальных машин со всеми ее составными частями.

Отсутствие средств сотрудничества говорит об ущербности той или иной системы виртуализации машин.