Comments 95
Познавательно. Спасибо за статью!
Раздел "Настоящая виртуальная машина" полностью применим к x86-64 (и ARM) с расширениями для виртуализации, которые есть примерно на всех актуальных серверных процессорах и на старших десктопных. Вы сравнили не виртуализацию на МФ и на x86-64, а виртуализацию с аппаратной поддержкой (МФ и неупомянутые современные x86-64) и без нее — с очевидным результатом.
Было бы интересно узнать больше про каналы даже без связи с виртуализацией (думаю, это тема на целую статью).
Раздел "Настоящая виртуальная машина" полностью применим к x86-64 (и ARM) с расширениями для виртуализации, которые есть примерно на всех актуальных серверных процессорах и на старших десктопных
На самом деле, не совсем. Хотя введение расширений виртуализации решило (вроде бы -- досконально я этот вопрос не изучал) проблему, связанную с тем, что в 80286/386 ряд команд, системных по своему смыслу, были сделаны непривилегированными), остаётся проблема ввода-вывода -- а без него нет виртуальной машины (компьютера), есть только виртуальный процессор :)
Чтобы на ПК получить виртуализацию, аналогичную мэйнфреймам, нужно сделать такой гипервизор, чтобы абсолютно любая гостевая система работала корректно при любых, даже самых нестандартных её обращениях к периферии. Более того, при подключении какой-то новой железки эта самая железка должна нормально работать под управлением гостевой ОС, даже если сам гипервизор понятия не имеет, как эту железку виртуализировать. На архитектуре ПК такое попросту невозможно, на мэйнфреймах -- элементарно в силу принципиальной иной организации ввода-вывода. (Но есть и обратная сторона: мэйнфреймовский ввод-вывод менее гибок и, скажем культурно, плохо подходит под, например, "ногодрыг" и прочие типично микроконтроллерные задачи).
Чтобы на ПК получить виртуализацию, аналогичную мэйнфреймам, нужно сделать такой гипервизор, чтобы абсолютно любая гостевая система работала корректно при любых, даже самых нестандартных её обращениях к периферии.
А для этого необходимо отказатсья от MMIO и перейти на "каналы". PCI и PCIe это движение в нужном направлении, но что делать со всем остальным железом ? Где-то читал, что IOMMU не решает всех проблем виртуализации, а только создает новые.
Проблема в не шинах (электронной реализации), проблема в самой концепции ввода-вывода, управление которым везде, кроме мэйнфреймов, сводится к записи и чтению регистров устройств как обычных адресуемых ячеек (памяти или пространства ввода-вывода -- неважно). Чтобы виртуализировать такое устройство, программа-виртуализатор должна отслеживать все операции записи и считывания этих регистров (что может быть накладным, но технически вполне выполнимо) и программно эмулировать работу устройства, чьи регистры пишутся или читаются. В теории это осуществимо, и для простых устройств качественная эмуляция (если угодно, виртуализация) существует, однако создать такой программный эмулятор для каждого устройства ПК на практике нереально из-за нереального количества этих железяк, их плохой документированности и т.д. и т.п. Поэтому ограничиваются некоторым подмножеством, достаточным для работы Винды и Линуха, но что-то нестандартное, успешно работающее на реальном железе, запросто может оказаться неработоспособным на такой виртуальной машине (даже с такой, вроде бы, банальщиной, как прокинуть железные USB-порты на виртуальную машину, есть проблемы).
Ну и проблема с использованием устройств, с которыми не знаком сам гипервизор. В VM/370 и её потомках такие устройства могут просто полностью отдаваться в распоряжение гостевой ОС, умеющей с ними работать, а роль гипервизора сводится к преобразованию адреса устройства и адресов блоков памяти, участвующих в операциях ввода-вывода, что на мэйнфреймах является абсолютно идентичным для любого устройства и поэтому не требует от гипервизора знаний о том, что это за устройство и как именно оно работает. Ну а на других архитектурах эта задача, в общем случае, неразрешима, поскольку нет единого стандарта на взаимодействие устройств с центральной частью машины.
устройства могут просто полностью отдаваться в распоряжение гостевой ОС, умеющей с ними работать, а роль гипервизора сводится к преобразованию адреса устройства и адресов блоков памяти, участвующих в операциях ввода-вывода
Проброс устройств в вируталку с помощью IOMMU, разве нет?
Есть вопрос к модели работы самих устройств. Пример с диском удобный, потому что с любой его частью можно работать, как с целым диском, но возьмем сетевую карту — как в ней выделить кусок, подобный целой карте, без того, чтобы карта об этом знала? Какой компонент будет отвечать за распределение ресурсов карты? NVIDIA (Mellanox) делает нечто подобное, но строго при содействии карты. Из забавного, в их новых картах даже есть режим работы VF, когда железо притворяется VirtIO, чтобы гипервизору меньше транслировать.
С такими устройствами не получится -- их надо либо полностью выделять в распоряжение гостевой ОС, либо эмулировать программно. С последним, как я уже писал, проблемы из-за их высокой сложности на уровне управления ими (устройству нельзя просто выдать команду "прочитать блок данных", как это делается на мэйнфрейме, -- надо запрограммировать кучу регистров специфичным для конкретной модели образом, и т.д. и т.п.; соответственно, программный эмулятор должен корректно воспринимать всё такое программирование со стороны ОС и затем выполнять затребованную операцию).
А IOMMU далеко не всегда помогает. Скажем, если устройство может быть мастером шины (само выполняет прямой доступ к памяти), то надо преобразовывать его доступы к памяти таким образом, чтобы они выполнялись по адресам, выделенным виртуальной машине, причём именно тем, что гостевая ОС запрограммировала в регистрах этого устройства, да ещё учитывать, что нужные страницы памяти могут быть выгружены гипервизором...
А IOMMU далеко не всегда помогает. Скажем, если устройство может быть мастером шины (само выполняет прямой доступ к памяти), то надо преобразовывать его доступы к памяти таким образом, чтобы они выполнялись по адресам, выделенным виртуальной машине, причём именно тем, что гостевая ОС запрограммировала в регистрах этого устройства, да ещё учитывать, что нужные страницы памяти могут быть выгружены гипервизором.
В zVM, как написано в статье, гипервизор (СР) переисывает канальную программу в свою память и модернизирует ее так чтобы канал ввода-вывода писал данные в память СР. Конечно и память канальной программы и данных фиксируется на время выполнения канала. По окончанию ввода-вывода данные переписываютмя в память виртуальной машины.
Можно ли так же поступать в случае х86 я не знаю. Но там нет каналов и канальных программ. Там это делается драйверами.
В том и проблема, что на любой архитектуре, кроме мэйнфреймовской, похоже, нет возможности полностью и сколько-нибудь эффективно виртуализировать ввод-вывод без помощи со стороны гостевой ОС: у каждого устройства свои припадки, и всё учесть в гипервизоре представляется нереальным.
Ну а как виртуализация ввода-вывода на мэйфреймах работает, я знаю -- в своё время работал с СВМ ЕС, а в девичестве она, как известно, VM/370.
Команду "прочитать блок данных" воспринимает сама карта или нечто промежуточное транслирует команды в специфичные действия с железом? Если первое, то как гипервизор может транслировать неизвестные ему команды для произвольных устройств? Если второе, то это означает, что мы реального железа просто никогда не видим, а значит, можем работать только с тем, для чего это нечто умеет делать преобразование.
Не понял пассаж про IOMMU — ну да, он описанное делает. Гипервизор, очевидно, не должен выгружать страницы, отображение на которые он запрограммировал в IOMMU.
Команду "прочитать блок данных" воспринимает сама карта или нечто промежуточное транслирует команды в специфичные действия с железом?
Что Вы имеете в виду под "карта"? У меня нет никаких карт в описании работы канала. Нет ничего промежуточного между канальной программой созданной на ВМ кроме управляющей программы (СР). И нет трансляции команд. Под трансляцией понимается, для примера, сдвиг номера цилиндра диска с учетом реалного положения минидиска на реальном диске.
...как гипервизор может транслировать неизвестные ему команды для произвольных устройств?
Команды, в общем случае, не меняются.
Если второе, то это означает, что мы реального железа просто никогда не видим, а значит, можем работать только с тем, для чего это нечто умеет делать преобразование.
Не совсем так. Мой коллега SIISII объяснял что прелесть виртуализации ввода-вывода на МФ для совершенно не известных гипервизору устройств, но известных ОС ВМ, такое устройство закрепляется за ВМ (командой СР ATTACH (или оператором DEDICATE оглавления ВМ) и гипервизор всего лишь заменяет виртуальный адрес устройства (он всегда есть) на реальный (в принципе они могут совпадать, но это все равно произойдет) оставляя канальную программа ВМ для этого устройства неизменной лишт переписывая ее (как есть) в свою память и фиксируя страницу(ы) с программой и данными в реальной памяти. Остальное выполняется канало и устройством подключенным к этому каналу. .
Не понял пассаж про IOMMU
Честно говоря я не знаю что это такое и не упоминал этот термин. Может SIISII что-то мог бы сказать. По крайней мере у него в сообщении выше есть такие слова: "А IOMMU далеко не всегда помогает. ..."
На мэйнфреймах любые команды ввода-вывода интерпретируются и каналом (на современных машинах корректней говорить о канальной подсистеме, но в детали углубляться в данной дискуссии не требуется), и устройством одновременно. Канал смотрит только на несколько битов кода канальной команды, чтобы понять, в каком направлении будет идти обмен данными (чтение или запись, грубо говоря; есть нюансы, но в данном случае они неважны), устройство же интерпретирует весь код целиком. Поэтому для канала нет принципиальной разницы между командами, скажем, "прочитать информацию с диска" и "прочитать состояние диска" -- для него это команды ввода, и всё, что он должен сделать, -- передать команду устройству (стандартным образом), получить от него поток байтов (стандартным образом) и записать их в указанную в канальной программе область памяти (тоже стандартным образом). Само устройство к памяти не обращается, оно лишь взаимодействует с каналом по стандартному интерфейсу ввода-вывода: получает команды, после чего получает или отдаёт байты данных. По этой причине гипервизор может обслуживать устройства, в которых он не разбирается: он может интерпретировать канальную программу, поскольку её формат определён архитектурой, а не конкретными устройствами, а соответственно, он может скорректировать адреса областей данных (преобразовать из виртуальных адресов памяти виртуальной машины в абсолютные адреса физической памяти -- ведь гостевая ОС не знает, где она сидит в памяти, и те адреса, которые она считает абсолютными, на самом деле являются виртуальными). Иметь дело с кодами операций ему приходится лишь в той степени, чтобы понять направление передачи данных, да и то не всегда, соответственно, ему не нужно понимать специфику устройства.
но возьмем сетевую карту — как в ней выделить кусок, подобный целой карте, без того, чтобы карта об этом знала? Какой компонент будет отвечать за распределение ресурсов карты? NVIDIA (Mellanox) делает нечто подобное, но строго при содействии карты. Из забавного, в их новых картах даже есть режим работы VF, когда железо притворяется VirtIO, чтобы гипервизору меньше транслировать.
Вы задали вопрос и сами на него ответили. Да, это зависит от карты. Даже без zVM системы в партициях МФ совместно используют сетевые карты OSA. Вообще все что есть на МФ может использоваться совместно. Кроме оперативной памяти.
Настоящность ВМ можно проверить простым тестом - загрузить гипервизор на ВМ.
Ничего не мешает на x86
Неа. "Настоящесть" можно проверить, если запустить на ВМ тест аппаратуры, и он покажет, что вся аппаратура работает нормально -- но при этом тестировать он будет не реальное железо, а виртуальное. Вот это и будет настоящей 100% виртуализацией машины. Мэйнфреймовская... ну, она 95%: некоторые тесты таки не пройдут, если за виртуальной машиной соответствующее физическое устройство не закрепить напрямую (во всяком случае, в VM/370 не прошли бы, скажем, тесты 29-мегабайтных дисков -- IBM 2914, если память не изменяет, они же ЕС-5061, -- если бы использовались не реальные диски, а их "виртуалы": гипервизор для них не эмулировал выполнение специальных диагностических команд; понятно, что на работе нормальных программ, включая ОС, это никак не сказывалось, поскольку эти команды использовались только узкоспециализированным диагностическим ПО). Ну а ПК... жалкое подобие левой руки, прямо скажем.
Я на процессоре i7-6700 с Linux-хостом запускал ESXi (VMWare) как гостя в QEMU-KVM, а в ESXi — виртуалку с Linux. Вот статья 2017, где автор делает то же: https://habr.com/ru/articles/325090/.
Это другое. Правильным был бы тест запуска ESXi (VMWare) на виртуалке ESXi (VMWare). Или QEMU-KVM на виртуалке QEMU-KVM.
Впрочем в Вашей ссылке есть про это:
К счастью, ESXi поддерживает Nested Virtualization — то есть способность запускаться из-под уже работающего гипервизора. При этом и внешний гипервизор понимает, что его гостю нужен доступ к аппаратной виртуализации, и ESXi знает, что работает не на голом железе. Как правило, в качестве основного гипервизора также используется ESXi .....
Что значит "знает"? Значит что такое знание предусмотренно разработкой этих гипервизоров. Ну и хорошо. Но zVM, работая на виртуалке может конечно знать про виртуалку, но он не пользуется этим знанием.
Другие ОС МФ могут знать и использовать знание о том что они работают на виртуалке. Более того есть ОС (не гипервизор) МФ которые в принципе могут только работать на виртуалках.
Ну а вообще привденная Вами ссылка про то как заставить гипервизор принимать гостя гипервизора. Это танец с бубном. Я подозреваю что в итоге гостевой гипервизор у Вас просто работает рядом с хостовым гипервизором и они особо не мешают друг другу.
А в случае с zVM это работает по определению.
В той же статье следующим предложением после того, которое вы процитировали, написано, что VMWare внутри VMWare — это штатный сценарий. QEMU-KVM внутри QEMU-KVM тоже работает. Можно утверждать, и я согласен, что на МФ это организовано более стройно, но в статье вы пишете, будто на x86-64 гость-гипервизор невозможен, что неправда.
Хорошо. Больше не буду писать что на х86-64 гость-гипервизор невозможен. Но согласитесь что если это была штатная ситуация то никаких таких статей бы не было.
Особенно мне вот это понравилось:
Затем отключим невежливое поведение модуля KVM в моменты, когда гость пытается читать машинно-специфические регистры, которых на самом деле нет. По-умолчанию, KVM в ответ на это генерирует внутри гостя исключение General protection fault, отчего гость ложится в синий (в нашем случае-розовый) экран смерти. Сделаем под рутом:
root@debian-pc:/> echo 1 > /sys/module/kvm/parameters/ignore_msrsТаких отключений для гостей в zVM нет и быть не может. Все работает в соответствии с "Принципами работы" и ничего не надо отключать чтобы гость zVMработал на виртуальной машине.
Остальное в статье я читать не стал. Попахивает шаманством. Но если в итоге гость-гипервизор заработал, то я только рад и никогда больше не стану утверждать обратное. Спасибо. .
Было бы интересно узнать больше про каналы даже без связи с виртуализацией (думаю, это тема на целую статью).
Да тема большая. Но можно и вкратце объяснить.
Канал это отдельный компьютер ввода-вывода. CPU МФ никакого участия в выполнении ввода-вывода не принимает за исключением подготовки канальной программы и подачи сигнала каналу о том что программа для него готова и можно начинать ее исполнять.
Программа канала состоит из последовательности CCW - Channel Command Word. Программа канала может быть весьма сложной и иметь циклы и условные переходы. Это не просто установить, прочитать, записать. Одной канальной программой можно отформатировать диск.
Выполнение канальной программы завершается прерыванием ввода-вывода отражаемого на CPU. Каналы существенно разгружают CPU. Они входят в архитектуру МФ с самых первых дней. Но за это время технически они весьма преобразились.
Изначально это были отдельные шкафы соединенные с CPU толстыми многожильными кабелями, с другой стороны имелись Control Units (CU), а те в свою очередь своими кабелями соединялись с устройствами. В архитектуре и принципах работы все это (Channel, Control Unit, Devices) остается и сейчас. Но технически это все многократно изменялось с учетом новых технологий. С точки зрения программирования все осталось неизменным.
Количество каналов на современных МФ исчисляется сотнями. .
С какой целью была написана эта сиатья?
Это не zVM, это реальная машина МФ с партициями реализованными PR/SM (Processor Resource/Systems Manager), ошибочно считающимся Type-1 Hypervisor. Почему ошибочно? Потому что каждая партиция это реальный МФ. PR/SM это микропроцессор МФ и микрокод на котором написаны все те же "Принципы работы МФ".
Микрокод - это ведь software с точки зрения разработчиков МФ? Тогда слой этого микрокода реализует гипервизор 1-го типа. Если zVM хоть немного считать ОС общего назначения, то она реализует уже гипервизор 2-го типа. Особенно, если при этом она как-то расширяет функционал гипервизора за счет возможностей ОС, недоступных в слое микрокода. Если же функционал гипервизора и zVM полностью независимы (настолько я не знаком с zVM, чтобы определить это), то такая типизация теряет смысл, поскольку zVM переиспользует гипервизор 1-го типа, находясь рядом с ним, но не являясь гипервизором 2-го типа.
Нет, микрокод -- это то, что существует внутри процессора и для программиста вообще никак не заметно: на уровне программы нельзя понять, выполняет ли некую операцию железка полностью железной логикой или же под управлением микропрограммы.
Обращаю внимание, что английский термин firmware не полностью аналогичен русской "микропрограмме" или "микрокоду": он более широкий: так именуют и прошивки разных устройств, и микропрограммы, реализующие системы команд сложных процессоров. В русском эти вещи различаются (хотя сейчас есть тенденция валить всё в одну кучу).
Я имел дело с серверами 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-го типа, поскольку близок к железу и узкоспециализированный.
Мне представляется, что аналогично тому, как в 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-разрядными числами такое АЛУ должно отработать четыре раза -- микропрограмма этим и управляет). Но потом поняли, что, если не скупиться на исполнительные блоки (на АЛУ, грубо говоря), то жёсткое чисто схемное управление не имеет преимуществ по скорости над микропрограммным, зато создаёт кучу проблем, если машина сложная, поэтому стали использовать комбинированный подход: часть операций управляется аппаратурой, часть (реализация сложных команд) -- микропрограммой.
Освежил свои представления и оказалось, что в 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, не требуя особой поддержки от микропрограмм процессоров .
Так LPAR -- это абсолютно не то же самое, что чисто программная виртуализация, реализуемая VM/370 и её наследниками, включая z/VM. Это, если угодно, разделение единой физической машины на несколько "подмашин" чисто аппаратными средствами. Вот представьте, например, что у вас есть машина с двумя процессорами, двумя модулями памяти и двумя дисками. Всё это может работать совместно, как обычная двухпроцессорная машина, но может быть разделено таким образом, что получаются две абсолютно независимые реальные (а не виртуальные!) машины, хотя физически они остаются единым целым. Поэтому ОС, работающая в разделе LPAR, в действительности работает прямо на реальном железе, а не под управлением программного гипервизора. Так что реализовать подобное LPAR на других архитектурах вполне возможно -- технически всё сводится к коммутации шин между процессорами, блоками памяти и периферией.
В случае нашего 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 требуется поддержка микропрограмм процессоров, упомянутая в статье, чтобы эффективнее осуществлять свою виртуализирующую деятельность.
Неверная точка зрения. LPAR технически возможна вообще без каких-либо программных средств -- от слова совсем. Более того, она, по сути, существовала уже в конце 1960-х (у нас -- лет на 10 позже), хотя никакого особого названия тогда не носила. Просто стояли рядом два мэйнфреймовских процессора, могли совместно использовать память друг друга, имели общее поле внешних устройств -- т.е. была обычная двухпроцессорная машина в современном понимании. Но в любой момент инженеры могли отключить кабели или переключить рубильники -- и вместо одной двухпроцессорной машины получалось две однопроцессорных, никак между собой не связанных (но продолжающих стоять в одном машинном зале). Вот современный LPAR -- абсолютно то же самое концептуально, только вместо двух шкафов на один процессор используется одна микросхема для ннадцати процессоров, а для изменения конфигурации инженерам не надо бегать по машинному залу, а достаточно нажать пару кнопочек на сервисном компьютере, который электронным образом перекоммутирует связи основных узлов.
И, кстати, что VM/370, что z/VM способны работать без какой-либо специальной поддержки виртуализации -- им хватает самой что ни на есть обычной виртуальной памяти. Поддержка виртуализации ускоряет ряд операций, но не более того.
Кажется, пришло время цитировать Таненбаума:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
Чувствительная к управлению инструкция (control sensitive instruction) – это инструкция, которая может повлиять на конфигурацию машины...
Инструкция, чувствительная к поведению (behavior sensitive instruction) – это команда, действие которой частично определяется контекстом, в котором она выполняется...
...не все наборы инструкций имеют конфиденциальные (т.е. чувствительные?) инструкции только для привилегированных пользователей, в том числе, пожалуй, самый популярный – набор инструкций Intel x86. Как оказалось, в этом наборе 17 конфиденциальных инструкций, которые не являются привилегированными.
...пока конфиденциальные инструкции перехватываются при выполнении в пользовательском режиме, мы можем безопасно выполнять все нечувствительные инструкции непосредственно на базовом оборудовании.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
Не только, но и это тоже. Точней, то, что в мэйнфреймах IBM в плане защиты сразу всё сделали правильно (все команды, имеющие отношение к управлению машиной в целом, являются привилегированными), явилось технической базой для создания гипервизора без необходимости добавлять в машину какую-то специальную поддержку: как только прикрутили MMU для организации виртуальной памяти, сразу стала возможной виртуализация всей машины. Но полноценная виртуализация ввода-вывода была бы невозможна, если б ввод-вывод был организован так, как это имеет место у основной массы архитектур.
Могу предположить, что чудесные свойства архитектуры, описываемой в статье, следуют из того, что набор чувствительных инструкций является подмножеством привилегированных. А для x86 приходится либо использовать эмуляцию, либо паравиртуализацию, либо еще что-то.
Нет на МФ никаких "чувствительных инструкций" как подмножество привилегированных. Ваш Таненбаума пишит только про процессоры х86 и им подобные.
В моей статье и в сообшении SIISII сказано ясно есть набор инструкций МФ подмножеством которого являются инструкции супервизора или гипервизора не важно, выполнение которых возможно исключительно в состоянии супервизор.
Вместо множества Ring-ов, которые доступны всем ОС на х86 и что с ними делать не понятно (к счастью две основные системы используют только два ринга, а также используют только один метод виртуализации памятьи из нескольих возможных) на МФ ровно два набора инструкций и ровно один метод виртуализации.
Представьте что было бы с виртуализацией ОС х86 если бы она использовала все ринги и все методы виртуализации памяти. Это был бы конец всему. На МФ любые мыслемые ОС будут работать на виртуалке zVM.
Кем эта типизация была введена и зачем я не знаю
В Википедии ссылаются на тезисы Гольдберга 1973 года "Architectural Principles for Virtual Computer Systems", где он впервые ввел эту типизацию.
Собственно, Таненбаум тоже ссылается на Гольдберга 1974 года, когда пишет про чувствительные инструкции.
А архитектура x86 появилась в 1978 году только.
А виртуальные машины на МФ появились в середине 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 я в этом сам многократно убедился.
Вы перепутали статью на 39 страниц и тезисы на 249 с похожим названием. Это оттуда
На мой взгляд наоборот: на математике вся компьютерная наука держится. Например, теория типов. Она применяется, как для определения свойств безопасности языков, например тех же инструкций x86 или другого набора. Так и для упрощения отладки и много чего еще. Без строгих математических оснований ничего бы столь сложного, как машины и операционные системы, не существовало бы.
z/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-го типа.
Эта абстракция и называется в статье настоящей виртуальной машиной.
В общем, пожалуй, верно, хотя есть определённые нюансы, связанные с тем, что VM/370 и, надо полагать, z/VM (с современными мэйнфреймами я дела не имел, поэтому на 100% утверждать не могу) способна работать без какой-либо поддержки со стороны процессора, но при её наличии получает преимущества по скорости. Вот простой пример.
В изначальной Системе 360 было единственное средство отсчёта времени -- так называемый интервальный таймер. С точки зрения программиста, это было слово (4 байта) в памяти машины по адресу 50(16), значение которого постепенно уменьшалось, и когда становилось отрицательным, появлялся запрос на внешнее прерывание. В Системе 370 были введены другие средства отсчёта времени, а в более поздних версиях архитектуры интервальный таймер вообще выпилили.
Очевидно, что любой виртуальной машине, которая нуждается в интервальном таймере (а это любая машина, на которой предполагается запускать любую из "классических" ОС, рассчитанных на Систему 360, а зачастую и на Систему 370), нужно обеспечить, чтоб содержимое слова по её виртуальному адресу 50 изменялось аналогично железному интервальному таймеру. Гипервизор может реализовать это чисто программно: когда происходит физическое прерывание, он должен обновить соответствующие слова в памяти всех виртуальных машин. Понятно, что этот процесс занимает определённое время и не слишком эффективен. Поэтому довольно многие процессоры Системы 370 (например, наши ЕС-1035 и ЕС-1130, но наверняка и все остальные) имели специальную поддержку для гипервизора, упрощая эмуляцию интервального таймера для виртуальных машин (следили за обращением гостевой ОС к соответствующей ячейке, избавляя гипервизор от необходимости либо постоянно обновлять эту ячейку, либо вообще блокировать доступ ко всем нижним 4 Кбайтам виртуальной памяти, чтобы отлавливать обращения к таймеру).
Вот и возникает вопрос: к какой категории относится гипервизор, если он использует подобного рода поддержку, ежели обнаруживает её во время своей инициализации, но при этом сохраняет возможность работать без неё? (Например, та СВМ ЕС, что была в моём распоряжении, не могла использовать поддержку, имеющуюся в ЕС-1035: версии не совпадали; вот на ЕС-1130 она пользовалась всем, что там было).
Ну и, опять-таки, путаница с firmware: и в ЕС-1035, и в ЕС-1130 поддержка была в значительной степени на уровне микропрограммы -- т.е. firmware по-буржуйски, но это абсолютно не то же самое, что поддержка на уровне программы, зашитой в ПЗУ (типа BIOS на ПК) -- это часть процессора, неотличимая для программиста, включая создателя гипервизора, от "железных" функций аппаратуры.
z/VM, как операционная система, является гипервизором 2-го типа, software, и может работать standalone, без какой-либо поддержки виртуализации, будь-то hardware или firmware.
Когда z/VM запущена поверх PR/SM, т.е. с поддержкой виртуализации на уровне firmware, то она уже строго говоря не относится ко 2-му типу. Тут лучше говорить про 2-tier гипервизор.
Не важно о каком МФ идет речь, с PR/SM или без, речь идет об абсолютно одинаковых принципах работы и наборе инструкций/команд процессора, организации памяти и вводе-выводе. Именно на этом уровне разрабоатны все ОС МФ включая z/VM, хотя это и не ОС в дословном понимании.
Иными словами нет и не было никаких специальных поддержек виртуализации на МФ (пара исключений были давно и давно их нет). Это и не нужно. В принципах работы МФ есть все необходимое для виртуальных машин.И всем эти пользуется z/OS и даже больше чем z/VM. Это возможно потому что любая ВМ на МФ имеет доступ ко всем воможностям процессора и ввода, не все из которых используются z/VM (CP). Вот это и понимается в статье как "настояшая виртуальная машина".
Могу предположить, что в случае мейнфреймов, применяется общая, более узкая абстракция физической машины, которую можно переиспользовать для разных операционных систем и другого системного ПО, такого как гипервизоры 1-го типа.
Эта абстракция и называется в статье настоящей виртуальной машиной.
Предположение не верно. Читайте документ " Principles of Operation ": https://www.ibm.com/docs/en/SSQ2R2_15.0.0/com.ibm.tpf.toolkit.hlasm.doc/dz9zr006.pdf
Это описание МФ и "настоящей виртуальной машины". И не надо ничего предполагать. .
Не важно о каком МФ идет речь, с PR/SM или без, речь идет об абсолютно одинаковых принципах работы и наборе инструкций/команд процессора, организации памяти и вводе-выводе
Под этой удобной моделью скрывается реализация, в которой есть и абстрагирование, и виртуализация и все, что положено при общем подходе к конструированию систем. Я пытаюсь не мыслить в рамках модели, описываемой 1200+ страничным документом, а построить свою, достаточно простую.
Одинаковые наборы инструкций процессора в случае МФ возможны благодаря тому, что выполняется требование Гольдберга, приведу его еще раз:
Для любого обычного компьютера может быть создан монитор виртуальной машины, если набор чувствительных инструкций для этого компьютера является подмножеством набора привилегированных инструкций...
А для x86 есть 17 инструкций, для которых это требование нарушается.
Следствием является то, что в случае МФ возможно построение таких абстракций, накладные расходы на виртуализацию в которых практически не заметны, что дает возможность строить модель "настоящей виртуальной машины".
А в случае x86 потери настолько велики, что приходится довольствоваться лишь "виртуальной ... системой".
Могу предположить, что в случае z/VM одного функционала bare-metal hypervisor недостаточно, и требуется поддержка на уровне самой специализированной ОС z/VM (программного гипервизора в вашей терминологии), чтобы запускать тысячи гостевых машин на каком-то меньшем числе партиций LPAR мейнфрейма.
На самом деле запуск тысяч виртуалок на МФ под zVM в логических партициях не является ни панацеей не самым эффективным способом использования МФ.
Более эффективно есть и будет использование МФ под z/OS, который совмещает в себе и ОС и гипервизор виртуальных машин, правда это машины ОС MVS, ОС Unix или контейнеры с Линуксами.
Это более эффективно потому что в случае тысяч виртуалок мы можем оптимизировать только каждую виртуалки в отдельности, но не всю их совокупность. В то время как в z/OS мы имеем возможность оптимизировать всю совокупность работ под ней и даже всю совокупность логических партиций с ОС z/OS на МФ.
Здесь 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.
Именно, чтобы избегать подобных смысловых неточностей, и хотелось бы классифицировать программные компоненты.
Чтобы не было написано, хоть бы и в ИБМ доках, думать самостоятельно тоже надо.
К сожалению и ИБМ не идеален. Докуманты 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). Как Вам кажется есть в нем гипервизор или нет?
Думаю, было так: в самых первых мейнфреймах LPAR могли быть реализованы через рубильники и коммутацию, совершенно без виртуализации. Как только техника развилась настолько, чтобы этим уже не приходилось заниматься на уровне ручных переключателей, тот же функционал LPAR был реализован уже через виртуализацию, и остается таковым по сей день.
Термин virtual machine может иметь два смысла: как гостевая система для гипервизора, и как абстракция физической машины, реализуемая в операционной системе (по-другому она еще называется extended machine). Эта же абстракция может быть реализована на уровне PR/SM, рассматривая LPAR как виртуализированный отдельный компьютер.
Про VM/370 и VM/SP к сожалению не могу сказать, это не моя сфера, меня хватило только на z/VM.
z/OS может представляться одной из трех ОС: MVS, USS (Unix), and zCX (Linux). Как Вам кажется есть в нем гипервизор или нет?
Не исключаю, что на каком то этапе своего существования, в z/OS мог быть встроен гипервизор непосредственно. Но в текущей конфигурации я уверен, что функционал гипервизора вынесен в отдельный модуль, который называется z/VM. Это следует из описания практически во всех доступных источниках и из инженерных соображений по компоновке модулей системы.
Поскольку модули z/ системы интегрированы между собой в достаточной степени, ничто не мешает z/OS "представляться" другими ОС. находясь при этом в окружении гипервизора z/VM и делегируя ему функционал гипервизора.
Про гипервизоры 3-го уровня (3-tier) у IBM ничего не известно.
Не исключаю, что на каком то этапе своего существования, в z/OS мог быть встроен гипервизор непосредственно. Но в текущей конфигурации я уверен, что функционал гипервизора вынесен в отдельный модуль, который называется z/VM. Это следует из описания практически во всех доступных источниках и из инженерных соображений по компоновке модулей системы.
Поскольку модули z/ системы интегрированы между собой в достаточной степени, ничто не мешает z/OS "представляться" другими ОС. находясь при этом в окружении гипервизора z/VM и делегируя ему функционал гипервизора.
Для меня пока загадка как устроено "представление" z/OS другими системами. Возможно я подзабыл материал курсов про Unix System Services, которые я посещал довольно давно. Это можно исправить.
Но я очень сомневаюсь в достоверности Ваших предположениий о наличии гипервизора в составе z/OS, тем боле дословно z/VM.
В самом деле z/VM позволяет выполняться любым системам МФ на ее ВМ. z/OS с другой стороны реализует в себе совсем не МФ системы Unix и Linux. Полагаю для этого вовсе не требуется виртуализировать МФ ведь ни Unix ни Linux не писались для МФ как такового и следовательно иметь МФ им не требуется.
Скорее всего имиджи Unix и Linux выполняются в z/OS как обычные программы MVS в MVS адресных пространствах с использованием привычных для них API к их привычным ядрам на их привычных процессорах, которые! эмулируются расширением ядра MVS. Где-то так мне кажется должно быть.
Другими словами я исключаю наличия каких либо модулей z/VM в z/OS потому что системам, которые включает в себя z/OS машина МФ вовсе не нужна. Они про нее ничего не знают. Ведь написаны системы в основном на С, а язык С давно уже адаптирован на МФ в разных ОС МФ в том числе конечно же в z/OS.
Спасибо за повод к размышлению
Вам тоже спасибо за статью.
Могу сказать, что нативный Linux (под процессор IBM) запускается в z/OS посредством commercial Linux kernel provided by IBM that runs inside a virtual appliance on z/OS. А x86 Linux запустить иначе чем как посредством гипервизора, вероятнее всего нельзя.
Путём изменения микропрограммы можно поменять поведение процессора -- например, расширить или вообще кардинально изменить систему команд. И такое на мэйнфреймах реально использовалось, а может, и сейчас встречается (например, ещё System/360 model 85 умела "прикидываться" IBM-овскими машинами 2-го поколения -- 7090, вроде б, а наша ЕС-1035 могла выполнять программы от нашего же Минска-32, хотя архитектурно это абсолютно разные машины с совершенно разным набором команд).
Даже знаю имя разработчика - Котов Михаил Петрович.Увы, умершего.
Он был начальником отдела в НИИ ЭВМ занимавшегося СВМ ЕС (VM/370, VM/SP). Много с ним общался в командировках и на семинарах.
Что касаемо микропрограммирования и микрокодов, то подозреваю что в процессоре МФ даже не два, а более уровней микропрограммирования. Слышал давно про макрокод, который между микро и тем что уже представляет набор команд для программирования ОС и прикладных программ.
Ну, подробности устройства процов современных мэйнфреймов не раскрываются, поэтому можно только гадать. В тех, где хоть какая-то более-менее подробная информация о микроархитектуре имеется, -- более-менее обычные одноуровневые микрокоманды + схемная реализация некоторых простых, но важных вещей вроде выборки и декодирования команд.
Если я правильно понимаю, разработчик мейнфрейма IBM (я не имею ввиду прикладного разработчика под ОС z/VM) может заниматься как разработкой прошивки процессора (firmware), так и разработкой самой ОС z/VM. В силу того, что компания занимается и железом и софтом. Не знаю, как у процессоров мейнфрейма, но для разных устройств прошивка (например, firmware for IBM Power System) - это обычное ПО, которое также разрабатывается, легко меняется и обновляется.
Нет, конечно же firmware это самостоятельный вид деятельности и совмещать его с разработакой z/VM просто нецелесообразно. Кстати z/VM строго говоря не операционная система. Операционная система это система выполнения прикладных программ, это в общем случае система виртуальной машины. z/VM это гипервизор.
Но Вы правы что поскольку и железо и системное программное обеспечение в случае МФ это одна и та же фирма, то разработка обеих сторон ведется и велась согласованно. Т.е. в железе появлялись те и только те возможности что востребованы хотя бы одной ОС МФ. И это не zVM, а z/OS на самом деле. Только z/OS использует все возможности МФ.
"... firmware это самостоятельный вид деятельности и совмещать его с разработкой z/VM просто нецелесообразно."
Справедливости ради, был исторический этап с VM/SP и hardware assist. Но сейчас, IBM нет особого смысла вкладываться в производительность zVM, так как эра VSE под VM ушла, а 100500 Линукс под zVM не зашла, и zVM используется для разработки, отладки и тестирования zOS.
Справедливости ради, был исторический этап с 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. Тоже интересно и показательно.
"Да были времена когда отладка MVS под VM была важной сферой применения VM в IBM. Но вряд ли сейчас это так важно имея LPAR и средства отладки в самом z/OS."
Здесь Вы заблуждаетесь. Тестировщики имеют по несколько виртуальных машин (например, для сисплекса), разработчики - минимум по одной. И дело не только в средствах отладки в VM из коробки, если подумать и посчитать. LPAR используется при системном (нагрузочном) тестировании и тестах (проблем) производительности.
Вы работаете в этой сфере?
Я имел в виду средства отладки в z/OS (MVS). Не в VM, хотя в последнем тоже есть очень мощные срество отладки ОС ВМ.
Я имел в виду, что разбрасываться партициями дорого, а более одного разработчика/тестировщика в партиции проблемно.
По поводу отладки (коротко): встроенный в zOS на уровне языка, zVM на уровне ассемблера.
P.S. Дела давно минувших дней, Преданья старины глубокой. (©)
P.P.S. И, да, для внутреннего отладчика нужен исходный код и компилятор с опциями. При этом вы отлаживаете только свой кусок, который пересобрали. А если вы наводите ошибку в другой компоненте? Без средств отладки zVM поймать это будет (значительно) сложнее.
Безусловно переоценить роль 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 такой.
GTF - мимо, если компонента в него не пишет. SLIP - на стороне заказчика (дамп по программному прерыванию, etc.). zVM (у себя) - останов по адресу, прогр. прерыванию, етс., покомандное исполнение, етс.
"В z/OS каждую системную компоненту ...". 1) Не каждую. 2) А если у двух разработчиков общий модуль в LPA? 3) Туева куча других проблем ...
Простое решение этой дилемы похоже на решение дилемы курицы и яица. 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.
На ARM микрокода нет. И, более того, его наличие у мэйнфреймов или там IA-32/AMD64 -- не неизбежность, можно было бы всё сделать на жёсткой логике -- просто последнее было бы сильно сложней и дороже.
Нашел неплохое объяснение 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 она до сих пор актуальна.
Во-первых, мало ли что и как можно нарисовать. Я, например, убрал бы слой в зеленом цвете и написал в голубом: Processors, Memory, IO & PR/SM. Кстати то что на этом рисунке названо "Memory" в терминологии МФ называется "Storage". Вот Вам и цена таких источников. Не важно кто бы их рисовал пусть даже кто-то из ИБМ. Писателей нынче больше чес настоящих специалистов.
Во-вторых, Вы написали "Когда на ранних периодах своего существования, z/VM запускалась без PR/SM, являясь при этом операционной системой, она относилась ко 2-му типу. " (это опечатка?). Если нет то тогда почему и под PR/SM она категоризируется зачастую как тип 2?
Строго говоря z/VM (основная ее компонента - СР) не операционная система. Как таковая система виртуальных машин не запускает и не управляет программами. Это делают ОС на ВМ. Без ОС на ВМ Вы не запустите ни одной программы. Хотя именно на ВМ под СР можно написать програму, которая сама себя запустит и выполнится без какой либо ОС.
Но в состав z/VM входит, например, CMS - операционная система ВМ. А также GCS (Group Control System) это усеченная версия MVS. Это как бы разные вещи.
Кстати про CMS. Эта ОС не сможет работь на PR/SM.
Если нет то тогда почему и под PR/SM она категоризируется зачастую как тип 2?
Не опечатка. Дело в уровнях абстракции. Гипервизор 1-го типа абстрагирует оборудование и предоставляет виртуализированную машину гостевым системам. Гипервизор 2-го типа использует абстракцию оборудования, созданную операционной системой. Когда z/VM под PR/SM называют типом 2, руководствуются чисто формальным критерием, что z/VM это операционная система, запускающая гипервизор. А здесь операционная система пользуется абстракцией, предоставленной PR/SM, а не сама абстрагирует оборудование.
Строго говоря z/VM не операционная система.
Она не операционная система общего назначения, но она операционная система специального назначения, расширяющая функционал гипервизора. Одного PR/SM недостаточно, чтобы реализовывать все необходимые задачи. Поэтому требуется полноценная операционная система. В семействе z/ есть несколько операционных систем и чтобы не встраивать функционал расширенного гипервизора в каждую из них, в которой он требуется, он вынесен в отдельную операционную систему, которой другие делегируют эту задачу.
Глагол абстрагирует не подходит для описания процесса виртуализации.
«Абстрагировать» означает мысленно отвлечься от несущественных деталей, чтобы сосредоточиться на главном, выделив основные свойства и закономерности. Это процесс выделения существенного, отбрасывая всё второстепенное, что позволяет лучше понять суть предмета или явления.
Виртуализация наоборот имеет своей цкоью передать виртуальной машины все детали реальной машины и по возможности точнее.
ОС скорее всегоне поймет и упадет если ему давать абстрактную реальную машину. Примерно как если бы Вы заходели использовать вместо шестеренки в коробке перепач ее абстракцию, например нечто круглое в некими зубцами по окружности.
Вообще жонглирование абстрактными типами (я читал и про другие, чем Ваше, определения типов) не добавляет понимания виртуализации.
Если же говорить о конкретной z/VM то она устроена и работает абсолютно идентично как на машинах с PR/SM так и без этого. Из Вашего же объяснения складывается впечатление что это не так и что мы имеем две разных z/VM. Нет разных z/VM.
PR/SM решает задачу диспетчеризации (задачу планирования) логических CPU (виртуальных) по физическим. Физические процессоры имеют своё расположение на микросхеме, расстояния и соединения между чипами, значения объемов быстрых и медленных кешей и т.д. Если бы виртуальные процессоры не были бы абстракцией, а в точности отображали все детали устройства физических процессоров, то оптимизации были бы невозможны.
Грубо говоря, логические CPU имели бы даже те же номера, что и физические. И количество их совпадало бы 1:1. Т.е. пользы от такой виртуализации просто бы не было никакой. Как только мы скрываем какие-то детали устройства физических процессоров, становится возможным получать те или иные преимущества от абстракции. Например, иметь количество логических процессоров большее, чем физических.
Точно также работает абстракция на уровне z/VM, но там в силу вступают другие факторы и нужно скрывать другие детали.
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
Вам спасибо за очередную возможность пошевилить мозгами.
Кстати говоря, в современных мэйнфреймах появилась команда, позволяющая прикладному коду узнать содержимое PSW, в т.ч. состояние задача/супервизор -- что нарушает возможности виртуализации. Либо нынче в IBM сидят идиоты, либо "Принципы работы" описывают не всё -- а они точно описывают не всё (например, лишь упоминается безопасная память, которую контролирует "ультравизор"). Подозреваю, что в реальных машинах эта команда может выполняться в режиме пользователя или кидать прерывание в зависимости от режима процессора, не описываемого в "Принципах работы" (что-нибудь специально под виртуализацию, например).
Кстати говоря, в современных мэйнфреймах появилась команда, позволяющая прикладному коду узнать содержимое PSW, в т.ч. состояние задача/супервизор -- что нарушает возможности виртуализации. Либо нынче в IBM сидят идиоты,
Не надо торопиться обвинять.
Нарушением была бы возможность изменять состояние задача/супервизор. Это можно сделать только командой загрузить новое PSW. Это привилегированная команда.
либо "Принципы работы" описывают не всё -- а они точно описывают не всё (например, лишь упоминается безопасная память, которую контролирует "ультравизор").
А можно поподробнее или хотя бы термины на английском привести.
Подозреваю, что в реальных машинах эта команда может выполняться в режиме пользователя или кидать прерывание в зависимости от режима процессора, не описываемого в "Принципах работы" (что-нибудь специально под виртуализацию, например).
Что Вы хотели сказать сделав акцент на "реальных машинах"? Все команды на МФ выполняются на реальной машине. Исключений нет.
Если под "эта команда" понимается EPSW, то эта команда выполнится в обоих режимах как описано без прерываний.
Возможно эта команда для ОС ВМ чтобы без траты времени на прерывание и подключение z/VM (CP) выполнить в общем то безобидное действие. Получить то можно текущее PSW, т.е. то с каким PWS программа в данный момент выполняется.
Нарушением была бы возможность изменять состояние задача/супервизор. Это можно сделать только командой загрузить новое PSW. Это привилегированная команда.
Извините, но это -- бред. Интеловская архитектура оказалась непригодна для нормальной виртуализации без специальных расширений как раз из-за того, что коду режима пользователя были доступны команды, позволяющие получить состояние привилегированных сущностей, хотя изменить их они не могли: команды изменения были привилегированными, а вот команды чтения -- нет. Как следствие, сделать просто надёжную систему было возможно, начиная с 80286, а вот реализовать виртуализацию -- нет (даже если отбросить проблемы с вводом-выводом и говорить исключительно о процессоре). Здесь -- абсолютно то же самое, почему появление этой команды выглядит... странно.
А можно поподробнее или хотя бы термины на английском привести.
Ультравизор -- так и есть, ultravisor; для взаимодействия "обычной" системы с ним имеется некая ultravisor-call facility. Блоки памяти делятся на secure storage и non-secure storage; попытка обратиться к secure storage для любого кода, работающего в рамках обычной системы, вызывает прерывание по попытке доступа к безопасной памяти. Никаких других сведений "Принципы работы" не дают (как они не дают их о целом ряде других вещей).
Что Вы хотели сказать сделав акцент на "реальных машинах"? Все команды на МФ выполняются на реальной машине. Исключений нет.
Вы не поверите, но все команды на персоналках выполняются на реальной машине. И на телефонах тоже. И даже на Ардуине.
Я говорю про реально существующие машины, а не "сферические в вакууме". И я берусь утверждать, что реальные современные мэйнфреймы работают не так просто, как описано в "Принципах работы" -- есть весьма много вещей, подробности о которых не раскрываются, а в лучшем случае лишь упоминаются.
Возможно эта команда для ОС ВМ чтобы без траты времени на прерывание и подключение z/VM (CP) выполнить в общем то безобидное действие.
Это "безобидное действие" напрочь убивает возможность полной виртуализации. Например, классическая OS/360 временами проверяет состояние масок прерываний и в зависимости от их состояния выбирает ту или иную ветвь выполнения внутриядерного кода, и правильная её работа на виртуальной машине обеспечивается как раз тем, что просто так получить PSW рамках старых версий архитектуры невозможно, и гипервизор всегда подсунет "правильное" значение, а не то, которое в реальности установлено для гостевой ОС.
Поэтому я и написал, что либо в нынешней ИБМ сидят идиоты, либо что эта команда на самом деле может быть заблокирована, но информация об этом скрывается.
Извините, но это -- бред.
Это не бред это привелигированая команда LOAD PSW (LPSW), которой только и можно програмно изменить режим на супервизор.
Второй путь, не програмный, это аппаратная загрузка нового PSW из prefix area.
И давайте обойдемся без упоминания х86-64 в разговоре о МФ. Это только запутывает то с чем можно разобраться без этих упоминаний.
Ультравизор -- так и есть, ultravisor; для взаимодействия "обычной" системы с ним имеется некая ultravisor-call facility.
Google says:
The ultravisor-call facility is a special set of system calls (known as "ultracalls") used to request services from the Ultravisor, a highly privileged firmware layer that enables confidential computing on IBM zSystems and Power systems. The Ultravisor is a security feature, not a general mainframe facility for standard operations.
"Принципы Работы" не описывают firmware.
On IBM zSystems, the Ultravisor is a key component of the IBM Secure Execution for Linux feature, introduced with IBM z15 and LinuxONE III. It provides a robust, hardware-enforced isolation for confidential workloads, ensuring the confidentiality and integrity of data in use, at rest, and in flight. Ultracalls are the defined API for secure interaction within this environment.
IBM® Secure Execution for Linux® is a z/Architecture® security technology that is introduced with IBM z15® and LinuxONE III.
It protects data of workloads that run in a KVM guest from being inspected or modified by the server environment. For more information, see Introducing IBM Secure Execution for Linux, SC34-7721.
The IBM Secure Execution for Linux feature must be enabled on your IBM Z® or IBM LinuxONE hardware (see IBM Dynamic Partition Manager (DPM) Guide, SB10-7170).
https://www.ibm.com/docs/en/linux-on-systems?topic=concepts-secure-execution
Все есть и описано. Не надо наводить тень на плетень. Не красиво и обидно слышать от Вас. Вы выглядили компетентным специалистом по МФ.
Это не бред это привелигированая команда LOAD PSW (LPSW)
Бред -- не команда LPSW, а Ваше утверждение в ответ моё утверждение:
================
Кстати говоря, в современных мэйнфреймах появилась команда, позволяющая прикладному коду узнать содержимое PSW, в т.ч. состояние задача/супервизор -- что нарушает возможности виртуализации. Либо нынче в IBM сидят идиоты,
Не надо торопиться обвинять.
Нарушением была бы возможность изменять состояние задача/супервизор. Это можно сделать только командой загрузить новое PSW. Это привилегированная команда.
=================
Ещё раз повторяю: нарушением является факт возможности получения привилегированной информации непривилегированным кодом. Вы, похоже, этого не понимаете, иначе не было бы ни вышеприведённого Вашего утверждения, ни вот этого:
И давайте обойдемся без упоминания х86-64 в разговоре о МФ.
Ещё раз повторяю: проблема интеловской архитектуры -- в существовании команд, которые позволяют прикладному коду читать системные сущности (адреса таблиц описателей, например). Любые команды, подобные мэйнфреймовской LPSW, на 80286 и последующих процессорах являются привилегированными. И появление EPSW точно так же разрушает возможность виртуализации в мэйнфреймах.
Все есть и описано. Не надо наводить тень на плетень.
В "Принципах работы" -- не описано. Я не утверждал, что это вообще нигде не описано, я утверждал, что не описано в "Принципах работы", и что реальные мэйнфреймы работают сложней, чем там указано.
Не красиво и обидно слышать от Вас. Вы выглядили компетентным специалистом по МФ.
Ну так разберитесь с тем, в чём реальная причина невозможности виртуализации на интеловской архитектуре, а не просто отмахивайтесь от неё, -- тогда и не будете писать бред и слышать в ответ обидное. Я, извините, политкорректностью не страдаю и если вижу бред, то так и говорю.
А специалистом я ни разу не являюсь, я последний раз программировал для мэйнфрейма в 1993 или 94 году (на советской ЕС-1130), а в последний раз обслуживал её как электронщик или системщик -- году эдак в 98-м. Ничего современнее Системы 370 в виде советских машин я в моей реальной жизни даже не видел.
Бред -- не команда LPSW, а Ваше утверждение в ответ моё утверждение: ... -- что нарушает возможности виртуализации.
Ок. Объясните как эта команда, EPSW, нарушает "возможности виртуализации"?
А вот что-то, но не ответ:
Ещё раз повторяю: нарушением является факт возможности получения привилегированной информации непривилегированным кодом.
Какая такая приилегированная информация имеется в PSW программы? Формат PSW надеюсь Вам известен и Вы можете указать на байты и биты с "привелигерованной информациеЙ" и связать это с "нарушением возможности виртуализации". Прошу.
В "Принципах работы" -- не описано. Я не утверждал, что это вообще нигде не описано, я утверждал, что не описано в "Принципах работы", и что реальные мэйнфреймы работают сложней, чем там указано.
Не все должно быть и на самом деле указано в "Принципах работы", Многое содержится в других источниках и они есть доступны и дают полное представление о МФ и ОС МФ. Полное и исчерпывающее. За 40+ лет работы с МФ и ОС МФ мне (на моем уровне) никгода не прходилось испытывать информационный голод.
В дополнении к документации я использовал так доступ к ИБМ саппорту и конференции, на которых делали доклады более сведущие люди и им можно было задавать вопросы и получать ответы.
Мне даже удалось пару-тройку предложений в дизайн DB2 провести много лет назад.
Ну так разберитесь с тем, в чём реальная причина невозможности виртуализации на интеловской архитектуре,
Я с интеловской платформой работаю по минимальному принципу. Т.е. желания что-то творить на ней не испытываю. Вирттуализацию на интел платформе вообще не признаю за виртуализацию машины, только систем и то лишь некоторых.
тогда и не будете писать бред и слышать в ответ обидное.
Укажи на мой бред в моих статьях.
А специалистом я ни разу не являюсь, я последний раз программировал для мэйнфрейма в 1993 или 94 году (на советской ЕС-1130), а в последний раз обслуживал её как электронщик или системщик -- году эдак в 98-м. Ничего современнее Системы 370 в виде советских машин я в моей реальной жизни даже не видел.
В виртуальных машинах не так уж и много появилось с тех пор. А вот MVS, ставший OS/390 и наконец z/OS, бурно развивался и развивается, как впрочем и сам МФ.
Я тоже примерно в тоже время на тех же ЕС ЭВМ работал до 1995 года. Потом перерыв на персоналки и возврат на МФ в 2000 году, но уже в Канаде.
На ЕС ЭВМ я поработал практически на всех, кроме ЕС 1130. Возможно видел, на работать не довелось. Недавно читал ято все закончилось на стадии проета ЕС 1230 "Ряд-5".
Нам,с Вами, по идее, не о чем должно бы быть спорить. Но вишь как получается.
Ок. Объясните как эта команда, EPSW, нарушает "возможности виртуализации"?
А вот что-то, но не ответ:
Ещё раз повторяю: нарушением является факт возможности получения привилегированной информации непривилегированным кодом.
Какая такая приилегированная информация имеется в PSW программы? Формат PSW надеюсь Вам известен и Вы можете указать на байты и биты с "привелигерованной информациеЙ" и связать это с "нарушением возможности виртуализации". Прошу.
===========================
Конкретно по битам для 128-разрядного PSW: биты 0:17 и 24 (не считая разрядов, которые пока что не используются и равны нулю), содержат привилегированную информацию, которую от выполняемой программы необходимо скрывать, чтобы обеспечить полноценную виртуализацию. Непривилегированной информацией являются код условия (18:19), маска программы (20:23) и адрес команды (64:127). И именно привилегированную информацию EPSW возвращает программе (биты PSW[0:11,13:31]) -- т.е. делает ровно то же самое, что делают весьма многочисленные команды 80286 и 80386, из-за которых позже Интелу пришлось приделывать костыль для виртуализации.
Код, выполняющий подобные команды при работе на реальной машине, получит корректную информацию о состоянии процессора -- в частности, о том, работает ли он как код пользователя или супервизора и каково состояние масок прерываний и т.п. На основе этой информации он принимает решение, что делать дальше (например, системная по своей сути программа, если обнаружит, что была вызвана кодом пользователя и поэтому работает в режиме пользователя, может запросить у ядра переход в режим супервизора, если это ей для чего-то необходимо; или ей нужно переключить режим переадресации; или ей нужно сменить ключ доступа к памяти; или ей нужно понять, разрешены или запрещены прерывания или PER). При выполнении же на виртуальной машине эта же команда вернёт логически неверную информацию -- а именно ту, которая отражает состояние реального процессора, а не виртуального (и эта же самая гипотетическая программа увидит, например. что она работает в режиме пользователя с ненулевым ключом, хотя логически она должна выполняться в режиме супервизора с нулевым ключом -- просто PSW будет считан реальный, а не виртуальный).
Ещё раз повторяю: это абсолютно та же самая ошибка, что была допущена архитекторами Интел. Если для Вас это не очевидно, я тут бессилен.
Попробую дополнить, исходя из своего понимания, не претендующего на какой-то высокий профессионализм. Сначала цитата:
...каждая из этих инструкций может быть выполнена в пользовательском режиме, не вызывая ловушку для операционной системы, но влияет на то, как операционная система (гостевая) управляет своими ресурсами...Чтобы обойти проблему эмуляции всех подряд инструкций, снижающую производительность, подход, реализованный в виртуальной машине VMWare [Sugerman et al., 2001], состоит в том, чтобы сканировать исполняемый файл и вставлять код в непривилегированные конфиденциальные инструкции, чтобы перенаправить управление на монитор виртуальной машины. Там будет происходить соответствующая эмуляция,
например с учетом контекста, в котором должна была выполняться инструкция. В результате может произойти полная виртуализация, а это означает, что выполнение может происходить без изменения гостевой операционной системы или самого приложения.
Т.е. само по себе появление такой инструкции, как описываемая EPSW, не катастрофа. Поскольку разработчикам z/ системы достаточно применить компенсацию с помощью подхода, подобного описываемому выше или какого-то иного. Поскольку они полностью контролируют происходящее в их гипервизорах, то добавление такого обхода лишь в какой-то мере ухудшит производительность, сохранив при этом корректность виртуализации.
Это все лишь мои предположения относительно того, что на самом деле происходит в реализации системы, а не в её модели, описываемой "Принципами работы". Если компенсация реализована, то все инварианты сохранены и "Принципы работы" остаются справедливыми.
На самом деле, этот подход, хотя и более-менее работает на практике, в теории не даёт 100% виртуализации: например, программа может "на лету" модифицировать свой собственный код (это, например, делали первичные обработчики прерываний ввода-вывода и внешних прерываний в классической OS/360). Очевидно, что гипервизор не заметит подобной модификации, поскольку технически это обычная запись в память. (Да, я знаю, что можно запретить запись в страницы памяти, занимаемые кодом, -- но кто сказал, что это не будут страницы с данными? В упомянутой OS/360 всё это происходит в самой первой странице размером 4 Кбайта, где лежат и начала обработчиков прерываний, и куча системной информации, которая должна быть доступна и на чтение, и на запись). Или, например, нечто было формально загружено как данные, а потом исполняется как программа (тоже реальные случаи из OS/360). В общем, этот подход в общем случае не работает, и единственной гарантированной возможностью "виртуализировать" условный 80386 на нём самом является интерпретация всего кода вообще -- даже непривилегированного, ведь в непривилегированном режиме потенциально могут работать части ОС, готовящие информацию для привилегированного режима (скажем, в истинно микроядерной системе). Собственно, это подход более-менее работает как раз потому, что он применяется лишь к узкому кругу "стандартных" ОС с хорошо известным поведением, в то время как классическая VM/370 на классических мэйнфреймах сможет успешно работать с любой ОС или системно-независимой программой.
Ну а если подобные команды являются строго привилегированными, никаких проблем не возникает: они гарантированно "попадут в лапы" гипервизору. Да и производительность, по итогу, окажется ещё и больше: в любом случае надо переключаться из непривилегированного в привилегированный режим, но хоть не надо анализировать код программы.
В общем, как по мне, это как раз полнейшая катастрофа в плане виртуализации -- если только разработчики не предусмотрели "отключение" этой команды каким-то подпольным образом. Такое вполне может быть предусмотрено, но я отнюдь не исключаю, что они либо действительно идиоты (в конце концов, идиотскую архитектуру IBM PC и его BIOS с целой кучей нелепостей именно в IBM придумали), либо просто решили забить на виртуализацию.
В общем, как по мне, это как раз полнейшая катастрофа в плане виртуализации -- если только разработчики не предусмотрели "отключение" этой команды каким-то подпольным образом. Такое вполне может быть предусмотрено ...
Никакого такого отключения нет и не нужно. Я могу написать вопрос непосредственно в ИБМ по этому поводу, у меня есть доступ к их саппорту, но не вмжу никакого смысла. И не хочу их смешить.
, но я отнюдь не исключаю, что они либо действительно идиоты (в конце концов, идиотскую архитектуру IBM PC и его BIOS с целой кучей нелепостей именно в IBM придумали), либо просто решили забить на виртуализацию.
Идиотская архитектура IBM PC была следствием выборапроцессора Интел. Ни про какую виртуализацию тогда еще и лапоть не звенел. А потом все вышло из-под контроля ИБМ. Благодаря Биллу, блин, Гейтсу. В итоге имеел то что имеем.
Ну и если Вы думаете что в ИБМ одни и те же люди занимались/занимаются и мэйнфрэйм и писюками, то Вы сильно ошибаетесь.
Поскольку разработчикам z/ системы достаточно применить компенсацию с помощью подхода, подобного описываемому выше или какого-то иного. Поскольку они полностью контролируют происходящее в их гипервизорах, то добавление такого обхода лишь в какой-то мере ухудшит производительность, сохранив при этом корректность виртуализации.
Никакого такого "подхода" на самом деле не требуется и его нет на самом деле. Нет никаких сканирований выполняемого кода ВМ перед его выполнением и накаких замен ничего. И потерь производительности нет.
Есть только необяснимое непонимание SIISII полной безобидности команды EPSW, которая используется только в дебагерах.
Код, выполняющий подобные команды при работе на реальной машине, получит корректную информацию о состоянии процессора -- в частности, о том, работает ли он как код пользователя или супервизора
Если команда EPSW выполняется в режиме задача то бит 15 PSW будет всегда равен "1" - задача, если в режиме супервизор то "0".
Вы никак не хотите понять что получение значения PSW это получение значения PSW той программы котоая выдает команду EPSW, а не кокой-то другой программв или системы.
Для прикладной программы в PSW нет ничего интересного и отличаются PSW одной программы от длюбой другой только адресной частью, которую прикладные программы получаю командой LA Load Address/
Ну и наконец вот что говорит Гугле по поводу этой команды:
The command "EPSW" is a specialized command used within certain debugging and system management environments, primarily in mainframe systems like IBM z/OS with tools such as z/XDC. Its purpose is to display and interpret the contents of the Program Status Word (PSW) at the time an error or exception occurred.
и каково состояние масок прерываний и т.п.
В состоянии задача все прервания открыты всегда и это не секрет.
(например, системная по своей сути программа, если обнаружит, что была вызвана кодом пользователя и поэтому работает в режиме пользователя,
А вот это очень глубогое заблуждение. Никогда код пользователя не вызывает, и не может вызвать, системную. Вы это должны бы знать. Да еще так что системная программа начнет выполняться в режиме пользователя.
Ещё раз повторяю: это абсолютно та же самая ошибка, что была допущена архитекторами Интел. Если для Вас это не очевидно, я тут бессилен.
Нет, это не ошибка.
А Вы знаете что в архитектуре s/370 этой команды не было? Зачем было ее вводить если по-Вашему она вредит?
Да на ВМ, когда ОС ВМ выполняется в состоянии супервизора полученный PSW будет отражать курьезную информацию.
Как было показано выше смысл этой команды один: дать дебагеру источник информации для его отчета. Больше нигде этой команде никакого смысла нет. Системные программы (ядро) знают все про PSW без EPSW, а команда LPSW используется для переключения из состояния супервизор в задачу, т.е. для диспетчирования ВМ или прикладной програмы.
Без capping (бокс "Initial capping" не выбран) это также означает что если остальные партиции не выполняют ничего то 100% времени будет предоставленно этой партиции. Это все делается PR/SM.
Да, это хорошая демонстрация того, что я имею ввиду. Конфигурируемой партиции могут быть предоставлены как dedicated processors (выделенные физические CPU), так и виртуальные CPU, задаваемые, например, с помощью Absolute Capping -> Number of processors.
Системе, занимающей партицию, приходится пользоваться теми абстракциями, которые ей предоставили. Ей дали, например, либо один полноценный физический CPU, либо какую-то долю физического CPU, моделируемую логическими (виртуальными) CPU. И в некоторых ситуациях (например, связанных с высокопроизводительными вычислениями) это существенное отличие: одно дело владеть CPU монопольно, другое дело - иметь под капотом диспетчеризацию логических CPU.
Когда я говорю про сокрытие информации при абстрагировании оборудования для следующего уровня, я подразумеваю именно подобные ограничения. Вам приводили пример с сетевой картой и вы сослались на переписывание канальной программы https://habr.com/ru/articles/962262/comments/#comment_29051240 Это тоже 2 большие разницы: иметь монопольный полный доступ к устройству и иметь некоторую абстракцию (виртуальное устройство), реализуемую нижележащим уровнем, пусть хоть бы и с помощью канальной программы.
Сокрытие конфиденциальной информации при виртуализации отдельных инструкций CPU имеет похожие последствия с той разницей, что в отличии от случая физических/логических CPU, где допустимы оба варианта (гостю можно предоставлять как полный физический CPU, так и логические CPU с диспетчеризацией), скрывать некоторую информацию, касающуюся выполнения инструкций, от гостевой системы обязательно. Иначе может произойти утечка абстракции и нарушение безопасности. Мы с @SIISIIпытаемся донести эту мысль, но сталкиваемся с непониманием.
Точно не так. Ничего на МФ от ОС партиций не скрывается. Более того ОС партиций имеет доступ к "железу" через Base Control Program internal interface (BCPii)
Я понимаю, что Вы имеете ввиду. Для ОС партицией обязательно гарантировать, что вычислительный процесс при использовании виртуализации оборудования должен быть эквивалентен вычислительному процессу на чистом железе bare-metal. На этом все держится, иначе какой смысл. Но побочные эффекты, все же, возможны.
Начиная от потерь производительности из-за диспетчеризации и заканчивая возможным раскрытием абстракции при чтении того, что знать не положено.
Напоследок приведу гипотетический пример, демонстрирующий намеренно неудачное стечение обстоятельств. Пусть z/VM работает поверх PR/SM, причем на логических CPU с диспетчеризацией от PR/SM. И пусть она также задействовала свою HiperDispatch для того, чтобы предоставлять своим гостевым системам свою абстракцию CPU.
Как известно, при виртуализации есть 2 типа инструкций CPU, 1 - те, которые можно запускать сразу на физическом оборудовании, минуя все уровни абстракции, и 2 - которые обязательно пропускать через монитор (virtual machine monitor) или, по другому, гипервизор.
Так вот, в этих гостевых системах на z/VM запускается следующий синтетический тест. Вся нагрузка, которую они генерируют (причем по максимуму, выжимая все из оборудования), состоит преимущественно из операцией 2-го типа. Что будет происходить? Сначала они все с необходимостью будут попадать в монитор z/VM, а затем, точно также, в монитор PR/SM. Появятся 2 таких бутылочных горлышка производительности и, ко всему прочему, эти же инструкции будут 2 раза маршрутизироваться по логическим CPU, сначала в z/VM, а потом в PR/SM.
Как Вы думаете, удастся ли такому вычислительному процессу делать вид, что он выполняется на чистом железе?
так и виртуальные CPU, задаваемые, например, с помощью Absolute Capping -> Number of processors.
Это не верно потому что capping это не про виртуальные процессоры, а про ограничения использования реальных процессоров.
Я с capping никогда не работал, считаю его не обоснованным в любых сценариях, но ИБМ виднее.
Системе, занимающей партицию, приходится пользоваться теми абстракциями, которые ей предоставили. Ей дали, например, либо один полноценный физический CPU, либо какую-то долю физического CPU, моделируемую логическими (виртуальными) CPU. И в некоторых ситуациях (например, связанных с высокопроизводительными вычислениями) это существенное отличие: одно дело владеть CPU монопольно, другое дело - иметь под капотом диспетчеризацию логических CPU.
Никаких абстракций нет на самом деле. Партиция имеет дело всегда, в каждый момент времени когда PR/SM ей дает CPU, с реальным/физическим CPU.
Доля физического CPU это не пространственная доля, а временная. Это время доступа к физическому/реальному CPU. Я в курсе что на х86-64 есть немало спекуляций на эту тему, но на МФ все по честному. Поэтому это и работает хорошо, а не через пень-колоду.
Еще раз иметь "логические" CPU это не более чем фокус.
Высокопроизводительные вычисления это не сфера применения ИБМ МФ. ИБМ МФ это компьютер общего, без извращений, применения. Для самых общих приложений нужных реальной жизни, экономики, финансам, кправлении и многому другому, но не то чем занимается Гугл, или Фэйсбук или ... хотелось написать ИИ, но МФ и в ИИ алаптированы начиная с z16, и продолжением в z17. Это коммерция. ИБМ частная, коммерческая компания. ей нужны деньги.
Но побочные эффекты, все же, возможны.
Никаких побочных эффектов нет.
Начиная от потерь производительности из-за диспетчеризации
Диспетчеризация иммет место быть в любой системе разделения времени и ресурсов. Поэтому я и пишу в статьях что двойная диспетчеризация ВМ в гипервизоре и прикладных программ в ОС ВМ это плохо. И это не единственное плохо, есть и другие.
Напоследок приведу гипотетический пример, демонстрирующий намеренно неудачное стечение обстоятельств. Пусть z/VM работает поверх PR/SM, причем на логических CPU с диспетчеризацией от PR/SM. И пусть она также задействовала свою HiperDispatch для того, чтобы предоставлять своим гостевым системам свою абстракцию CPU.
Диспетчеризация на физические CPU и HiperDispatch это совершенно не связанные вещи. Смотрим дальше.
Так вот, в этих гостевых системах на z/VM запускается следующий синтетический тест. Вся нагрузка, которую они генерируют (причем по максимуму, выжимая все из оборудования), состоит преимущественно из операцией 2-го типа.
Тест конечно можно создать любой, но в реальной жизни задачи для МФ, неважно в ВМ или без (а скорее всего без - zVM это на МФ нынче экзотика в отличии от х86-64, где как я понимаю из реакции коллег на мои статьи, без виртуализации и жизнь не та) как правило основной объем кода это, согласно Вашей типизации, типа 1, который просто выполняется на физических CPU без каких либо абстракций.
А если взять системы написанные специально для ВИ под z/VM, то там "оперций 2 типа" минимум и это команда CPU МФ DIAGNOSE, команда, используемая для вызова гипервизора z/VM. Дальше.
Что будет происходить? Сначала они все с необходимостью будут попадать в монитор z/VM, а затем, точно также, в монитор PR/SM.
Нет, не в монитор PR/SM. Его подключения к процессам ВМ весьма и весьма эпизодичны. Они сводятся к остановке одних машин и передачи CPU другим машинам. Все происходит в мониторе z/VM делается в состоянии супервизор, т.е. все команды и привилегированые и проблемные выполняются без прерваний. Иными словами монитору z/VM не нe нужен PR/SM чтоюы обслуживать нужды ВМ.
Появятся 2 таких бутылочных горлышка производительности и, ко всему прочему, эти же инструкции будут 2 раза маршрутизироваться по логическим CPU, сначала в z/VM, а потом в PR/SM.
Нет не появится. Я объяснил почему.
Как Вы думаете, удастся ли такому вычислительному процессу делать вид, что он выполняется на чистом железе?
Даже если мы создадим тест из одних только команд 2-го типа (что уже не реально, команды этого типа называются в "Принципах Работы" управляющими командами (Control Commands), т.е. надо будет придумать программу состоящую из одних лишь управляющих команд. Привидите пример такой программы.) , то даже тогда все это будет выполняться на "чистом железе". PR/SM в этом не участвует, это дело монитора z/VM.
Хорошо, что Вы сказали об эпизодичной роли гипервизора PR/SM. Тогда мы можем признать, что на платформе x86 можно аналогично использовать низкоуровневый гипервизор только для разовой привязки систем к железу и для последующих миграций. И накладные расходы, связанные с виртуализацией x86, будут также разовыми, а не постоянными. Или этому мешает "ненастоящность" виртуализации x86?
Таким образом, остается сравнивать программные гипервизоры z/VM и их аналоги на x86. Об этом я уже неоднократно упоминал, не хочется повторяться. Преимущество платформы IBM по сравнению с x86 в эффективности. Но структурно эти 2 вида виртуализации эквивалентны между собой также, как вычислительный процесс на виртуальном оборудовании эквивалентен вычислительному процессу на физическом.
Какие-то абстракции, которые можно реализовать на МФ, невыгодны и практически невозможны на x86. И вместо них применяются другие, которые лучше соответствуют ограничениям. Но в обоих случаях применяются общие подходы. Основанные на теории процессов, если хотите.
Привидите пример такой программы.) , то даже тогда все это будет выполняться на "чистом железе". PR/SM в этом не участвует, это дело монитора z/VM.
Повторю мысль, что "Вы не поверите, но в x86 тоже все в конечном итоге выполняется на чистом железе". Дело в том, какими путями оно добирается до железа, какие при этом расходы и от чего приходиться отказаться. Пример очень простой: подбираются соответствующие инструкции 2 типа и в пару к ним инструкции, отменяющие предыдущую, чтобы соблюдалась идемпотентность.
И все это гоняется в параллельных циклах, насыщая по максимуму пропускную способность программного гипервизора.
..... на платформе x86 можно аналогично использовать низкоуровневый гипервизор только для разовой привязки систем к железу и для последующих миграций. И накладные расходы, связанные с виртуализацией x86, будут также разовыми, а не постоянными. Или этому мешает "ненастоящность" виртуализации x86?
Насколько я знаю в платформе х86-64 с началом движения за виртуализацию были сделаны изменения в архитектуру с целью поддержки виртулизации на более высоком уровне чем "постоянное" вмешательство в работу ОС ВМ.
"Накладные расходы" происходят не только от виртуализации CPU. Ввод-вывод на х86 тоже их источник.
Но вот партиционинга на платформе х86 так и нет.
Какие-то абстракции, которые можно реализовать на МФ, невыгодны и практически невозможны на x86. И вместо них применяются другие, которые лучше соответствуют ограничениям. Но в обоих случаях применяются общие подходы. Основанные на теории процессов, если хотите.
Если Вы мне, то я бы хотел больше технических обоснований и примеров в Ваших глубокомысленных высказываниях услышать. Спасибо.
Повторю мысль, что "Вы не поверите, но в x86 тоже все в конечном итоге выполняется на чистом железе".
Уквжите где я утверждал что в х86 "все" (что "всё"?) не "выполняется на чистом железе".
Пример очень простой: подбираются соответствующие инструкции 2 типа и в пару к ним инструкции, отменяющие предыдущую, чтобы соблюдалась идемпотентность.И все это гоняется в параллельных циклах, насыщая по максимуму пропускную способность программного гипервизора.
Это не пример про который я спрашивал. То что Вы даете это повторение того же самого на что я уже дал комментарий. Вы это мой комментарий чократили и делаете вид что привели "пример". Вот весь мой комментарий:
"Даже если мы создадим тест из одних только команд 2-го типа (что уже не реально, команды этого типа называются в "Принципах Работы" управляющими командами (Control Commands), т.е. надо будет придумать программу состоящую из одних лишь управляющих команд. Привидите пример такой программы.) , то даже тогда все это будет выполняться на "чистом железе". PR/SM в этом не участвует, это дело монитора z/VM."
Вы взяли в качестве цитаты для повторения своих фантазий только то что я подчеркнул, исказив полностью смысл моего абзаца.
Что будем делать?
Но вот партиционинга на платформе х86 так и нет.
Нет, но вместо него есть вполне приемлемая альтернатива. Вот, из похожего обсуждения
as long as the hypervisor is competently configured, respecting memory and IO adjacency (NUMA, AMP) and pinning threads to cores to eliminate sched overhead, as well as taking advantage of UEFI features like PCIe passthrough, performance of current hypervisors are easily 99+%
Уквжите где я утверждал что в х86 "все" (что "всё"?) не "выполняется на чистом железе".
Так эта мысль во всей Вашей статье. Вы зачем-то вводите лишние сущности "настоящая виртуальная машина" и "виртуальная система" (в случае x86). Когда я пытаюсь с помощью сравнений для обоих случаев проследить всю иерархию уровней абстракции вплоть до железа, чтобы таки понять, что именно Вы имеете ввиду, словно бы наталкиваюсь на стену, будто мы с Вами находимся в разных партициях.
Насколько я понял, в мейнфрейме функции гипервизора PR/SM относительно бесшовно (именно за счет преимуществ архитектуры IBM по сравнению с x86 такая бесшовность возможна) интегрированы с функциями конфигуратора оборудования (аналога переключения рубильников и кабелей). И тут, действительно, легко запутаться и перестать понимать, где кончается виртуализация и начинается изоляция железа исключительно с помощью конфигурации.
Чудесно, когда можно полностью избавиться от слоя виртуализации, организуя все только с помощью партиционинга. Но вот проблема: живая миграция, например, в этом случае будет невозможна.
Что будем делать?
Вернемся к основам. Попытаемся понять, что именно можно считать подлинной виртуализацией, а что - таковой не является. И нужна ли она вообще?
Чудесно, когда можно полностью избавиться от слоя виртуализации, организуя все только с помощью партиционинга. Но вот проблема: живая миграция, например, в этом случае будет невозможна.
Если изоляция -- не с помощью ручного перетыкания кабелей и перещёлкивания переключателей, то возможна, если я правильно понимаю, что такое "живая миграция".
что именно можно считать подлинной виртуализацией, а что - таковой не является
Как по мне, подлинная виртуализация -- это когда программа независимо от того, что она делает, всегда получает одни и те же результаты что при работе на реальной физической машине, что при работе на виртуальной машине. Естественно, при соблюдении двух очевидных условий: 1) результаты не зависят от конкретного времени выполнения, 2) программа не выходит за рамки оговорённого архитектурой -- например, не использует команды, результаты выполнения которых зависят от конкретной модели -- будь то команда ДИАГНОСТИКА на мэйнфреймах или функции и содержимое моделезависимых регистров на IA-32/AMD64.
И нужна ли она вообще?
Полезна, но не необходима. Скажем, на ПК в общем случае невозможно написать и отладить драйвер какой-то железки, используя ВМ, поскольку виртуализация периферии очень плоха, ну а на классической VM/370 такое делалось без проблем.
Моя супер-пупер-мега-ОС, которую я начал лепить на железной ЕС-1035, потом делалась в рамках СВМ ЕС, в девичестве VM/370, на ЕС-1130; на реальной ЕС-1130 я её запускать не мог, поскольку в качестве единственного консольного терминала я использовал пишущую машинку, а у ЕС-1130 её уже не было; поддержку дисплеев я реализовать банально не успел -- хотя наверняка сделал бы, если б продолжал работать на прежнем месте. Так вот, виртуальную память, а отчасти и работу с дисками я доводил до ума уже под СВМ, и это было намного удобнее: работая на ЕС-1035 без СВМ (она не сразу в моём распоряжении появилась), я для трансляции исходников был вынужден загружать ОС ЕС (OS/360), а после трансляции, сборки и записи результата на магнитную ленту -- загружаться с неё и тестировать полученное, что, естественно, сильно тормозило процесс. Под СВМ мне для этого достаточно было переместить свою пятую точку между двумя соседними мониторами, каждый из которых был консолью двух разных виртуальных машин -- на одной работала ОС ЕС, на второй -- моя меганедосистема. Плюс, отладка с помощью СВМ удобней, чем с железного пульта управления машиной (даже в сочетании с пишмашкой, которая в пультовом режиме могла распечатывать память или позволять её изменять, ну и всё такое прочее).
Если изоляция -- не с помощью ручного перетыкания кабелей и перещёлкивания переключателей, то возможна, если я правильно понимаю, что такое "живая миграция".
Здесь в самом термине live migration уже подразумеваются именно операция с виртуальной машиной. А я имел ввиду, если, например, в LPAR1 работает ОС, можно ли её перенести в LPAR2, оставляя её на период переноса работающей со всеми процессами, и при этом не задействуя никакой виртуализации PR/SM, только конфигуратор оборудования.
Как я догадываюсь, ответ здесь да, и операция переноса заключается в подключении новых (из LPAR2) процессора, памяти и т.д. и освобождении старых, чтобы полностью отключить LPAR1.
Но тогда, похоже, виртуализация - это неотъемлимое свойство самой такой ОС, раз она позволяет подобные вещи.
Тогда можно переформулировать вопрос: если в LPAR1 будет работать другая ОС, которая сама не поддерживает такую миграцию, можно ли её перенести в LPAR2, не задействуя возможности виртуализации PR/SM?
А я имел ввиду, если, например, в LPAR1 работает ОС, можно ли её перенести в LPAR2, оставляя её на период переноса работающей со всеми процессами, и при этом не задействуя никакой виртуализации PR/SM, только конфигуратор оборудования.
Перенос из одного LPAR в другой LPAR на одном и том же МФ не имеет никакого смысла. .
Выделенное выше может иметь смысл в такой редакции: мы имеем два LPAR с z/OS, работающих как одyна система в ParallelSysplex. И нам надо сделать апгрейд этих систем без остановки процессов.
Это делается в следущей последовательности:
Одна из систем выводится из Sysplex и становится автономной. Вся работа при этом переносит ся на вторую систему без остановки и Sysplex получается MonoPlex.
Делается апгрейд первой системы и система возвращается в Sysplex.
Повторяем шаги 1 и 2 для второй системы. А если наш Sysplex из более чем две системы повторяем для каждой из них.
В итоге получаем все системы на новой версии ОС без остановки всего комплекса.
Как я догадываюсь, ответ здесь да, и операция переноса заключается в подключении новых (из LPAR2) процессора, памяти и т.д. и освобождении старых, чтобы полностью отключить LPAR1.
Как уже говорилось в моих статьюх память у каждого LPAR своя, она фиксированна в определенном разделе памяти МФ.
Процессоры могут закрепляться и монопольно использоваться LPAR. Но основным способом использования процессоров на МФ в LPARs является их совместное использования разными LPAR одновременно.
С помощью упоминавшегося уже IIRD, WLM, ParallelSysplex и PR/SM можно организовать автоматический перенос, по мере надобности, процессоров из одних LPAR, где на данный момент нет достаточно работы, в другие где есть работы и им недостаточно мощности доступных процессоров. В принципе можно и память переносить. Я это делал не раз вручную, но это можно автоматизировать и возможно уже автоматизированно.
Переносить же из одного в другой не имеет никакого смысла и соответственно этого нет. .
Моя супер-пупер-мега-ОС,
Почему бы Вам не написать статью про Вашу ОС? Или уже есть? Сохранились ли у Вас исходники?.
Под СВМ мне для этого достаточно было переместить свою пятую точку между двумя соседними мониторами, каждый из которых был консолью двух разных виртуальных машин
Можно было на одном мониторе иметь много пультов ВМ. VTERM это называлось. Были и другие, более стандартные, сервисы для этого, но в СССР испльзовался почти везде (везде где я бывал, а бывал я много где).
...на второй -- моя меганедосистема
Все таки Ваше мегасистема могла гружить на ВМ с монитором на дисплее. Это и не удивительно, пишущая машинка эмулировалась СВИ на дисплее. В чем же тогда была проблема использовать ЕС-1130? Не могли грузить ее без ВМ?
Так эта мысль во всей Вашей статье. Вы зачем-то вводите лишние сущности "настоящая виртуальная машина" и "виртуальная система" (в случае x86). Когда я пытаюсь с помощью сравнений для обоих случаев проследить всю иерархию уровней абстракции вплоть до железа, чтобы таки понять, что именно Вы имеете ввиду, словно бы наталкиваюсь на стену, будто мы с Вами находимся в разных партициях.
То что я говорю про "настоящая ВМ" и "витуализация систем" не означает что я утверждаю будто виртуальные системы не работают на "чистом железе". А как иначе они могли бы работать? Что система виртуализауии должна пошагово эмулировать код виртуальной ОС? Нет конечно, это были бы вилы для производительности.
Мы находимся действительно далеко. Вы на уровне статьи(-ей) Голденберга и платформы х86, а я нахожусь на уровне архитектуры МФ и ее систем (не все они ОС) и мне не чуждо понимаение платформы х86, хотя и без практиуки работы с ее виртуальными системами. Но мне кажется что и те кто работает с х86 виртуальными системами имеют дело всего лишь с неким графическим интерфейсом, позволяющим им конфигурировать и запускать виртуальные системы.
Насколько я понял, в мейнфрейме функции гипервизора PR/SM относительно бесшовно (именно за счет преимуществ архитектуры IBM по сравнению с x86 такая бесшовность возможна) интегрированы с функциями конфигуратора оборудования (аналога переключения рубильников и кабелей). И тут, действительно, легко запутаться и перестать понимать, где кончается виртуализация и начинается изоляция железа исключительно с помощью конфигурации.
Вот хороший пример моей оценке Вашего уровня понимания МФ. Вы пытаетесь из того что прочитали в моих статьях, ну может быть и еще чего-то, делать какие предположения и выводы из них. Но предпололожения Ваши зачастую не имееют отношения к реальному положению дел. Следовательно и выводы тоже.
Никакой "изоляции железа с помошью конфигурации" нет. Все железо МФ используется сомвместно партициями. В зависимости от свойств конкретного железо способы его совместного использования разные. Например паямять может быть совмечстно использована на уровне PR/SM (без виртуализации) только нарезание изолированных кусков памяти для каждой партиции. Процессоры и каналы используются совместно разделяя их использование по времени. На процессоры и в каналы идут потоки процессов из разных партиций и им (процессорам и каналам) до лампочки из какой партийии что приходит. Это разделение происходит в PR/SM.
Теоритически и практически на МФ можно сконфигурировать одну партицию, закрепить за ней все процессоры, каналы и дать доступ ко всей наличной памяти. И запустить в ней один имидж z/VM. И на ВМ "гонять" z/OS, Linux и любые другие ОС МФ, включая саму z/VM. Но так не делают.
В фирме где я отработал 25+ лет никогда не было ни z/VM, ни VM/SP, ни, полагаю VM/370. Хотя может и было, но очень давно. Эта компания вообще очень странная, странность ее (может не только ее, а вообще менталитета англо-саксов и всех других компаний. Я знаю только одну, эту).
Эта компания до середины 90-х имела все свое ИТ на МФ. С середины 90-х было принято решение перевести все некритические для бизнеса приложения на Unix сервера. В итоге к 2006 году (когда я стал единственным системщиком на МФ) остались всего два приложения на МФ. Рукщводство говорило что никогда эти приложения не будут перенесены с МФ.
В итоге на следующей неделе, 12 тоября, я буду останавливать все системы на двух МФ, и их потом демонтируют и сдадут на металлолом. Вместе с террабайтами дисков, лент, специфического МФ коммуникационного оборудования. Все уничтожат к концу года. Сотрут в пыль, как я это называю.
Руководит этим проектом русскоговорящий Дмитрий (походу бывший москвич. У нас в дивизионе таких москвичей (не всех, но их почему то было много) называли "шланги, гофрированные). Он ничего не знает, не понимает и не хочет (тлт не может) знать и понимать про МФ хоть на английском хоть на русском языке ему объясняешь.
Да, еще про конфигурацию. Конфигурация МФ создается в z/OS. В одну конфигурации можно "положить" несколько МФ сразу и все их оборудование, а также обозначить парнтиции. Эта конфигурация транслируется определенным образом и загружается в реальную область где хранится и откуда она берется во время начального запуска МФ или изменяется во время работы МФ и систем. Называется эта область HSA (Hardware Save Area).
У каждой ОС МФ (кроме Linux) тоже есть эта конфигурация. В этих ОС конфигурациях могут иметься конфигурации разных МФ . Как минимум одного. Т.е. одна и та же ОС может грузиться на разные МФ в одно и то же время или в разное.
Кроме активации конфигурации на МФ имеется также задача активации в работающих ОС (кроме Linux).
В одно и тоже время на МФ может быть до 4-х разных конфигаций, одна из которых будет текущей, а остальные как запасные, бэкапы или сто еще можно придумать для этого.
На уровне PR/SM делается конфигурирование партиций в смысле сколько и каких CPU дать той или иной партиции, памяти, какие каналы активировать или деактивировать. Все это, после загрузки ОС, можно делать и из самой системы.
Короче "виртуализация" и "изоляция" это не одно продолжение другого. Это два самостоятельных процесса не перетекающие из одного в другое, а каждое занимающееся своим делом, если хотите.
Надо же столько написать и опять впустую скорее всего.
Чудесно, когда можно полностью избавиться от слоя виртуализации, организуя все только с помощью партиционинга. Но вот проблема: живая миграция, например, в этом случае будет невозможна.
Что такое "миграция"? В х86 это как я понимаю пернос виртуальной машины с одного сервера системы виртулизации на другой. С одной физ машины на другую. Это еще назвается failover, и это давно присутсвует без каких либо виртуальных систем. С виртуальными машинами можно мигрировать всю машину. Без них на целевом сервере уже работает система и, в случае БД, сервер БД в который реплицируются данные. В принципе можно объединить создание системы на целевом сервере с процессом миграции, тоже и с БД.
Делается это во всех случаях примерно одинаково.В случае с виртуальными системами на целевой виртуальной системе создается ВМ аналог мигрируемой. Реплицируются данные, в какой-то момент останавливается исходный мигрируемый процесс (виртуальная машина, БД). Данные синхронизируются, и в случае ВМ копируется вся память ВМ из одной в другую виртуальную систему. Мигрируемый процесс запускается на новом месте.
Когда-то давно на МФ использовались т.н. системные слипы.Это когда после длинной загрузки системы до начала прикладных работ делалась копия памяти и в дальнейшем система загружалась с этой копии чтобы сократить время начальной загрузки с активацией всех служб.
Примерно это входит в состав стандартных возможностей ВМ в z/VM, называемых хпанимые системы и сегменты. Но это не включает приладные процессы, тольк начальную загрузку системы и соместное использование ядра и сегментов на разных виртуальных машинах. Иными словами системы на ВМ z/VM, их ядра и разделяемые сегментв памяти существуют в единственной копии для всех ВМ использующих такую систему и ее сегменты. Конечно это участники памяти используемые только для чтения. Но если на ВМ происходит все таки изменение этих областей памяти то z/VM (CP) автоматически создает уникальную копию для такой машины.
Вернемся к основам. Попытаемся понять, что именно можно считать подлинной виртуализацией, а что - таковой не является. И нужна ли она вообще?
Зачем возвращаться? Все уже давно устоялось на всех платформах, так или иначе.
Подинная виртуализация это на МФ. Может и на другой какой платформе, если общие принципы их работы создают возможности для такой виртуализации. Я не знаю про такие платформы, но допускаючто они есть.
х86-64 пока в состоянии виртуализировать некое подмножество ОС х86. У каждого вендора свое. С тем или иным уклоном,.при этом ввод-вывод ограничивается известным виртуальной системе набором внешних устройств. Эта не великая проблема т.к. основное оборудование сервера где работает виртуальная система годится для большенства применений, а ранообразие например дисковых подсистем покрывается тем что они эмулируют известные сетевые файловые системы (Samba, NFS и т.п.).
Виртуализация, как можно прочитать в моей статье, не панацея навечно. На МФ она (zVM) уже в основном заменена PR/SM (это разные виртуализации если что) и z/OS. На х86 идет замена виртуализации через контейнеризированные технологии (очень похожие на то что давно есть на МФ начиная с MVS. По крайней мере решает схожие проблемы, пользуясь различной терминологией).
Конечно и в z/OS и в контейнерах на х86 (аналогичные тоже доступны на МФ в z/OS с zCX) есть определенные признаки и проявление виртуализаций. Но виртуализация никогда не сводилась только к машинам. Этогораздо более широкое понятие и технология.
Остается только цитировать википедию https://en.wikipedia.org/wiki/Virtualization
virtualization is a series of technologies that allows dividing of physical computing resources into a series of virtual machines, operating systems, processes or containers
The initial implementation x86 architecture did not meet the Popek and Goldberg virtualization requirements to achieve "classical virtualization"
Full virtualization was not fully available on the x86 platform prior to 2005. Many platform hypervisors for the x86 platform came very close and claimed full virtualization
In 2005 and 2006, Intel and AMD (working independently) created new processor extensions to the x86 architecture called Intel VT-x and AMD-V, respectively
А насчет контейнеров могу сказать, что они не позволяют обеспечивать должный уровень изоляции и безопасности из-за того, что пользуются общими абстракциями виртуальной машины, предоставленными единым ядром ОС.
Поэтому, появляются еще подобные гибриды
https://firecracker-microvm.github.io/
Firecracker enables you to deploy workloads in lightweight virtual machines, called microVMs, which provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers.
Похоже, то, что Вы называете "настоящей виртуальной машиной" по-другому называется "полной виртуализацией" (full virtualization) или классической виртуализацией (classical virtualization).
Остается только цитировать википедию https://en.wikipedia.org/wiki/Virtualization
В Википедии дается не определение виртуализации (хотя и такое сойдет), а цитата вот из этого источника:
Rodríguez-Haro, Fernando; Freitag, Felix; Navarro, Leandro; Hernánchez-sánchez, Efraín; Farías-Mendoza, Nicandro; Guerrero-Ibáñez, Juan Antonio; González-Potes, Apolinar (2012-01-01). "A summary of virtualization techniques". Procedia Technology. The 2012 Iberoamerican Conference on Electronics Engineering and Computer Science.
Как Вы можете увидеть это 2012 год. Реальнейшей виртуализации, которую можно датировать 1972 годом когда была аннонсированна VM/370, было уже 40 лет.
А за приведенной Вами цитатой, в Вики, идет вот этот текст:
Virtualization began in the 1960s with IBM CP/CMS.[1] The control program CP provided each user with a simulated stand-alone System/360 computer.
Похоже, то, что Вы называете "настоящей виртуальной машиной" по-другому называется "полной виртуализацией" (full virtualization) или классической виртуализацией (classical virtualization).
Можно и так сказать чтобы не обижать комьюнити ч86 ориентированных специалистов.
Приведеные Вами выши определения (хоть откуда) показывают лишь то что со временем представления о сложных вещах меняются в зависимости от того кем и для чего эти представления создаются.
Я читал про виртуализацию в книгах конца 70-х. Там говорилось о том что изначально и содержалось в значении слова "виртуальность", т.е. воображаемость.
Виртуа́льность (лат. virtualis — возможный) — воображаемые объект или состояние, которые реально не существуют, но могут возникнуть при определённых условиях.
Т.е. (говорилось в тех книгах), например, для программиста компьютер это машина выполняющая программы написанные на том языке, который использует программист. Для оператора ОС компьютер это машина выполняющая команды оператора. И т.д..
Если вернуться к конкретным виртуальным машинам на МФ и х86-64, то да можно говорить про "полную" виртуализацию. Но что тогда такое "неполная"?
Кроме того, вместо расплывчатой типизации уровней виртуализации, выраженных через Type 1, Type 2 в, давно устаревшем, стиле Гольдберга, я бы использовал, тоже применяемую, типизацию уровней "Hardware" and "Software".
В этой шкале уровней, на МФ, мы имеем оба уровня (PR/SM и z/VM). На х86-64 только один, второй. Посмею утверждать что железо х86-64 не виртуализируемо на уровне железа. Почему? я не могу строго сформулировать, но мысли на эту тему есть. Думаю если бы такаяя возможность имелась ей бы обязательно воспользовались бы. Это было бы круто.
Поправка. Вроде разобрался: дело в том, что в оригинальной типизации Гольдберга для 2-го типа используется не любая операционная система, а только так называемая conventional os. Поэтому, несмотря на то, что z/VM является операционной системой специального назначения, специализирующейся на функции гипервизора, она не является conventional os. Поэтому, её лучше записать в 1 тип в случае, если она работает на железе напрямую. Да и абстракция оборудования в этом случае выполняется один раз: операционной системой или гипервизором, не важно как назвать.
Поэтому на МФ возможно то что невозможно на х86-64, а именно загружать zVM на виртуальной машине, а в ней, на её ВМ второго уровня, загружать другую zVM. И так далее.
Процессоры х86 с аппаратной виртуализацией доступны лет 20 как. И на компьютерах с этими процессорами тоже можно создавать многократно вложенные виртуальные машины.
Что такое виртуальная машина и чем она отличается от виртуальных систем