Краткая, упрощенная история виртуальных машин
На 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 диски ВМ в общем случае это файлы в файловой системе гипервизора. И есть два уровня драйверов: реальный и виртуальный.
Дополнение из диалога в комментариях.
Один мой оппонет в комментариях проявил интерес к глубинам МФ. Причем сделал он это с позиций "общей теории виртуализации" экстраполировав это на МФ. Я решил сделать этот диалог более доступным чем в комментариях и добавил его в статью (ниже цитаты с прямой речью это из сообщения моего визави. Собственно кроме последней цитаты все первые его):
PR/SM решает задачу диспетчеризации (задачу планирования) логических CPU (виртуальных) по физическим. Физические процессоры имеют своё расположение на микросхеме, расстояния и соединения между чипами, значения объемов быстрых и медленных кешей и т.д. Если бы виртуальные процессоры не были бы абстракцией, а в точности отображали все детали устройства физических процессоров, то оптимизации были бы невозможны.
В случае с МФ все ОС в логических партициях (LPAR) знают и используют физические характиристики процессоров с целью оптимизации диспетчирования процессов (ВМ в случае zVM). Наоборот, без этого, будь PR/SM не "прозрачен", предоставлял бы он партициям абстрактные процессоры, оптимизация была бы невозможной. Про как это (HiperDispatch) работает в случае zVM можно узнать вот из этой статьи.
https://www.vm.ibm.com/perf/tips/zvmhd.html
Абсолютно идентичный функционал (HiperDispatch) имеется и в z/OS.
И вот скрины команды z/OS DISPLAY M=CPU где z/OS показывает все CPU МФ, в партиции которого он выполняется, в отметками тех CPU, котороые он может использовать:
... и скрин с HMC для конфигурации процессоров партиции z/OS показаного выше:
Здесь CPU заданы количеством, по типам, и как видите 2 сконфигурированны как зарезервированные. Дело в том что всего на этом МФ шесть процессоров общего назначения. Четыре из их на данный момент активированы для использование. В дальнейшем один или два могут быть тоже активированны и чтобы не прервать работу этой партиции указаны два зарезервированных, которые могут активированы в z/OS этой партиции "на ходу" командой CONFIG CPU.
zIIP процессор это спецпроцессор, используется в некоторых функциях DB2 и для выполнения Java кода, напримр, в WebSphere.
Обратите также внимание на поле "Initial processing weight" это, как видно из названия, вес данной партиции используемый PR/SM для вычисления процента времени CPU, которое может быть предоставлено данной партиции с учетом весов остальных активных партиций. Без capping (бокс "Initial capping" не выбран) это также означает что если остальные партиции не выполняют ничего то 100% времени будет предоставленно этой партиции. Это все делается PR/SM.
Как только мы скрываем какие-то детали устройства физических процессоров, становится возможным получать те или иные преимущества от абстракции.
Например какие? Такие:
Например, иметь количество логических процессоров большее, чем физических.
Чем больше процессоров тем больше издержки ОС ВМ на диспетчирование процессов. Я знаю что MS SQL может отказываться и отказывается использовать "лишние CPU". Тоже самое Вы найдете в описании HiperDispatch приведеном выше.
Точно также работает абстракция на уровне z/VM, но там в силу вступают другие факторы и нужно скрывать другие детали.
Точно не так. Ничего на МФ от ОС партиций не скрывается. Более того ОС партиций имеет доступ к "железу" через Base Control Program internal interface (BCPii):
IBM предоставляет поддержку в z/OS, которая позволяет авторизованным приложениям запрашивать, изменять и выполнять рабочие процедуры на установленной аппаратной базе z System через набор интерфейсов прикладных программ. Эти приложения могут получать доступ к оборудованию z System, на котором запущено приложение, и расширять свою зону действия на другие процессоры z System в подключенной сети управления процессами (Hardware Management Console).
https://public.dhe.ibm.com/s390/zos/racf/pdf/ny_metro_naspa_2011_03_22_intro_to_bcpii.pdf
https://www.ibm.com/docs/en/zos/3.2.0?topic=services-base-control-program-internal-interface-bcpii
Конец статьи.
Я даю себе отчет в том что статья получилась сумбурной, с издержками и многими недостатками. Но согласитесь тема эта довольно глубокая, обстоятельства тонки, а сравнение таких вещей как МФ и х86 весьма затруднительно. Гораздо проще было бы сделать введение в виртуализацию на МФ, введение в то же самое на х86 и оставить сравнение их читателю. На интернете можно найти такие сравнения, но они во многих случаях банальны и зачастую неточны, и даже ошибочны. Но я попытался сделать больше. Получилось это у меня или нет, судить читателям.
