Краткая, упрощенная история виртуальных машин
На IBM mainframe
Первые шаги того что нынче известно как zVM были сделаны в конце 60х, почти 60 лет назад. И это началось спустя всего 3-4 года как появилась архитектура s/360 - первых мэйнфрэймов. Могло бы произойти и раньше. Не хватало только виртуальной памяти. Все остальное в архитектуре S/360 уже было тогда доступно для виртуализации машины, т.е. самого компьютера S/360.
Этот недостаток был устранен в модели IBM System/360 model 67 поставки которых начались в мае 1966 года. Строго говоря в названии первых продуктов занимавшихся виртуализацией не было словосочетания "виртуальная машина". Использовался термин Time Sharing (TSS) и Control Program (CP). Разделение времени было необходимо и востребовано для повышения используемости первых мэйнфрэймов, которые изначально предназначались исключительно для пакетной обработки заданий. Но это не значит что такое расширение предполагалось исключительно для диалоговых работ. Об этом ниже.
Первый продукт завоевавший большее признание (их было больше одного изначально) назывался CP/CMS. Создана она была в IBM's Cambridge Scientific Center (CSC). В 1972 году с появлением S/370 CP/CMS была переименована в VM/370. Базовыми компонентами VM/370 были и остаются в настоящее время CP (Control Program) и СMS.(Conversational Monitor System известная также как Cambridge Monitor System и Console Monitor System). Но обозначился явно, в названии, термин "виртуальная машина" уточнивший что основой системы разделения времени является виртуализация реальной машины, а не что-то иное. А что-то иное могло быть традиционной многозадачной и многопользовательской системой типа MVS (Multiple Virtual Storage). Впрочем это вскоре и произошло, в 1974 году. Т.е. вместе с появлением виртуальных машин на мэйнфрэйм появилась и мощная традиционная много- много- система, в итоге доказавшая что виртуальные машины это далеко не панацея.
Но вернемся к теме статьи. CMS это однозадачная однопользовательская ОС. Была таковой изначально и остается такой же сейчас. Фишка была и есть в том что такая система имеет меньше издержек на виртуальной машине, а многозадачность и многопользовательность достигается множеством виртуальных машин под управлением CP (Control Program) или в современной терминологии "hypervisor". CMS использует "короткие" связи с CP (аналог APIs) и поэтому не может выполняться на реальной машине. "Короткие" связи (interface DIAG command) существо снижает издержки виртуализации. Этот интерфейс может использоваться любой программой и ОС выполняемой на виртуальной машине.
На серверах х86-64
А что мы видим в истории системного ПО на серверах х86-64. Сначала появилась однопользовательская, однозадачная DOS (MS-DOS. PC-DOS) потом началась разработка многозадачной OS/2, в значительной степени торпедированная Microsoft их графической оболочкой Windows 3.x. Вылезла из параллельной реальности OC Unix и вскоре Linux. Microsoft тоже двинулся в направлении традиционных много- много- операционных систем. Windows NT наконец.
И только в начале 21-го века начинают появляться "виртуальные машины" (в кавычках потому что это не машины, а ОС. Всем известная VMWare вышла на серверный маркет в 2001 году.
На сегодня имеется до десятка разных имплементаций "виртуальных машин" на платформе х86-64. Они типизированы как Hypervisor Type-1 и Type-2, разница между которыми размыта и не несет никакого реального смысла. Кем эта типизация была введена и зачем я не знаю. По этой типизации в одном из англоязычных источников я даже нашел утверждение что zVM это гипервизор второго типа.
Некоторые выводы из исторического введения
Завершая историческую часть статьи, отмечу что эволюция развития системного ПО на мэйнфрэйм шла иначе чем на платформах х86 и х86-64. На мэйнфрэйм оба подхода: виртуальные машины и системы разделения время в рамках одной модели ОС появились одновременно и развивались параллельно. На х86, х86-64 традиционные системы разделения времени значительно опередили "виртуальные машины", а последние так и не выросли больше чем виртуализация операционных систем. Это невозможно (ниже будет показано), да это и не нужно, строго говоря.
Объясняется это тем что архитектура Интел процессоров изначально не претендовала даже на многозадачность. Со временем стало однако понятно что рамки надо расширять, но с сохранением преемственности к более ранней архитектуре. Это привело к полумерам и не изжито полностью до сих пор.
Процессор мэйнфрэйм, с другой стороны, изначально проектировался для по крайней мере многозадачной ОС. Да, с виртуальной памятью немного "пролетели". Но уже в S/370 был наведен с этим полный порядок и гармония.
Ну а теперь перейдем к описанию что такое настоящая виртуальная машина и что такое виртуальная операционная система пусть даже их может несколько разных, но все таки ограниченное в каждом случае количество.
Настоящая виртуальная машина
. Краткое определение настоящей виртуальной машины такого что это полный функциональный аналог реального компьютера. Я написал компьютер чтобы различать "машина" от "компьютер". Это чисто лингвистическая проблема с одной стороны. Но с другой это порождает некоторые заблуждения, если не быть дотошным.
В самом деле, если мы имеем несколько образов (копий) ОС, выполняющих разные работы, на одном и том же компьютере, то возникает иллюзия что мы создали несколько компьютеров или виртуальных машин. Насколько эта иллюзия близка к реальности?
Для создания многозадачной ОС необходим компьютер обладающий возможностью защиты задач друг от друга и защиты ОС от задач. На МФ это достигается во-первых, разделением машинных команд на две группы: команды супервизора и команды задач, во-вторых, механизмом защиты памяти.
Команды супервизора это те команды которые могут изменять выполнение задач, управлять внешними устройствами и машинными службами, например, службой времени. Команды задач это все остальные команды. Команды супервизора могут выполняться только в состоянии супервизора, переход в которое из проблемной задачи невозможен. Достигается это тем что в слове состояния программы (PSW), которое сопровождает всю работу процессора, имеется бит, состояние которого "0" или "1" определяет выполняется ли программа в состоянии супервизор или это задача. Соответственно если программа выполняется в состоянии супервизор то ей доступны все команды, и супервизора и задачи. Если это состояние задача, то доступны только команды задач и недоступны команды супервизора. При попытке выполнять последние происходит прерывание и управление передается супервизору, который такую задачу просто уничтожает с соответствующей диагностикой.
Программы виртуальных машин всегда выполняются в состоянии задача. Не важно какая часть работы: супервизор ОС ВМ или прикладная задача в этой ОС ВМ на самом деле выполняется. Разница состоит лишь в том что в процессе выполнения ВМ отслеживается виртуальный статус ВМ. Это может быть супервизор или прикладная задача.
Если команда супервизора была выполнена в виртуальном состоянии супервизор то CP (hypervisor как принято это нынче называть) обеспечит ее безопасное выполнение отразив результат на ВМ и продолжив её выполнение.
Если же команда супервизора на ВМ выполнялась в виртуальном состоянии задача, то тогда CP отразит программное прерывание на ВМ и этим займется супервизор ОС ВМ.
Таким образом отличие выполнения ОС на реальной машине от выполнении ее на ВМ состоит в наличии дополнительной прокладки между реальной машиной и ОС на ВМ. Т.е. наличии CP. Причем эта прокладка действует точно также как и реальная машина, но уже в отношении виртуальной. Иными словами CP отражает работу реальной машины на виртуальную через разделение команд и с учетом виртуального состояния супервизор/задача в виртуальном cлове состояния программы (PSW).
Кроме виртуального PSW для ВМ в CP поддерживаются все службы процессора МФ, но виртуально. Делается это через т.н. управляющие блоки, которые ведет СP для каждой активной ВМ.
Таким образом ВМ на МФ это не что-то придуманное разработчиками того или иного hypervisor, а в точности тоже самое чем является процессор (и другие компоненты) МФ со всеми их принципами работы. Поэтому логика управления виртуальной машиной под zVM (CP) проста. А именно:
Готовая к выполнению ВМ диспетчируется на реальный процессор, без какого-либо просмотра и/или модификации кода, так же как и любая задача в многозадачной ОС. Выполнение ВМ продолжается без каких-либо остановок до наступления одного из трех событий: истечение кванта времени отпущенного ВМ, появление в коде ВМ команды супервизора, и/или любого другого прерывания реальной машины.
При наступлении одного из этих событий выполнение ВМ прекращается, вся информация о состоянии выполнения (регистры, адрес прерывания и т.п.) сохраняется в управляющем блоке ВМ, управление возвращается CP. В следующий раз ВМ получит процессор когда будет разрешена причина прерывания, ВМ станет готовой для выполнения и диспетчер (CP) вновь запустит ВМ на выполнение.
Поэтому на МФ возможно то что невозможно на х86-64, а именно загружать zVM на виртуальной машине, а в ней, на её ВМ второго уровня, загружать другую zVM. И так далее.
Последнее является ёмким критерием и лакмусовой бумажкой определения что есть настоящая виртуальная машина.
Виртуальные системы на х86-64
Как было показано выше на МФ в zVM виртуальная машина это полный функциональный аналог реальной машины. И это не просто слова это есть прямое следствие устройства и принципов работы МФ (процессора, памяти, ввода-вывода). Это в свою очередь является следствием тех подходов к проектированию компьютеров, которые использовались до появления микропроцессоров. А именно наличия в общем наборе возможностей компьютеров быть устройством выполнения систем и программ функций управления собственно компьютером без прикладного программного обеспечения, и без ОС.
Изначально это выполнялось через пульты управления используя световые индикаторы, переключатели и клавиши. Например вот так:
Этим в основном пользовались электронщики, которые обслуживали железо. И у них имелся богатый инструментарий для работы с компьютером без каких либо программ, даже в ручную. Электрическая пишущая машинка слева это пульт операционной системы или системнонезависимой программы.
Помню на втором курсе у нас летом организовали т.н. вычислительную практику. Проще говоря научили нас программировать на Минск-22. И были практические занятия с выходом к Минск-22. Однажды пришли мы в машзал раньше нашего времени. За пультом Минск-22 сидел инженер/программист. Пульт Минск-22 был в виде довольно большого письменного стола, на столешнице которого располагались ряды клавиш, а на вертикальной стойке ряды лампочек. Впрочем вот он:
Там даже вольтметр есть. Инженер/программист периодически запускал машину и начинал звучать полонез Огинского. В какой то момент раздавалась фальшивая нота. Инженер/программист нажимал клавишу и музыка прекращалась. Потом он многократно что-то нажимал, смотрел на лампочки и наконец снова начинался полонез Огинского. Что это было я не знаю.
Вот эти особенности, значительно видоизменившиеся со временем, и позволяют zVM создавать виртуальные машины как полные функциональные аналоги реальной. Кроме того важную роль сыграло то что МФ изначально проектировался как компьютер для многозадачной работы.
Процессор х86-64 изначально был и остается микропроцессором. Да весьма развитым (даже чересчур на мой взгляд, до того что некоторые возможности не используются ни в Windows ни в Linux, как то: методы виртуализации памяти, кольца защиты (Ring)), но все таки микропроцессором. Его назначением было выполнять программы состоящие из инструкций над данными хранимыми в памяти. Управлять самим микропроцессоров вообщем то и не надо. Более того, поскольку микропроцессор размещается на одном кристалле, то имело место быть дефицит количества элементов на кристалле. Поэтому размещать на нем еще и нечто вроде управления микропроцессором как таковым было затруднительным, да и не нужным. Аналогом пультов управления в случае компьютеров на микропроцессорах является BIOS:
Отдельная микросхема для тестирования элементов, минимальных конфигураций и загрузки системы. Возможно в современных х86-64 микропроцессорах BIOS размещается на одном кристалле с CPU.
Связь микропроцессора с памятью и внешними устройствами осуществляется через общую шину. Микропроцессор постоянно что-то выполняет. У него нет состояния остановки выполнения. Если нет прикладной работы микропроцессор как минимум двигает часы, которые реализованы как регистры с изменением их значения программно. BIOS после запуска ОС в работе компьютера не участвует. До следующего включения компьютера.
Поэтому фактически компьютер на микропроцессоре это Операционная Система. Поэтому все гипервизоры на микропроцессорах это системы виртуальных ОС. Их может быть много, но они не на виртуальных машинах выполняются, а как любые другие задачи в многозадачной ОС. Разница может казаться незначительной, но она есть и у неё есть определенные последствия.
Углубление понимания настоящей виртуальной машины
Сравнивать микропроцессоры и процессор мэйнфрэйм (недавно натолкнулся на термин mainprocessor) дело неблагодарное. Я пытался это делать много раз и всегда "буксовал" в итоге. Но совсем недавно, при написании этой статьи, меня осенило одной мыслью. Изложу. её.
Процессор МФ это микропроцессор окруженный некой оболочкой прежде чем на нем начинают выполняться ОС и программы. Этот микропроцессор имеет свои инструкции на которых запрограммированы инструкции оболочки используемые для написания ОС и программ на языке машинных команд - Ассемблер. Эта оболочка называется "Принципы работы МФ". Кроме собственно процессора (CPU - Central Processing Unit) принципы работы охватывают и ввод-вывод. На этих принципах базируются и принципы работы Операционных Систем МФ. Это ключевой момент на самом деле. Это как раз и позволяет ИБМ так долго держаться на плаву и выдавать все новые и новые генерации МФ и его ОС.
Изначально принципы работы МФ были относительно просты и понятны программистам как разрабатывающим ОС, так и пишущих прикладные программы на языке Ассемблер. По мере развития принципы работы усложнялись и на сегодня прикладные программисты даже на Ассемблер многих новых принципов могут и не знать. Эти новые принципы как правило находят свое применение в системных службах (facilities) и уже через эти службы используются в прикладном программировании или администрировании.
Важно что эти принципы развиваются независимо от того какой микропроцессор превращает их в сигналы и движения. Изначально это и не был микропроцессор, это была электронная логика на дискретных транзисторах. На этом этапе принципы работы реализовывались непосредственно в электронных схемах. Поэтому до появления больших интегральных схем компьютеры получались довольно большими. Иначе и быть не могло. Но первые микропроцессоры и компьютеры на их основе сильно уступали МФ по производительности.
Примерно в середине 90-х появились МФ на микропроцессорах и видимо тогда началось расщепление на уровень принципов работы и их материализацией в железе. Но еще до середины 90-х в МФ появилось понятие microcode. Это и были те программы работающие на железе и формирующие то что называется "Принципы работы". Я почему так упираю на это обстоятельство? Уже будучи программистом на языках, включая Ассемблер, я имел слабое представление о, на тот момент, ЕС ЭВМ. И прочитав однажды небольшой документ "Принципы работы" как бы прозрел и все стало понятно и легко. Легко диагностировать проблемы и находить им решения, легко писать "правильные" программы на каком угодно языке и их смесях.
Эти же знание позволили мне буквально ворваться в Систему Виртуальных Машин (VM/370) и успешно в ней работать долгие годы, увы закончившиеся уже больше лет назад чем их было. Но знания основ виртуализации на МФ, полученные мной давно, остаются актуальными и сегодня. Мне не составит никакого труда начать работу с современным состоянием VM - zVM. Поскольку это в основе одно и тоже.
В этом смысле уместно отметить что на микропроцессорах х86-64 мы имеем десяток в принципе разных систем виртуализации и переход с одних на другие не так и прост. Главным образом правда это касается GUI, который различаются у разных вендоров. Суть тоже остается одной и той же - виртуальные операционные системы. На МФ кто бы что ни делал в смысле виртуализации все равно получится одно и тоже - VM. Поэтому и нет VM МФ от разных вендоров.
Дополнительный материал о реальных машинах
Но что такое реальная машина (компьютер)? В ответе на этот вопрос все зависит от того о каком компьютере идет речь. Рассмотрим процесс включения компьютера и активизации программного обеспечения..
Если это х86, то тогда это может быть либо firmware, в который мы переходим нажатием неких клавиш на клавиатуре в определенный отрезок времени после включения, либо ОС, которая загружается с устройства ранее сконфигурированное в firmware как устройство загрузки ОС. Т.е. в общем случае всегда когда мы включаем компьютер х86 мы имеем дело с загрузкой ОС, в которую наш компьютер и превращается с этого момента. Превращается либо в виртуальную firmware, либо ОС. (Возможность выбора загрузки одной из разных ОС ничего принципиально не меняет). Пользователь х86 всегда имеет дело с тем или иным программным обеспечением. Поэтому х86 компьютер для пользователя это всегда ОС.
Иначе обстоит дело в случае мэйнфрэйм. Включение мэйнфрэйма в общем случае не сопровождается загрузкой какой-либо ОС. На ранних моделях МФ выбор устройства загрузки ОС задавался переключателями путем набора трехзначного числа (ранее десятичного, позднее шестнадцатеричного четырехзначного, Довольно рано физические переключатели ушли на Hardware Management Console (HMC)) - адреса внешнего устройства на пульте управления МФ, и нажатием клавиши "IPL" (Initial Program Load") рядом с наборным полем адреса устройства загрузки. Таким образом можно загружать любые подготовленные на внешних устройствах (обычно это диски, но не обязательно) ОС, а вообще все что угодно, с любых внешних устройств (диски, ленты, перфокарты, перфоленты, etc...USB, CD, FTP server). Если это не ОС то такая программа называется системно независимая программа (standalone program), которых немало в мире МФ и каждый может написать свою. Можно и ОС свою написать. Преград этому нет никаких.
До загрузки ОС МФ можно использовать с пульта, например, вручную заносить данные в память, изменять значения в регистрах в том числе PSW - Program Status Word. Это может быть код программы и данные для ее выполнения. А потом запустить программу на выполнение нажатием клавиши Start на пульте управления мэйнфрэйм (конечно давно уже это делается с HMC). Можно в любой момент останавливать выполнение на заранее установленных адресах или по каким-то другим событиям выполнения. В те давние времена многие компьютеры предоставляли такие возможно, но иных уж нет, а МФ всеми этими возможностями обладает, правда без пультов, которые можно увидеть в фильме "Чародеи" (это была ЕС-1045), а с Hardware Management Console (HMC). Вот экран живого, пока, HMC:
. Здесь мы имеем один МФ с шестью логическими партициями (LPAR), четыре из которых не активны, две активны и выполняют z/OS. Это не zVM, это реальная машина МФ с партициями реализованными PR/SM (Processor Resource/Systems Manager), ошибочно считающимся Type-1 Hypervisor. Почему ошибочно? Потому что каждая партиция это реальный МФ. PR/SM это микропроцессор МФ и микрокод на котором написаны все те же "Принципы работы МФ".
В принципе в любой партиции можно загрузить любую системы или просто программу. В партициях нет никаких определенных ОС до момента загрузки. Все определяется тем что находится на том или ином устройстве загрузки:
В этой партиции я загружал Linux.
А вот что входит в конфигурацию партиций:
Причем память (storage) это не виртуальная память а вполне таки кусок реальной памяти МФ в целом:
Здесь показаны только активные партиции и их нахождение в памяти. Память для неактивных партиций размещается в процессе их активации. Таким образом можно иметь партиций с суммарной памятью больше память МФ. Но активированы в каждый момент времени могут быть только столько партиций сколько есть физической памяти.
А что c CPU? На этом МФ один CPU (точнее один кор) активирован. И все шесть партиций, если они все будут активированы, будут выполняться на этом одном CPU. В данный момент выполняется только две партиции.
zVM, если бы он у нас был, выполнялся бы в одной или больше партициях. На этом уровне (PR/SM) все ОС выполняются на реальной машине.
Тоже самое что мы имеем с PR/SM имеет место быть и с виртуальными машинам в исполнении zVM только теперь уже под управлением zVM, и это Hypervisor Type-1.
У каждой виртуальной машины под zVM есть виртуальный пульт управления полный аналог того пульта с переключателями, клавишами и лампочками что имелись на ранних реальных машинах, или ныне в партициях с использование HMC.
Пульт виртуальной машины это терминал с которого виртуальная машина (ВМ) была активирована. Сразу после активации ВМ пульт ВМ переводится в среду команд CP, которые выполняет Control Program (CP). Команды CP делятся на семь классов, обозначаемых буквами A-G. Первые шесть классов (A-F) относятся к управлению самой CP. Эти классы назначаются ВМ для управления самой CP, её разным областям/функциям. Седьмой класс G состоит из команд управления виртуальной машиной и это минимум назначаемый пользовательским машинам.
Командой CP класса G является команда выполнение загрузки программы (ОС) на ВМ. Это команда IPL с операндом адрес устройства загрузки. Все как и на реальном мэйнфрэйм. После выдачи команды IPL пульт управления ВМ также становится консолью той ОС которая загружается. На этот пульт выводятся сообщения ОС ВМ и сообщения CP. Сообщения CP ограничиваются теми функциями классов команд, которые были назначены ВМ. С этого пульта можно выдавать все команды ОС загруженной на ВМ. Для различения команд ОС ВМ и команд СР (выдаваемых с одного и того же терминала/пульта) существует ряд приемов, одним из которых является использование префикса #CP перед именем команды СР.
Интел процессоры того времени не предоставляли возможности четкого разделения команд на пользовательские и системные. Поэтому первые версии VMWare выполняли сканирование кода ОС ВМ с целью выявления команд, выполнение которых непосредственно могло привести к разрушению всей конструкции. И заменяли их интерпретацией. Это сильно повышало накладные расходы на виртуализацию. И очевидные последствия. Хотя для учебно-лабораторных работ было приемлемо. Мне приходилось с этим сталкиваться на ИБМ-ских воркшопах.
В более поздних версиях Интел процессоров это было устранено и появились т.н. Ring's - кольца. Их в итоге оказалось гораздо больше двух. В процессорах S/360, начальной стадии процессоров мэйнфрэйм, было два уровня команд: супервизор и проблемный (или задача). Команды проблемного (задача) уровня выполнятлись без опасности оказать негативное (любое) воздействие на другие задачи и на систему. Их как было две группы так и остается две. А больше и не надо поскольку есть только два уровня в любой системе: сама система и приложения, или система и виртуальные машины со своими системами.
Особенности виртуализации ввода-вывода на примере дисков.
Обращение к внешним устройствам МФ выполняется по адресу. Адрес это четырехзначное шестнадцатиричное чмсло. Физически устройства подключены через каналы ввода-вывода. Изначально количество каналов измерялось десятками (на ЕС ЭВМ единицами) в настоящее время их может быть сотни и тысячи на одном МФ.
Устройства ВМ тоже имеют алреса, но это виртуальные адреса. При выполнении ввода-вывода управляющая программа (СР) заменяет виртуальные адреса на реальные. В это состоит одна из причин трансляции программ ввода-вывода перед их выполнением.
В простейшем случае внешние устройства могут закрепляться за ВМ и тогда трансляция канальной программы это простая замена виртуального адреса на реальный. Диски обычно совместно используются многими ВМ.
Диски на МФ виртуализируются так называемыми минидисками. Минидиск это участок реального диска ограниченный цилиндрами с номерами "с" и "до". В оглавлении виртуальных машин минидиски определяются оператором MDISK, в котором указывается серийный номер реального диска, виртуальный адрес, виртуальный номер цилиндра начала минидиска и количество цилиндров на минидиске. .
Естественный способ работы с дисками на МФ (CKD диски), как впрочем и с любыми другими внешними устройствами, это состоит в построении и выполнении канальной программы ввода-вывода. Для дисков это в простом варианте означает поиск нужного цилиндра, по номеру, и выполнение тех или действий на нем.
ОС ВМ подготавливает канальную программу и запускает ее инструкцией процессора SIO (Start I/O). SIO это команда супервизора и следовательно при выполнении ее в виртуальной машине происходит прерывание, Управляющая программа (СР) получает управление и обнаруживает что это команда "начать ввод-вывод". СР знает где находится канальная программа ВМ и переписывает ее в свою область памяти. Затем СР анализирует каналную программу и если это минидиск то выполняет корректировку номеров цилиндров. Так как ОС ВМ считает что ее диски всегда начинаютсяя с нулевого цилиндра, то надо эти номера изменить с учетом номера начального цилиндра на реальном диске. После корректировки номеров цилиндров СР запускает канальную программу ВМ из своего адресного пространста. Результат выполнения канальной программы возвращается на виртуальную машину.
Большенство других внешних устройств в zVM используются закреплением их за ВМ с минимальной корректировкой канальных программ.
На х86-64 диски ВМ в общем случае это файлы в файловой системе гипервизора. И есть два уровня драйверов: реальный и виртуальный.
Конец статьи.
Я даю себе отчет в том что статья получилась сумбурной, с издержками и многими недостатками. Но согласитесь тема эта довольно глубокая, обстоятельства тонки, а сравнение таких вещей как МФ и х86 весьма затруднительно. Гораздо проще было бы сделать введение в виртуализацию на МФ, введение в то же самое на х86 и оставить сравнение их читателю. На интернете можно найти такие сравнения, но они во многих случаях банальны и зачастую неточны, и даже ошибочны. Но я попытался сделать больше. Получилось это у меня или нет, судить читателям.
Комментарии (58)
kozlyuk
31.10.2025 21:05Раздел "Настоящая виртуальная машина" полностью применим к x86-64 (и ARM) с расширениями для виртуализации, которые есть примерно на всех актуальных серверных процессорах и на старших десктопных. Вы сравнили не виртуализацию на МФ и на x86-64, а виртуализацию с аппаратной поддержкой (МФ и неупомянутые современные x86-64) и без нее — с очевидным результатом.
Было бы интересно узнать больше про каналы даже без связи с виртуализацией (думаю, это тема на целую статью).
SIISII
31.10.2025 21:05Раздел "Настоящая виртуальная машина" полностью применим к x86-64 (и ARM) с расширениями для виртуализации, которые есть примерно на всех актуальных серверных процессорах и на старших десктопных
На самом деле, не совсем. Хотя введение расширений виртуализации решило (вроде бы -- досконально я этот вопрос не изучал) проблему, связанную с тем, что в 80286/386 ряд команд, системных по своему смыслу, были сделаны непривилегированными), остаётся проблема ввода-вывода -- а без него нет виртуальной машины (компьютера), есть только виртуальный процессор :)
Чтобы на ПК получить виртуализацию, аналогичную мэйнфреймам, нужно сделать такой гипервизор, чтобы абсолютно любая гостевая система работала корректно при любых, даже самых нестандартных её обращениях к периферии. Более того, при подключении какой-то новой железки эта самая железка должна нормально работать под управлением гостевой ОС, даже если сам гипервизор понятия не имеет, как эту железку виртуализировать. На архитектуре ПК такое попросту невозможно, на мэйнфреймах -- элементарно в силу принципиальной иной организации ввода-вывода. (Но есть и обратная сторона: мэйнфреймовский ввод-вывод менее гибок и, скажем культурно, плохо подходит под, например, "ногодрыг" и прочие типично микроконтроллерные задачи).
checkpoint
31.10.2025 21:05Чтобы на ПК получить виртуализацию, аналогичную мэйнфреймам, нужно сделать такой гипервизор, чтобы абсолютно любая гостевая система работала корректно при любых, даже самых нестандартных её обращениях к периферии.
А для этого необходимо отказатсья от MMIO и перейти на "каналы". PCI и PCIe это движение в нужном направлении, но что делать со всем остальным железом ? Где-то читал, что IOMMU не решает всех проблем виртуализации, а только создает новые.
SIISII
31.10.2025 21:05Проблема в не шинах (электронной реализации), проблема в самой концепции ввода-вывода, управление которым везде, кроме мэйнфреймов, сводится к записи и чтению регистров устройств как обычных адресуемых ячеек (памяти или пространства ввода-вывода -- неважно). Чтобы виртуализировать такое устройство, программа-виртуализатор должна отслеживать все операции записи и считывания этих регистров (что может быть накладным, но технически вполне выполнимо) и программно эмулировать работу устройства, чьи регистры пишутся или читаются. В теории это осуществимо, и для простых устройств качественная эмуляция (если угодно, виртуализация) существует, однако создать такой программный эмулятор для каждого устройства ПК на практике нереально из-за нереального количества этих железяк, их плохой документированности и т.д. и т.п. Поэтому ограничиваются некоторым подмножеством, достаточным для работы Винды и Линуха, но что-то нестандартное, успешно работающее на реальном железе, запросто может оказаться неработоспособным на такой виртуальной машине (даже с такой, вроде бы, банальщиной, как прокинуть железные USB-порты на виртуальную машину, есть проблемы).
Ну и проблема с использованием устройств, с которыми не знаком сам гипервизор. В VM/370 и её потомках такие устройства могут просто полностью отдаваться в распоряжение гостевой ОС, умеющей с ними работать, а роль гипервизора сводится к преобразованию адреса устройства и адресов блоков памяти, участвующих в операциях ввода-вывода, что на мэйнфреймах является абсолютно идентичным для любого устройства и поэтому не требует от гипервизора знаний о том, что это за устройство и как именно оно работает. Ну а на других архитектурах эта задача, в общем случае, неразрешима, поскольку нет единого стандарта на взаимодействие устройств с центральной частью машины.
kozlyuk
31.10.2025 21:05устройства могут просто полностью отдаваться в распоряжение гостевой ОС, умеющей с ними работать, а роль гипервизора сводится к преобразованию адреса устройства и адресов блоков памяти, участвующих в операциях ввода-вывода
Проброс устройств в вируталку с помощью IOMMU, разве нет?
Есть вопрос к модели работы самих устройств. Пример с диском удобный, потому что с любой его частью можно работать, как с целым диском, но возьмем сетевую карту — как в ней выделить кусок, подобный целой карте, без того, чтобы карта об этом знала? Какой компонент будет отвечать за распределение ресурсов карты? NVIDIA (Mellanox) делает нечто подобное, но строго при содействии карты. Из забавного, в их новых картах даже есть режим работы VF, когда железо притворяется VirtIO, чтобы гипервизору меньше транслировать.
SIISII
31.10.2025 21:05С такими устройствами не получится -- их надо либо полностью выделять в распоряжение гостевой ОС, либо эмулировать программно. С последним, как я уже писал, проблемы из-за их высокой сложности на уровне управления ими (устройству нельзя просто выдать команду "прочитать блок данных", как это делается на мэйнфрейме, -- надо запрограммировать кучу регистров специфичным для конкретной модели образом, и т.д. и т.п.; соответственно, программный эмулятор должен корректно воспринимать всё такое программирование со стороны ОС и затем выполнять затребованную операцию).
А IOMMU далеко не всегда помогает. Скажем, если устройство может быть мастером шины (само выполняет прямой доступ к памяти), то надо преобразовывать его доступы к памяти таким образом, чтобы они выполнялись по адресам, выделенным виртуальной машине, причём именно тем, что гостевая ОС запрограммировала в регистрах этого устройства, да ещё учитывать, что нужные страницы памяти могут быть выгружены гипервизором...
zVlad909 Автор
31.10.2025 21:05А IOMMU далеко не всегда помогает. Скажем, если устройство может быть мастером шины (само выполняет прямой доступ к памяти), то надо преобразовывать его доступы к памяти таким образом, чтобы они выполнялись по адресам, выделенным виртуальной машине, причём именно тем, что гостевая ОС запрограммировала в регистрах этого устройства, да ещё учитывать, что нужные страницы памяти могут быть выгружены гипервизором.
В zVM, как написано в статье, гипервизор (СР) переисывает канальную программу в свою память и модернизирует ее так чтобы канал ввода-вывода писал данные в память СР. Конечно и память канальной программы и данных фиксируется на время выполнения канала. По окончанию ввода-вывода данные переписываютмя в память виртуальной машины.
Можно ли так же поступать в случае х86 я не знаю. Но там нет каналов и канальных программ. Там это делается драйверами.
SIISII
31.10.2025 21:05В том и проблема, что на любой архитектуре, кроме мэйнфреймовской, похоже, нет возможности полностью и сколько-нибудь эффективно виртуализировать ввод-вывод без помощи со стороны гостевой ОС: у каждого устройства свои припадки, и всё учесть в гипервизоре представляется нереальным.
Ну а как виртуализация ввода-вывода на мэйфреймах работает, я знаю -- в своё время работал с СВМ ЕС, а в девичестве она, как известно, VM/370.
kozlyuk
31.10.2025 21:05Команду "прочитать блок данных" воспринимает сама карта или нечто промежуточное транслирует команды в специфичные действия с железом? Если первое, то как гипервизор может транслировать неизвестные ему команды для произвольных устройств? Если второе, то это означает, что мы реального железа просто никогда не видим, а значит, можем работать только с тем, для чего это нечто умеет делать преобразование.
Не понял пассаж про IOMMU — ну да, он описанное делает. Гипервизор, очевидно, не должен выгружать страницы, отображение на которые он запрограммировал в IOMMU.
zVlad909 Автор
31.10.2025 21:05Команду "прочитать блок данных" воспринимает сама карта или нечто промежуточное транслирует команды в специфичные действия с железом?
Что Вы имеете в виду под "карта"? У меня нет никаких карт в описании работы канала. Нет ничего промежуточного между канальной программой созданной на ВМ кроме управляющей программы (СР). И нет трансляции команд. Под трансляцией понимается, для примера, сдвиг номера цилиндра диска с учетом реалного положения минидиска на реальном диске.
...как гипервизор может транслировать неизвестные ему команды для произвольных устройств?
Команды, в общем случае, не меняются.
Если второе, то это означает, что мы реального железа просто никогда не видим, а значит, можем работать только с тем, для чего это нечто умеет делать преобразование.
Не совсем так. Мой коллега SIISII объяснял что прелесть виртуализации ввода-вывода на МФ для совершенно не известных гипервизору устройств, но известных ОС ВМ, такое устройство закрепляется за ВМ (командой СР ATTACH (или оператором DEDICATE оглавления ВМ) и гипервизор всего лишь заменяет виртуальный адрес устройства (он всегда есть) на реальный (в принципе они могут совпадать, но это все равно произойдет) оставляя канальную программа ВМ для этого устройства неизменной лишт переписывая ее (как есть) в свою память и фиксируя страницу(ы) с программой и данными в реальной памяти. Остальное выполняется канало и устройством подключенным к этому каналу. .
Не понял пассаж про IOMMU
Честно говоря я не знаю что это такое и не упоминал этот термин. Может SIISII что-то мог бы сказать. По крайней мере у него в сообщении выше есть такие слова: "А IOMMU далеко не всегда помогает. ..."
SIISII
31.10.2025 21:05На мэйнфреймах любые команды ввода-вывода интерпретируются и каналом (на современных машинах корректней говорить о канальной подсистеме, но в детали углубляться в данной дискуссии не требуется), и устройством одновременно. Канал смотрит только на несколько битов кода канальной команды, чтобы понять, в каком направлении будет идти обмен данными (чтение или запись, грубо говоря; есть нюансы, но в данном случае они неважны), устройство же интерпретирует весь код целиком. Поэтому для канала нет принципиальной разницы между командами, скажем, "прочитать информацию с диска" и "прочитать состояние диска" -- для него это команды ввода, и всё, что он должен сделать, -- передать команду устройству (стандартным образом), получить от него поток байтов (стандартным образом) и записать их в указанную в канальной программе область памяти (тоже стандартным образом). Само устройство к памяти не обращается, оно лишь взаимодействует с каналом по стандартному интерфейсу ввода-вывода: получает команды, после чего получает или отдаёт байты данных. По этой причине гипервизор может обслуживать устройства, в которых он не разбирается: он может интерпретировать канальную программу, поскольку её формат определён архитектурой, а не конкретными устройствами, а соответственно, он может скорректировать адреса областей данных (преобразовать из виртуальных адресов памяти виртуальной машины в абсолютные адреса физической памяти -- ведь гостевая ОС не знает, где она сидит в памяти, и те адреса, которые она считает абсолютными, на самом деле являются виртуальными). Иметь дело с кодами операций ему приходится лишь в той степени, чтобы понять направление передачи данных, да и то не всегда, соответственно, ему не нужно понимать специфику устройства.
zVlad909 Автор
31.10.2025 21:05но возьмем сетевую карту — как в ней выделить кусок, подобный целой карте, без того, чтобы карта об этом знала? Какой компонент будет отвечать за распределение ресурсов карты? NVIDIA (Mellanox) делает нечто подобное, но строго при содействии карты. Из забавного, в их новых картах даже есть режим работы VF, когда железо притворяется VirtIO, чтобы гипервизору меньше транслировать.
Вы задали вопрос и сами на него ответили. Да, это зависит от карты. Даже без zVM системы в партициях МФ совместно используют сетевые карты OSA. Вообще все что есть на МФ может использоваться совместно. Кроме оперативной памяти.
zVlad909 Автор
31.10.2025 21:05Настоящность ВМ можно проверить простым тестом - загрузить гипервизор на ВМ.
SIISII
31.10.2025 21:05Неа. "Настоящесть" можно проверить, если запустить на ВМ тест аппаратуры, и он покажет, что вся аппаратура работает нормально -- но при этом тестировать он будет не реальное железо, а виртуальное. Вот это и будет настоящей 100% виртуализацией машины. Мэйнфреймовская... ну, она 95%: некоторые тесты таки не пройдут, если за виртуальной машиной соответствующее физическое устройство не закрепить напрямую (во всяком случае, в VM/370 не прошли бы, скажем, тесты 29-мегабайтных дисков -- IBM 2914, если память не изменяет, они же ЕС-5061, -- если бы использовались не реальные диски, а их "виртуалы": гипервизор для них не эмулировал выполнение специальных диагностических команд; понятно, что на работе нормальных программ, включая ОС, это никак не сказывалось, поскольку эти команды использовались только узкоспециализированным диагностическим ПО). Ну а ПК... жалкое подобие левой руки, прямо скажем.
kozlyuk
31.10.2025 21:05Я на процессоре i7-6700 с Linux-хостом запускал ESXi (VMWare) как гостя в QEMU-KVM, а в ESXi — виртуалку с Linux. Вот статья 2017, где автор делает то же: https://habr.com/ru/articles/325090/.
zVlad909 Автор
31.10.2025 21:05Это другое. Правильным был бы тест запуска ESXi (VMWare) на виртуалке ESXi (VMWare). Или QEMU-KVM на виртуалке QEMU-KVM.
Впрочем в Вашей ссылке есть про это:
К счастью, ESXi поддерживает Nested Virtualization — то есть способность запускаться из-под уже работающего гипервизора. При этом и внешний гипервизор понимает, что его гостю нужен доступ к аппаратной виртуализации, и ESXi знает, что работает не на голом железе. Как правило, в качестве основного гипервизора также используется ESXi .....
Что значит "знает"? Значит что такое знание предусмотренно разработкой этих гипервизоров. Ну и хорошо. Но zVM, работая на виртуалке может конечно знать про виртуалку, но он не пользуется этим знанием.
Другие ОС МФ могут знать и использовать знание о том что они работают на виртуалке. Более того есть ОС (не гипервизор) МФ которые в принципе могут только работать на виртуалках.
Ну а вообще привденная Вами ссылка про то как заставить гипервизор принимать гостя гипервизора. Это танец с бубном. Я подозреваю что в итоге гостевой гипервизор у Вас просто работает рядом с хостовым гипервизором и они особо не мешают друг другу.
А в случае с zVM это работает по определению.
kozlyuk
31.10.2025 21:05В той же статье следующим предложением после того, которое вы процитировали, написано, что VMWare внутри VMWare — это штатный сценарий. QEMU-KVM внутри QEMU-KVM тоже работает. Можно утверждать, и я согласен, что на МФ это организовано более стройно, но в статье вы пишете, будто на x86-64 гость-гипервизор невозможен, что неправда.
zVlad909 Автор
31.10.2025 21:05Хорошо. Больше не буду писать что на х86-64 гость-гипервизор невозможен. Но согласитесь что если это была штатная ситуация то никаких таких статей бы не было.
Особенно мне вот это понравилось:
Затем отключим невежливое поведение модуля KVM в моменты, когда гость пытается читать машинно-специфические регистры, которых на самом деле нет. По-умолчанию, KVM в ответ на это генерирует внутри гостя исключение General protection fault, отчего гость ложится в синий (в нашем случае-розовый) экран смерти. Сделаем под рутом:
root@debian-pc:/> echo 1 > /sys/module/kvm/parameters/ignore_msrsТаких отключений для гостей в zVM нет и быть не может. Все работает в соответствии с "Принципами работы" и ничего не надо отключать чтобы гость zVMработал на виртуальной машине.
Остальное в статье я читать не стал. Попахивает шаманством. Но если в итоге гость-гипервизор заработал, то я только рад и никогда больше не стану утверждать обратное. Спасибо. .
zVlad909 Автор
31.10.2025 21:05Было бы интересно узнать больше про каналы даже без связи с виртуализацией (думаю, это тема на целую статью).
Да тема большая. Но можно и вкратце объяснить.
Канал это отдельный компьютер ввода-вывода. CPU МФ никакого участия в выполнении ввода-вывода не принимает за исключением подготовки канальной программы и подачи сигнала каналу о том что программа для него готова и можно начинать ее исполнять.
Программа канала состоит из последовательности CCW - Channel Command Word. Программа канала может быть весьма сложной и иметь циклы и условные переходы. Это не просто установить, прочитать, записать. Одной канальной программой можно отформатировать диск.
Выполнение канальной программы завершается прерыванием ввода-вывода отражаемого на CPU. Каналы существенно разгружают CPU. Они входят в архитектуру МФ с самых первых дней. Но за это время технически они весьма преобразились.
Изначально это были отдельные шкафы соединенные с CPU толстыми многожильными кабелями, с другой стороны имелись Control Units (CU), а те в свою очередь своими кабелями соединялись с устройствами. В архитектуре и принципах работы все это (Channel, Control Unit, Devices) остается и сейчас. Но технически это все многократно изменялось с учетом новых технологий. С точки зрения программирования все осталось неизменным.
Количество каналов на современных МФ исчисляется сотнями. .
artscan
31.10.2025 21:05Это не zVM, это реальная машина МФ с партициями реализованными PR/SM (Processor Resource/Systems Manager), ошибочно считающимся Type-1 Hypervisor. Почему ошибочно? Потому что каждая партиция это реальный МФ. PR/SM это микропроцессор МФ и микрокод на котором написаны все те же "Принципы работы МФ".
Микрокод - это ведь software с точки зрения разработчиков МФ? Тогда слой этого микрокода реализует гипервизор 1-го типа. Если zVM хоть немного считать ОС общего назначения, то она реализует уже гипервизор 2-го типа. Особенно, если при этом она как-то расширяет функционал гипервизора за счет возможностей ОС, недоступных в слое микрокода. Если же функционал гипервизора и zVM полностью независимы (настолько я не знаком с zVM, чтобы определить это), то такая типизация теряет смысл, поскольку zVM переиспользует гипервизор 1-го типа, находясь рядом с ним, но не являясь гипервизором 2-го типа.
SIISII
31.10.2025 21:05Нет, микрокод -- это то, что существует внутри процессора и для программиста вообще никак не заметно: на уровне программы нельзя понять, выполняет ли некую операцию железка полностью железной логикой или же под управлением микропрограммы.
Обращаю внимание, что английский термин firmware не полностью аналогичен русской "микропрограмме" или "микрокоду": он более широкий: так именуют и прошивки разных устройств, и микропрограммы, реализующие системы команд сложных процессоров. В русском эти вещи различаются (хотя сейчас есть тенденция валить всё в одну кучу).
artscan
31.10.2025 21:05Я имел дело с серверами IBM на архитектуре Power и под ОС Linux, но не с мейнфреймами. И на HPC кластере, без виртуализации. Больше всего запомнилось отличие petitboot загрузчика (PowerPC на Linux) от загрузчика x86. https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/
Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Мне представляется, что аналогично тому, как в firmware маршрутизатора можно реализовать функционал, например, брандмауэра, так и в firmware мейнфрейма (в т.ч. его процессоров) можно реализовать функционал гипервизора. И он будет 1-го типа, поскольку близок к железу и узкоспециализированный.
SIISII
31.10.2025 21:05Мне представляется, что аналогично тому, как в firmware маршрутизатора можно реализовать функционал, например, брандмауэра, так и в firmware мейнфрейма (в т.ч. его процессоров) можно реализовать функционал гипервизора
firmware маршрутизатора -- обычная программа, выполняемая обычным процессором, а сам маршрутизатор -- это, по сути, обычный компьютер, просто оснащённый специализированной периферией для эффективного выполнения своей основной задачи. Тот же результат, только менее эффективно, можно получить на любом обычном ПК (поставь несколько сетевух, запусти соответствующее ПО -- и будет ПК маршрутизировать, как настоящий маршрутизатор, только медленно и печально, поскольку обычные сетевухи не имеют "железной" поддержки соответствующих функций, и всё придётся делать программно).
firmware процессора -- это его внутренняя часть, снаружи невидимая и для программиста, в том числе создателей ОС, неотличимая от аппаратуры. Это -- не программа в обычном смысле слова, она не выполняется процессором; наоборот, она управляет реальными электронными блоками процессора таким образом, чтобы процессор снаружи казался тем, чем он кажется. Путём изменения микропрограммы можно поменять поведение процессора -- например, расширить или вообще кардинально изменить систему команд. И такое на мэйнфреймах реально использовалось, а может, и сейчас встречается (например, ещё System/360 model 85 умела "прикидываться" IBM-овскими машинами 2-го поколения -- 7090, вроде б, а наша ЕС-1035 могла выполнять программы от нашего же Минска-32, хотя архитектурно это абсолютно разные машины с совершенно разным набором команд).
Обычный машинный код привязан к конкретной архитектуре машины -- грубо говоря, к её системе команд, однако ему без разницы, как внутри машина устроена. Можно взять программу, скомпилированную под Core i7-что-то-там, и запустить на Ryzen 5, и наоборот, поскольку эти процессоры, хотя и имеют большие отличия внутри, с точки зрения программиста выглядят одинаково (разве что могут отличаться наличием или отсутствием некоторых дополнительных команд). А вот микропрограмма теснейшим образом привязана к внутреннему устройству процессора, поскольку железом процессора она и управляет.
Ну и ещё раз повторяю: англ. firmware -- очень широкий термин, что порождает постоянные проблемы.
И, кстати говоря, микропрограммы может не быть вообще. Примитивные процессоры -- скажем, любые ARM и RISC-V -- её не имеют, там всё реализовано жёсткой логикой. У ранних высокопроизводительных мэйнфреймов тоже микропрограмм не было, делали всё в железе, а микропрограммы использовали на младших и средних моделях, чтобы экономить железо (скажем, у System/360 model 30 и у нашей ЕС-1020 физическое АЛУ было 8-битным, но с точки зрения программиста машина 32-битная; понятно, что для выполнения операции над 32-разрядными числами такое АЛУ должно отработать четыре раза -- микропрограмма этим и управляет). Но потом поняли, что, если не скупиться на исполнительные блоки (на АЛУ, грубо говоря), то жёсткое чисто схемное управление не имеет преимуществ по скорости над микропрограммным, зато создаёт кучу проблем, если машина сложная, поэтому стали использовать комбинированный подход: часть операций управляется аппаратурой, часть (реализация сложных команд) -- микропрограммой.
artscan
31.10.2025 21:05Освежил свои представления и оказалось, что в PowerPC Linux используется POWER Hypervisor, аналогичный мейнфреймовским. Приведу здесь немного информации об архитектуре из https://en.wikipedia.org/wiki/Hypervisor для удобства:
IBM provides virtualization partition technology known as logical partitioning (LPAR) on System/390, zSeries, pSeries and IBM AS/400 systems. For IBM's Power Systems, the POWER Hypervisor (PHYP) is a native (bare-metal) hypervisor in firmware and provides isolation between LPARs...For real-mode addressing by operating systems (AIX, Linux, IBM i), the Power processors (POWER4 onwards) have designed virtualization capabilities where a hardware address-offset is evaluated with the OS address-offset to arrive at the physical memory address.
Похоже, что для LPAR технологии не обязательны мейнфреймовские процессоры, она в таком же виде существует и для RISC POWER процессоров. Linux после petitboot просто грузится как гостевая ОС. А гипервизор реализован на уровне firmware, не требуя особой поддержки от микропрограмм процессоров .SIISII
31.10.2025 21:05Так LPAR -- это абсолютно не то же самое, что чисто программная виртуализация, реализуемая VM/370 и её наследниками, включая z/VM. Это, если угодно, разделение единой физической машины на несколько "подмашин" чисто аппаратными средствами. Вот представьте, например, что у вас есть машина с двумя процессорами, двумя модулями памяти и двумя дисками. Всё это может работать совместно, как обычная двухпроцессорная машина, но может быть разделено таким образом, что получаются две абсолютно независимые реальные (а не виртуальные!) машины, хотя физически они остаются единым целым. Поэтому ОС, работающая в разделе LPAR, в действительности работает прямо на реальном железе, а не под управлением программного гипервизора. Так что реализовать подобное LPAR на других архитектурах вполне возможно -- технически всё сводится к коммутации шин между процессорами, блоками памяти и периферией.
artscan
31.10.2025 21:05В случае нашего HPC вообще просто: гостевому Линуксу одному отдаются все доступные ресурсы. Т.е. аппаратные средства (или по-другому Power PHYP native bare-metal hypervisor in firmware) запускают одну ОС в одной партиции и больше ничего особенного не делают. Все дублирующие элементы машины с несколькими процессорами https://shorturl.at/3OfVx используются только для эффективности вычислений.
Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
С моей точки зрения, оба они программные гипервизоры, просто один из них находится в firmware, а другой - в ОС z/VM. И этому гипервизору в ОС z/VM требуется поддержка микропрограмм процессоров, упомянутая в статье, чтобы эффективнее осуществлять свою виртуализирующую деятельность.SIISII
31.10.2025 21:05Неверная точка зрения. LPAR технически возможна вообще без каких-либо программных средств -- от слова совсем. Более того, она, по сути, существовала уже в конце 1960-х (у нас -- лет на 10 позже), хотя никакого особого названия тогда не носила. Просто стояли рядом два мэйнфреймовских процессора, могли совместно использовать память друг друга, имели общее поле внешних устройств -- т.е. была обычная двухпроцессорная машина в современном понимании. Но в любой момент инженеры могли отключить кабели или переключить рубильники -- и вместо одной двухпроцессорной машины получалось две однопроцессорных, никак между собой не связанных (но продолжающих стоять в одном машинном зале). Вот современный LPAR -- абсолютно то же самое концептуально, только вместо двух шкафов на один процессор используется одна микросхема для ннадцати процессоров, а для изменения конфигурации инженерам не надо бегать по машинному залу, а достаточно нажать пару кнопочек на сервисном компьютере, который электронным образом перекоммутирует связи основных узлов.
И, кстати, что VM/370, что z/VM способны работать без какой-либо специальной поддержки виртуализации -- им хватает самой что ни на есть обычной виртуальной памяти. Поддержка виртуализации ускоряет ряд операций, но не более того.
artscan
31.10.2025 21:05Кажется, пришло время цитировать Таненбаума:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
Чувствительная к управлению инструкция (control sensitive instruction) – это инструкция, которая может повлиять на конфигурацию машины...
Инструкция, чувствительная к поведению (behavior sensitive instruction) – это команда, действие которой частично определяется контекстом, в котором она выполняется...
...не все наборы инструкций имеют конфиденциальные (т.е. чувствительные?) инструкции только для привилегированных пользователей, в том числе, пожалуй, самый популярный – набор инструкций Intel x86. Как оказалось, в этом наборе 17 конфиденциальных инструкций, которые не являются привилегированными.
...пока конфиденциальные инструкции перехватываются при выполнении в пользовательском режиме, мы можем безопасно выполнять все нечувствительные инструкции непосредственно на базовом оборудовании.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.SIISII
31.10.2025 21:05Не только, но и это тоже. Точней, то, что в мэйнфреймах IBM в плане защиты сразу всё сделали правильно (все команды, имеющие отношение к управлению машиной в целом, являются привилегированными), явилось технической базой для создания гипервизора без необходимости добавлять в машину какую-то специальную поддержку: как только прикрутили MMU для организации виртуальной памяти, сразу стала возможной виртуализация всей машины. Но полноценная виртуализация ввода-вывода была бы невозможна, если б ввод-вывод был организован так, как это имеет место у основной массы архитектур.
zVlad909 Автор
31.10.2025 21:05Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
Нет на МФ никаких "чувствительных инструкций" как подмножество привилегированных. Ваш Таненбаума пишит только про процессоры х86 и им подобные.
В моей статье и в сообшении SIISII сказано ясно есть набор инструкций МФ подмножеством которого являются инструкции супервизора или гипервизора не важно, выполнение которых возможно исключительно в состоянии супервизор.
Вместо множества Ring-ов, которые доступны всем ОС на х86 и что с ними делать не понятно (к счастью две основные системы используют только два ринга, а также используют только один метод виртуализации памятьи из нескольих возможных) на МФ ровно два набора инструкций и ровно один метод виртуализации.
Представьте что было бы с виртуализацией ОС х86 если бы она использовала все ринги и все методы виртуализации памяти. Это был бы конец всему. На МФ любые мыслемые ОС будут работать на виртуалке zVM.
artscan
31.10.2025 21:05Кем эта типизация была введена и зачем я не знаю
В Википедии ссылаются на тезисы Гольдберга 1973 года "Architectural Principles for Virtual Computer Systems", где он впервые ввел эту типизацию.
Собственно, Таненбаум тоже ссылается на Гольдберга 1974 года, когда пишет про чувствительные инструкции.
А архитектура x86 появилась в 1978 году только.
zVlad909 Автор
31.10.2025 21:05А виртуальные машины на МФ появились в середине 60-х. Заметил что в этой работе есть ссылки на CP-67.
А единственное место в стаье где появляется слово "Type":
Note that this example illustrates a Type I f-map in which resources of level n + 1 are mapped into resources of level n.
А про Тип II нет вообще ничего.
Вообще все эти глубокомысленные и математикобразные рассуждения имеют мало практического смысла, и в то же время применимы не только в отношении виртуальных машин, а вообще систем разделения времени и ресурсов.
Виртуальные же машины лишь один из возможных, и не самый эффективный, метод создания систем разделения времени и ресурсов. А именно это и нужно от операционных систем. Достижение этого через виртуальные машины даже в теории не эффективно, т.к. предполагает дублирование в организации доступа к ресурсам и времени процессора.
На МФ есть более эффективное решение это - z/OS.
Я впервые услышал об этом еще в конце 80-х, или начале 90-х. От начальника отдела НИИ ЭВМ по СВМ ЕС услышал. Причем он сам пересказывал кого-то еще. Или это было из какой-нибудь зарубежной статьи.
Но тогда я был фанатом VM/SP и меня это не удовлетворило. Но после последних 20+ лет работы с z/OS я в этом сам многократно убедился.
artscan
31.10.2025 21:05Вы перепутали статью на 39 страниц и тезисы на 249 с похожим названием. Это оттуда
На мой взгляд наоборот: на математике вся компьютерная наука держится. Например, теория типов. Она применяется, как для определения свойств безопасности языков, например тех же инструкций x86 или другого набора. Так и для упрощения отладки и много чего еще. Без строгих математических оснований ничего бы столь сложного, как машины и операционные системы, не существовало бы.
zVlad909 Автор
31.10.2025 21:05Кто бы еще пользовался "строгими математическими основаниями". Двигателем развития ИТ является жажда наживы. Лишь пара-тройка первых десятилетий истоприи ИТ математика и другие научные обоснования играли роль и к ним прислушивались. Начиная с 90-х ИТ это чисто коммерчесчкая сфера деятельности.
artscan
31.10.2025 21:05z/VM способны работать без какой-либо специальной поддержки виртуализации -- им хватает самой что ни на есть обычной виртуальной памяти
Кажется, разобрался во всех вариантах. Можно рассматривать такие виды гипервизоров: manual, hardware, firmware, software. Если вручную коммутаторы рубильниками переключать, это manual hypervisor, но это больше шутка.
Аппаратная поддержка виртуализации может быть в процессорах и, возможно, в другом железе. Но самодостаточный hardware hypervisor, совсем без задействования firmware или software, вряд ли возможен.
Также, возможна поддержка виртуализации на уровне прошивки, firmware, если в ней, например, реализован гипервизор 1-го типа. Гипервизор 1-го типа может быть и в виде software, как это часто встречается в случае x86. Гипервизоры 1-го типа также задействуют аппаратную поддержку виртуализации при её наличии.
z/VM, как операционная система, является гипервизором 2-го типа, software, и может работать standalone, без какой-либо поддержки виртуализации, будь-то hardware или firmware.
Когда z/VM запущена поверх PR/SM, т.е. с поддержкой виртуализации на уровне firmware, то она уже строго говоря не относится ко 2-му типу. Тут лучше говорить про 2-tier гипервизор.
Классически, операционная система абстрагирует возможности железа, виртуализирует, создавая интерфейс, который можно назвать extended machine.
Могу предположить, что в случае мейнфреймов, применяется общая, более узкая абстракция физической машины, которую можно переиспользовать для разных операционных систем и другого системного ПО, такого как гипервизоры 1-го типа.
Эта абстракция и называется в статье настоящей виртуальной машиной.SIISII
31.10.2025 21:05В общем, пожалуй, верно, хотя есть определённые нюансы, связанные с тем, что VM/370 и, надо полагать, z/VM (с современными мэйнфреймами я дела не имел, поэтому на 100% утверждать не могу) способна работать без какой-либо поддержки со стороны процессора, но при её наличии получает преимущества по скорости. Вот простой пример.
В изначальной Системе 360 было единственное средство отсчёта времени -- так называемый интервальный таймер. С точки зрения программиста, это было слово (4 байта) в памяти машины по адресу 50(16), значение которого постепенно уменьшалось, и когда становилось отрицательным, появлялся запрос на внешнее прерывание. В Системе 370 были введены другие средства отсчёта времени, а в более поздних версиях архитектуры интервальный таймер вообще выпилили.
Очевидно, что любой виртуальной машине, которая нуждается в интервальном таймере (а это любая машина, на которой предполагается запускать любую из "классических" ОС, рассчитанных на Систему 360, а зачастую и на Систему 370), нужно обеспечить, чтоб содержимое слова по её виртуальному адресу 50 изменялось аналогично железному интервальному таймеру. Гипервизор может реализовать это чисто программно: когда происходит физическое прерывание, он должен обновить соответствующие слова в памяти всех виртуальных машин. Понятно, что этот процесс занимает определённое время и не слишком эффективен. Поэтому довольно многие процессоры Системы 370 (например, наши ЕС-1035 и ЕС-1130, но наверняка и все остальные) имели специальную поддержку для гипервизора, упрощая эмуляцию интервального таймера для виртуальных машин (следили за обращением гостевой ОС к соответствующей ячейке, избавляя гипервизор от необходимости либо постоянно обновлять эту ячейку, либо вообще блокировать доступ ко всем нижним 4 Кбайтам виртуальной памяти, чтобы отлавливать обращения к таймеру).
Вот и возникает вопрос: к какой категории относится гипервизор, если он использует подобного рода поддержку, ежели обнаруживает её во время своей инициализации, но при этом сохраняет возможность работать без неё? (Например, та СВМ ЕС, что была в моём распоряжении, не могла использовать поддержку, имеющуюся в ЕС-1035: версии не совпадали; вот на ЕС-1130 она пользовалась всем, что там было).
Ну и, опять-таки, путаница с firmware: и в ЕС-1035, и в ЕС-1130 поддержка была в значительной степени на уровне микропрограммы -- т.е. firmware по-буржуйски, но это абсолютно не то же самое, что поддержка на уровне программы, зашитой в ПЗУ (типа BIOS на ПК) -- это часть процессора, неотличимая для программиста, включая создателя гипервизора, от "железных" функций аппаратуры.
zVlad909 Автор
31.10.2025 21:05Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
На самом деле запуск тысяч виртуалок на МФ под zVM в логических партициях не является ни панацеей не самым эффективным способом использования МФ.
Более эффективно есть и будет использование МФ под z/OS, который совмещает в себе и ОС и гипервизор виртуальных машин, правда это машины ОС MVS, ОС Unix или контейнеры с Линуксами.
Это более эффективно потому что в случае тысяч виртуалок мы можем оптимизировать только каждую виртуалки в отдельности, но не всю их совокупность. В то время как в z/OS мы имеем возможность оптимизировать всю совокупность работ под ней и даже всю совокупность логических партиций с ОС z/OS на МФ.
artscan
31.10.2025 21:05Здесь https://www.ibm.com/docs/en/zos/2.5.0?topic=environment-hardware-environments-that-zos-supports говорится, что z/OS может запускаться в следующих окружениях:
- LPAR under PR/SM
- Virtual machine under IBM z/VM
Examples of hypervisors are the tier-1 hypervisor, Processor Resource/System Manager (PR/SM), that is built into the IBM Z hardware and creates and manages logical partition (LPAR) virtual machines, and the tier-2 hypervisor, IBM z/VM®, which can host many virtual machines. Like many IBM Z operating systems, z/VM itself runs in an LPAR.
То есть, z/OS не содержит в себе гипервизор, а переиспользует либо PR/SM, либо z/VM.
Именно, чтобы избегать подобных смысловых неточностей, и хотелось бы классифицировать программные компоненты.zVlad909 Автор
31.10.2025 21:05Чтобы не было написано, хоть бы и в ИБМ доках, думать самостоятельно тоже надо.
К сожалению и ИБМ не идеален. Докуманты 2023 года явно писались не отцами МФ, z/OS and z/VM. Возможно недопонимание писателей новых редакций.
"logical partition (LPAR) virtual machines " - эта фраза, приведенная Вами из дока ИБМ, ошибочна. LPAR не является виртуальной машиной. И нигде в других доках LPAR не называется так.
В старых документах, которые я читал еще в 1980-е годы не было ничего про Type, or Tier. Тогда и PR/SM еще только появлялся на горизонте, не было еще z/OS была MVS и работали тогда на машинах без LPAR вообще.
Спрашивается кокого типа гипервизором была тогда VM/370 и VM/SP?
То есть, z/OS не содержит в себе гипервизор, а переиспользует либо PR/SM, либо z/VM.
z/OS может представляться одной из трех ОС: MVS, USS (Unix), and zCX (Linux). Как Вам кажется есть в нем гипервизор или нет?
zVlad909 Автор
31.10.2025 21:05Путём изменения микропрограммы можно поменять поведение процессора -- например, расширить или вообще кардинально изменить систему команд. И такое на мэйнфреймах реально использовалось, а может, и сейчас встречается (например, ещё System/360 model 85 умела "прикидываться" IBM-овскими машинами 2-го поколения -- 7090, вроде б, а наша ЕС-1035 могла выполнять программы от нашего же Минска-32, хотя архитектурно это абсолютно разные машины с совершенно разным набором команд).
Даже знаю имя разработчика - Котов Михаил Петрович.Увы, умершего.
Он был начальником отдела в НИИ ЭВМ занимавшегося СВМ ЕС (VM/370, VM/SP). Много с ним общался в командировках и на семинарах.
Что касаемо микропрограммирования и микрокодов, то подозреваю что в процессоре МФ даже не два, а более уровней микропрограммирования. Слышал давно про макрокод, который между микро и тем что уже представляет набор команд для программирования ОС и прикладных программ.
SIISII
31.10.2025 21:05Ну, подробности устройства процов современных мэйнфреймов не раскрываются, поэтому можно только гадать. В тех, где хоть какая-то более-менее подробная информация о микроархитектуре имеется, -- более-менее обычные одноуровневые микрокоманды + схемная реализация некоторых простых, но важных вещей вроде выборки и декодирования команд.
zVlad909 Автор
31.10.2025 21:05Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Нет, конечно же firmware это самостоятельный вид деятельности и совмещать его с разработакой z/VM просто нецелесообразно. Кстати z/VM строго говоря не операционная система. Операционная система это система выполнения прикладных программ, это в общем случае система виртуальной машины. z/VM это гипервизор.
Но Вы правы что поскольку и железо и системное программное обеспечение в случае МФ это одна и та же фирма, то разработка обеих сторон ведется и велась согласованно. Т.е. в железе появлялись те и только те возможности что востребованы хотя бы одной ОС МФ. И это не zVM, а z/OS на самом деле. Только z/OS использует все возможности МФ.
duselguy
31.10.2025 21:05"... firmware это самостоятельный вид деятельности и совмещать его с разработкой z/VM просто нецелесообразно."
Справедливости ради, был исторический этап с VM/SP и hardware assist. Но сейчас, IBM нет особого смысла вкладываться в производительность zVM, так как эра VSE под VM ушла, а 100500 Линукс под zVM не зашла, и zVM используется для разработки, отладки и тестирования zOS.zVlad909 Автор
31.10.2025 21:05Справедливости ради, был исторический этап с VM/SP и hardware assist. ....
Я полагаю что VM/SP hardware assist уже давно интегрирован во все новые процессоры МФ. В современных МФ для VM and Linux предусмотрен тип процессора IFL (Integrated Facility for Linux). Вроде как не про VM но это оно и есть. В принципе этот тип процессора такой как и основной просто на нем не будет работать z/OS.
.....zVM используется для разработки, отладки и тестирования zOS.
Да были времена когда отладка MVS под VM была важной сферой применения VM в IBM. Но вряд ли сейчас это так важно имея LPAR и средства отладки в самом z/OS.
На МФ LinuxONE основым способом применения zVM является выполнение Линукс виртуальных машин.
Для z/OS в пользовательском применении виртуальные машины совершенно не нужны. Я думаю нет таких применений вообще. По крайней мере сильно удивлюсь если ошибаюсь.
А вот на х86-64 мы видим широкое применение виртуальных машин Windows and Linux. Интересно, правда? И нет логического партиционинга - LPAR. Тоже интересно и показательно.
duselguy
31.10.2025 21:05"Да были времена когда отладка MVS под VM была важной сферой применения VM в IBM. Но вряд ли сейчас это так важно имея LPAR и средства отладки в самом z/OS."
Здесь Вы заблуждаетесь. Тестировщики имеют по несколько виртуальных машин (например, для сисплекса), разработчики - минимум по одной. И дело не только в средствах отладки в VM из коробки, если подумать и посчитать. LPAR используется при системном (нагрузочном) тестировании и тестах (проблем) производительности.zVlad909 Автор
31.10.2025 21:05Вы работаете в этой сфере?
Я имел в виду средства отладки в z/OS (MVS). Не в VM, хотя в последнем тоже есть очень мощные срество отладки ОС ВМ.
duselguy
31.10.2025 21:05Я имел в виду, что разбрасываться партициями дорого, а более одного разработчика/тестировщика в партиции проблемно.
По поводу отладки (коротко): встроенный в zOS на уровне языка, zVM на уровне ассемблера.
P.S. Дела давно минувших дней, Преданья старины глубокой. (©)
P.P.S. И, да, для внутреннего отладчика нужен исходный код и компилятор с опциями. При этом вы отлаживаете только свой кусок, который пересобрали. А если вы наводите ошибку в другой компоненте? Без средств отладки zVM поймать это будет (значительно) сложнее.zVlad909 Автор
31.10.2025 21:05Безусловно переоценить роль zVM в отладке любых ОС МФ, особенно ядер, невозможно. Трассировки на виртуальной машине и пошаговое выполнение с возможностью просмотра памяти и регистров это здорово. Но в самом zOS есть GTF (это не уровень языка):
The generalized trace facility (GTF) is a service aid you can use to record and diagnose system and program problems. GTF is part of the MVS system product, and you must explicitly activate it by entering a
START GTFcommand.Use GTF to record a variety of system events and program events on all of the processors in your installation. If you use the IBM-supplied defaults, GTF lists many of the events that system trace lists, showing minimal data about them. However, because GTF uses more resources and processor time than system trace, IBM® recommends that you use GTF when you experience a problem, selecting one or two events that you think might point to the source of your problem. This will give you detailed information that can help you diagnose the problem. You can trace combinations of events, specific incidences of one type of event, or user-defined program events that the GTRACE macro generates. For example, you can trace:
Channel programs and associated data for start and resume subchannel operations, in combination with I/O interruptions
I/O interruptions on one particular device
System recovery routine operations
SLIP:
lip z/OS" refers to SLIP (Serviceability Level Indication Processing) commands used on IBM's z/OS operating system to trap system events for diagnostic purposes. These traps allow administrators to capture detailed information, such as dumps, when specific conditions are met, which helps in problem diagnosis when standard error reporting is insufficient. SLIP commands use a
SLIP SETcommand with parameters likeACTION,CONDITION, andMATCHLIMto define what to trap and what action to take when a match occurs.Когда я имел проблемы ИБМ саппорт всегда запрашивал эти два источника данных и оказывал действенную помощь.
Думаю и разработчики в определенных условиях используют эти два тулза, работая в одном имидже z/OS, который трудно убить проблемами не только в прикладных программах, но и в системных компонетах.
Проблема отладки средствами виртуальной машины в том что знать где останавливаться и надо уметь копаться в цепочках управляющих блоков и знать где лежать указатели на них. А эти средства дают более адресную расшифровку.
Кмк, трассировка в ВМ хороша в случае отладки функций ядра системы. Это само по себе уникальное занятие в наши дни.
Средства чтения дампов в z/OS тоже есть.
Я не в плане критики, а в плане дополнения.
P.S. В z/OS каждую системную компоненту (TCP/IP, DFSMS, JES2 etc...) можно запускать в несльких экземплярах и отлаживать их, роняя, беря дампы и поднимая снова несколькими разработчиками одновременно и в одной партиции. Это современный уровень z/OS такой.
duselguy
31.10.2025 21:05GTF - мимо, если компонента в него не пишет. SLIP - на стороне заказчика (дамп по программному прерыванию, etc.). zVM (у себя) - останов по адресу, прогр. прерыванию, етс., покомандное исполнение, етс.
"В z/OS каждую системную компоненту ...". 1) Не каждую. 2) А если у двух разработчиков общий модуль в LPA? 3) Туева куча других проблем ...
zVlad909 Автор
31.10.2025 21:05Согласен. Но все же пути есть разные. Нет такого что только один путь.
zVlad909 Автор
31.10.2025 21:05Простое решение этой дилемы похоже на решение дилемы курицы и яица. VM появилась таки раньше PR/SM. 1972 (даже раньше) и 1988. При этом никаких изменений ни в VM ни в PR/SM не вносилось. Но не VM не какая другая ОС МФ "рядом с ним" загрузиться на МФ не может.
Тут все дело именно в архитектуре и принципах работы МФ. Именно они позволяют виртуализировать именно реальный МФ и делать это даже на ВМ. Вложенность бесконечна, боле одного VM на ВМ практического смысле не имеет. Ради фана я грузил VM на ВМ VM-а, который выполнялся на ВМ VM первого уровня. И работал в ВМ третьего уровня. Но это неи чем не было обоснованно. Загрузка VM на ВМ имеет смысл протестировать вновь сгенерированную VM.
Конечно PR/SM это гипервизор. Но это настолько встроено в архитектуру МФ что ни одна ОС не сможет различить наличие PR/SM иначе как проверив модель МФ и зная что на этой модели есть гипервизор. Т.е. другими словами PR/SM не создает никаких ограничений на архитектуру и принципы работы. Он прозрачен для любых программ включая ОС и в том числе zVM.
А вот zVM для гостевой ОС может быть заметен и может ограничивать некоторые возможности МФ. Поэтому zVM не равно PR/SM в смысле типизации гипервизоров. PR/SM не выполняется на архитектуре МФ, он ее создает на совсем другой архитектуре. Так что zVM это все таки первый гипервизор выполняющийся на архитектуре в смысле принципов работы МФ.
На х86 тоже есть микрокод. Если это учитывать то вообще ни один программный гипервизор не может быть гипервизором Тии 1.
SIISII
31.10.2025 21:05На ARM микрокода нет. И, более того, его наличие у мэйнфреймов или там IA-32/AMD64 -- не неизбежность, можно было бы всё сделать на жёсткой логике -- просто последнее было бы сильно сложней и дороже.
artscan
31.10.2025 21:05Нашел неплохое объяснение https://shorturl.at/jNlSU
It’s important to note that the lines between z/VM being categorized as type 1 and type 2 hypervisors are blurred; I’ve seen it labeled as Type 1 in some articles, but the reference I have provided lists it as Type 2. z/VM does not fall into the description of a Type 1 hypervisor because it operates on top of Type 1
Поэтому, лучше использовать 1-tier и 2-tier терминологию, а не 1, 2 тип, поскольку z/VM работает поверх PR/SM.
Когда на ранних периодах своего существования, z/VM запускалась без PR/SM, являясь при этом операционной системой, она относилась ко 2-му типу. Но когда её стали запускать только поверх PR/SM, такая типизация устарела. А для x86 она до сих пор актуальна.
GidraVydra
31.10.2025 21:05Поэтому на МФ возможно то что невозможно на х86-64, а именно загружать zVM на виртуальной машине, а в ней, на её ВМ второго уровня, загружать другую zVM. И так далее.
Процессоры х86 с аппаратной виртуализацией доступны лет 20 как. И на компьютерах с этими процессорами тоже можно создавать многократно вложенные виртуальные машины.
4external
Познавательно. Спасибо за статью!