Начнём с теории.
Полная виртуализация - виртуализация целой системы с типовым аппаратным обеспечением. Бывает аппаратно ускоренной, программно ускоренной (бинарная трансляция) и не ускоренной (эмуляция).
Паравиртуализация - используется в Xen. Плюс в том, что её не надо ускорять, минус - что ядро ОС должно быть дописано под гипервизор, поэтому таким способом можно запускать ограниченное подмножество ОС (Linux, FreeBSD, NetBSD, Solaris). Windows и DOS - точно нельзя.
Полная виртуализация с паравиртуальными драйверами (в Xen обозначается HVM/PV) - от обычной полной виртуализации отличается тем, что часть типовых периферийных устройств (дисковый контроллер, сетевая карта, видеокарта) заменяется на синтетические, драйверы для которых разрабатываются в рамках решения виртуализации. Такое есть, например, у QEMU (VirtIO), Xen (XenPV), Hyper-V (VMBus, Enlightments), основных гипервизоров II типа. Также, в рамках этих решений часто предоставляется доступ к ФС хоста, для которого (внутри словных VMWare Tools) активно используется протокол 9P.
Контейнеризация - легковесный вариант виртуализации, ещё более легковесный, чем паравиртуализация. Работает с помощью системного вызова chroot(), присутствующего в Linux, FreeBSD и т.п. и позволяет создавать обособленные окружения той же системы (в Linux можно создавать только контейнеры на базе Linux), и изоляция получается довольно слабая, поскольку контейнер делит с окружением хоста одно и то же ядро, из-за чего приходится всякие там cgroups придумывать. Самый каличный способ виртуализации, но для существенного числа задач хватает. Из интересного можно отметить только, что с помощью контейнеризации можно развернуть, например, полноценное окружение GNU/Linux на Android (с помощью Linux Deploy) или юзерленд OpenWRT на заводской прошивке роутеров Keenetic.
Из распространённых решений контейнеризации, используемых в серьёзных задачах, можно отметить Docker, FreeBSD Jails, WSL.
Полная виртуализация - виртуализация целой системы с типовым аппаратным обеспечением. Бывает аппаратно ускоренной, программно ускоренной (бинарная трансляция) и не ускоренной (эмуляция).
Паравиртуализация - используется в Xen. Плюс в том, что её не надо ускорять, минус - что ядро ОС должно быть дописано под гипервизор, поэтому таким способом можно запускать ограниченное подмножество ОС (Linux, FreeBSD, NetBSD, Solaris). Windows и DOS - точно нельзя.
Полная виртуализация с паравиртуальными драйверами (в Xen обозначается HVM/PV) - от обычной полной виртуализации отличается тем, что часть типовых периферийных устройств (дисковый контроллер, сетевая карта, видеокарта) заменяется на синтетические, драйверы для которых разрабатываются в рамках решения виртуализации. Такое есть, например, у QEMU (VirtIO), Xen (XenPV), Hyper-V (VMBus, Enlightments), основных гипервизоров II типа. Также, в рамках этих решений часто предоставляется доступ к ФС хоста, для которого (внутри словных VMWare Tools) активно используется протокол 9P.
Контейнеризация - легковесный вариант виртуализации, ещё более легковесный, чем паравиртуализация. Работает с помощью системного вызова chroot(), присутствующего в Linux, FreeBSD и т.п. и позволяет создавать обособленные окружения той же системы (в Linux можно создавать только контейнеры на базе Linux), и изоляция получается довольно слабая, поскольку контейнер делит с окружением хоста одно и то же ядро, из-за чего приходится всякие там cgroups придумывать. Самый каличный способ виртуализации, но для существенного числа задач хватает. Из интересного можно отметить только, что с помощью контейнеризации можно развернуть, например, полноценное окружение GNU/Linux на Android (с помощью Linux Deploy) или юзерленд OpenWRT на заводской прошивке роутеров Keenetic.
Из распространённых решений контейнеризации, используемых в серьёзных задачах, можно отметить Docker, FreeBSD Jails, WSL.
Одно из связанных понятий - эмуляция.
В случае использования аппаратной виртуализации сводится к имитации для виртуалки чипсета и типовой периферии (например, у гостевой ОС может не быть поддержки драйверов VirtIO, но быть драйверы для сетевых карт Intel Pro/1000 м Realtek 8139, дисковых контроллеров Intel PIIX и видеокарт вроде Cirrus Logic).
Но на архитектуре x86 аппаратная виртуализация появилась далеко не сразу, поэтому первые решения виртуализации эмулировали вообще всё - и процессор, и контроллер памяти, и небо, и Аллаха. Некоторые решения виртуализации по различным причинам делают так до сих пор (например, DOSBox, Bochs, PCem).
Но полная эмуляция или интерпретация - это медленно, и даже без VT-x ускорять её как-то надо - с помощью бинарной трансляции.
Основных подходов к БТ два:
Динамическая перекомпиляция - "умная" интерпретация, используется при эмуляции другой архитектуры (например, DOSBox, эмулирующим x86 на смартфоне на процессоре архитектуры ARM). Или Microsoft Virtual PC на PowerPC-шных Маках. В современных решениях, требующих именно эмуляции, как правило, поддерживается только она.
Trap-and-emulate - использовался в первых версиях всех решений VMWare (Workstation, GSX/Server, ESX/ESXi - всех), Parallels, x86-версиях Connectix/Microsoft Virtual PC и QEMU с драйвером kqemu. Быстрее динамической перекомпиляции, но подходит только для эмуляции той же архитектуры, и даже так есть нюансы. Но поскольку ту же архитектуру сейчас можно виртуализировать и с аппаратным ускорением, т.е. с помощью расширения системы команд - на это сейчас благополучно забили, и актуальные версии всех перечисленных решений больше trap-and-emulate не умеют.
А вот ЦП, не имеющие поддержки нужных расширений системы команд, до сих пор иногда используются, о чём можно почитать в соседних тредах.
В случае использования аппаратной виртуализации сводится к имитации для виртуалки чипсета и типовой периферии (например, у гостевой ОС может не быть поддержки драйверов VirtIO, но быть драйверы для сетевых карт Intel Pro/1000 м Realtek 8139, дисковых контроллеров Intel PIIX и видеокарт вроде Cirrus Logic).
Но на архитектуре x86 аппаратная виртуализация появилась далеко не сразу, поэтому первые решения виртуализации эмулировали вообще всё - и процессор, и контроллер памяти, и небо, и Аллаха. Некоторые решения виртуализации по различным причинам делают так до сих пор (например, DOSBox, Bochs, PCem).
Но полная эмуляция или интерпретация - это медленно, и даже без VT-x ускорять её как-то надо - с помощью бинарной трансляции.
Основных подходов к БТ два:
Динамическая перекомпиляция - "умная" интерпретация, используется при эмуляции другой архитектуры (например, DOSBox, эмулирующим x86 на смартфоне на процессоре архитектуры ARM). Или Microsoft Virtual PC на PowerPC-шных Маках. В современных решениях, требующих именно эмуляции, как правило, поддерживается только она.
Trap-and-emulate - использовался в первых версиях всех решений VMWare (Workstation, GSX/Server, ESX/ESXi - всех), Parallels, x86-версиях Connectix/Microsoft Virtual PC и QEMU с драйвером kqemu. Быстрее динамической перекомпиляции, но подходит только для эмуляции той же архитектуры, и даже так есть нюансы. Но поскольку ту же архитектуру сейчас можно виртуализировать и с аппаратным ускорением, т.е. с помощью расширения системы команд - на это сейчас благополучно забили, и актуальные версии всех перечисленных решений больше trap-and-emulate не умеют.
А вот ЦП, не имеющие поддержки нужных расширений системы команд, до сих пор иногда используются, о чём можно почитать в соседних тредах.
Едем дальше.
Помимо эмуляции и эмуляторов есть ещё гипервизоры, они же "virtual machine monitor". Как правило, так называются решения виртуализации, работающие преимущественно засчёт аппаратной виртуализации... впрочем, пока её не было, так назывались и эмуляторы, реализующие подход trap-and-emulate.
Различают гипервизоры I и II типа, но на самом деле разница между ними охуительно размыта. Сейчас рассмотрим на примерах.
Помимо эмуляции и эмуляторов есть ещё гипервизоры, они же "virtual machine monitor". Как правило, так называются решения виртуализации, работающие преимущественно засчёт аппаратной виртуализации... впрочем, пока её не было, так назывались и эмуляторы, реализующие подход trap-and-emulate.
Различают гипервизоры I и II типа, но на самом деле разница между ними охуительно размыта. Сейчас рассмотрим на примерах.
Гипервизоры I типа - это, по определению, те, которые устанвливаются "непосредственно на оборудование", т.е. вместо ОС.
К ним обычно относят те же QEMU/KVM, Xen, VMWare ESXi, Microsoft Hyper-V.
А гипервизоры II типа - те, которые устанвливаются как приложение внутрь обычной десктопной или серверной ОС. К ним обычно относят VMWare Workstation, VirtualBox, Microsoft Virtual PC...
К ним обычно относят те же QEMU/KVM, Xen, VMWare ESXi, Microsoft Hyper-V.
А гипервизоры II типа - те, которые устанвливаются как приложение внутрь обычной десктопной или серверной ОС. К ним обычно относят VMWare Workstation, VirtualBox, Microsoft Virtual PC...
А теперь давайте попробуем разобрать различия между ними.
QEMU/KVM - это вообще две отдельных вещи, где KVM - это модуль ядра Linux или Solaris, QEMU - это эмулятор, или, говоря терминами Xen - "device model". Эмулятор, который без KVM или другого, в терминах QEMU, "ускорителя" (они могут быть разными) - будет тормозить, как и любой другой "чистый" эмулятор.
То есть, QEMU/KVM не устанавливается вместо ОС - он устанавливается внутрь окружения GNU/Linux или OpenSolaris.
Xen - вот тут уже больше похоже на правду, поскольку он действительно запускается до любых ОС. Но, при этом, ему так же требуется некий Dom0 - да, это тоже виртуалка, но особенная, которая выполняет все те же функции, что и ОС хоста у гипервизоров II типа.
Hyper-V... с ним, как с Xen, поскольку его разработчики прямо вдохновлялись архитектурой последнего, и сделали её очень похожей. Ходят даже слухи, что сначала они пытались портировать XP под Xen, может даже режим PV, но получилось слишком охуительно, поэтому проект отменили и наработки засекретили, чтобы не помогать конкуренту. Собственно, Hyper-V как раз мог стать результатом этого проекта, равно как и драйверы XenPV (но уже для запуска винды в режиме HVM/PV).
Да и ESX/ESXi... Пока он ещё был без "i" - то чем-то напоминал Xen - ему требовалась некая "Service Console OS" - "виртуалка с привилегиями" на RHEL, аналогичная Dom0 у Xen, которая, по сути, запускала вариацию на тему линуксового GSX. Когда появился ESXi с его VMKernel - изменилось то, что Linux теперь не было, а окружение "Service Console OS" было сильно облегчено. Тем не менее, там всё равно остался тот же BusyBox, тот же OpenSSH, всё в том же формате ELF, что позволило написать под ESXi криптолокер (!!!), пруф https://habr.com/ru/articles/868664/.
То есть, всё равно какое-то UNIX-подобное окружение, в котором гипервизор был не один. Более того, в этом окружении всё так же был, например, бинарник "vmx", делавший то же самое, что и в Workstation и GSX.
В итоге, из "монолитных" гипервизоров, которые буквально соответствуют определению I типа, полностью заменяя ОС хоста, остаётся только IBM PowerVM, являющийся частью микропрограммы серверов IBM POWER.
QEMU/KVM - это вообще две отдельных вещи, где KVM - это модуль ядра Linux или Solaris, QEMU - это эмулятор, или, говоря терминами Xen - "device model". Эмулятор, который без KVM или другого, в терминах QEMU, "ускорителя" (они могут быть разными) - будет тормозить, как и любой другой "чистый" эмулятор.
То есть, QEMU/KVM не устанавливается вместо ОС - он устанавливается внутрь окружения GNU/Linux или OpenSolaris.
Xen - вот тут уже больше похоже на правду, поскольку он действительно запускается до любых ОС. Но, при этом, ему так же требуется некий Dom0 - да, это тоже виртуалка, но особенная, которая выполняет все те же функции, что и ОС хоста у гипервизоров II типа.
Hyper-V... с ним, как с Xen, поскольку его разработчики прямо вдохновлялись архитектурой последнего, и сделали её очень похожей. Ходят даже слухи, что сначала они пытались портировать XP под Xen, может даже режим PV, но получилось слишком охуительно, поэтому проект отменили и наработки засекретили, чтобы не помогать конкуренту. Собственно, Hyper-V как раз мог стать результатом этого проекта, равно как и драйверы XenPV (но уже для запуска винды в режиме HVM/PV).
Да и ESX/ESXi... Пока он ещё был без "i" - то чем-то напоминал Xen - ему требовалась некая "Service Console OS" - "виртуалка с привилегиями" на RHEL, аналогичная Dom0 у Xen, которая, по сути, запускала вариацию на тему линуксового GSX. Когда появился ESXi с его VMKernel - изменилось то, что Linux теперь не было, а окружение "Service Console OS" было сильно облегчено. Тем не менее, там всё равно остался тот же BusyBox, тот же OpenSSH, всё в том же формате ELF, что позволило написать под ESXi криптолокер (!!!), пруф https://habr.com/ru/articles/868664/.
То есть, всё равно какое-то UNIX-подобное окружение, в котором гипервизор был не один. Более того, в этом окружении всё так же был, например, бинарник "vmx", делавший то же самое, что и в Workstation и GSX.
В итоге, из "монолитных" гипервизоров, которые буквально соответствуют определению I типа, полностью заменяя ОС хоста, остаётся только IBM PowerVM, являющийся частью микропрограммы серверов IBM POWER.
>ESX/ESXi
А вообще, если откопать на торрентах ESX , попробовать поставить его на какой-нибудь старенький хост и понаблюдать в это время за консолью - то сначала там будет процесс загрузки RHEL, а потом уже "Starting VMKernel...". Т.е. термин VMKernel появился ещё до ESXi, и, если он обозначал то же самое, то, получается, Service Console OS сначала грузилась на железе, а потом уже, кхм, перемещалась в виртуалку. Удивляет, но вообще, сделать окружение хоста виртуалкой - для гипервизоров обычное дело. Так до сих пор делают, например, отладчики, использующие аппаратную виртуализацию, или Касперский, когда использует её же для усиления защиты.
>Hyper-V... с ним, как с Xen, поскольку его разработчики прямо вдохновлялись архитектурой последнего, и сделали её очень похожей.
Где-то ещё презентация с наглядным сравнением архитектур была, ищу ссылку.
Нашёл. Правда, уже только в Wayback - пидорасы из SlideShare у себя её потёрли.
https://web.archive.org/web/20160324063800/http://www.slideshare.net/xen_com_mgr/why-xen-slides
Гипервизоры II типа...
Во-первых, они тоже используют аппаратную виртуализацию, когда могут.
И тоже используют свои модули ядра.
VirtualBox - он ставит DKMS-модули, без которых нихуя не работает.
Workstation... в общем-то, поступает так же, ему ещё под желаемую версию гипера нужно конкретную версию линукса подбирать. А если ядро ему не подходит - он даже работать в режиме "клиента к мейнфреймам на базе ESXi" работать не будет.
А у MSVPC есть некий "vmm.sys". Ещё, его версия на PowerPC-шные Маки тоже в официальной документации называется гипервизором, хотя по сути это вообще эмулятор.
Короче, разница между гипервизорами I и II довольно размыта, поэтому особо опираться на эту классификацию не стоит. Если что и устанавливается "прямо на железо, вместо ОС" - то это не гипервизор, а решение, его содержащее. Одно из исключений - IBM PowerVM.
Ну, ещё можно просто вспомнить, что у Workstation, Parallels и VirtualBox есть "паравиртуальная видеокарта", позволяющая виртуалке пользоваться видеокартой хоста через трансляцию вызовов к графическим API, причём не монопольно (!!!), а в KVM и ESXi аналогичное реализовано гораздо беднее: QXL - ускоряет только 2D, VirtIO-GPU - только для Linux-гостей и 8.1+, и то драйвер для винды - "DOD" и постоянно крашит всю виртуалку, а "VMVGA" в ESXi, в отличие от Workstation, тоже ускоряет только 2D, и, поскольку ESXi видеодрайвера в этом случае тоже нужны, как винде или линуксу, а под домашние видеокарты драйверов для ESXi нет - хоть виртуалка и будет видеть GPU, но ESXi просто будет эмулировать GPU силами ЦП.
Зато KVM, Xen, Hyper-V и ESXi умеют с помощью IOMMU пробрасывать в виртуалку PCI-устройства, и в них настраивать это обязательно, чтобы виртуалка вообще могла пользоваться нормальной видеокартой.
Вот по этому признаку можно классифицировать, а изначальные определения - неоднозначны. Или стоп, в Hyper-V же ещё есть RemoteFX... то есть, был до 10 1809 и сервера 2019 включительно.
Во-первых, они тоже используют аппаратную виртуализацию, когда могут.
И тоже используют свои модули ядра.
VirtualBox - он ставит DKMS-модули, без которых нихуя не работает.
Workstation... в общем-то, поступает так же, ему ещё под желаемую версию гипера нужно конкретную версию линукса подбирать. А если ядро ему не подходит - он даже работать в режиме "клиента к мейнфреймам на базе ESXi" работать не будет.
А у MSVPC есть некий "vmm.sys". Ещё, его версия на PowerPC-шные Маки тоже в официальной документации называется гипервизором, хотя по сути это вообще эмулятор.
Короче, разница между гипервизорами I и II довольно размыта, поэтому особо опираться на эту классификацию не стоит. Если что и устанавливается "прямо на железо, вместо ОС" - то это не гипервизор, а решение, его содержащее. Одно из исключений - IBM PowerVM.
Ну, ещё можно просто вспомнить, что у Workstation, Parallels и VirtualBox есть "паравиртуальная видеокарта", позволяющая виртуалке пользоваться видеокартой хоста через трансляцию вызовов к графическим API, причём не монопольно (!!!), а в KVM и ESXi аналогичное реализовано гораздо беднее: QXL - ускоряет только 2D, VirtIO-GPU - только для Linux-гостей и 8.1+, и то драйвер для винды - "DOD" и постоянно крашит всю виртуалку, а "VMVGA" в ESXi, в отличие от Workstation, тоже ускоряет только 2D, и, поскольку ESXi видеодрайвера в этом случае тоже нужны, как винде или линуксу, а под домашние видеокарты драйверов для ESXi нет - хоть виртуалка и будет видеть GPU, но ESXi просто будет эмулировать GPU силами ЦП.
Зато KVM, Xen, Hyper-V и ESXi умеют с помощью IOMMU пробрасывать в виртуалку PCI-устройства, и в них настраивать это обязательно, чтобы виртуалка вообще могла пользоваться нормальной видеокартой.
Вот по этому признаку можно классифицировать, а изначальные определения - неоднозначны. Или стоп, в Hyper-V же ещё есть RemoteFX... то есть, был до 10 1809 и сервера 2019 включительно.
>разница между гипервизорами I и II довольно размыта
А ты рассмотри эту разницу через исполнение на блоках цп.
Дальше разберём некоторые особенности архитектуры, необходимые для понимания нюансов, возникающих в связи с различными подходами виртуализации.
Вспомним о режимах процессора x86:
https://www.seabios.org/Memory_Model.html
- Реальный режим: команды 16-разрядные, видно только первый 1 МБ ОЗУ со всеми правилами относительно 384 КБ от 640 килобайта до конца первого мегабайта, адресация вида "сегмент:смещение".
- "Нереальный режим", или "большой реальный" - уже видно первые 4 ГБ, но остальное - всё то же самое. А, ну и VirtualBox его не поддерживает.
- Появляющийся в 286 защищённый режим, который, начиная с 386 может ещё быть 32-разрядным, адресация может быть "плоской", т.е. только "смещение" от начала, без сегмента, а ещё появляется "виртуальная память" - и основной её функцией является отнюдь не дисковая подкачка, а защита приложений друг от друга через выдачу каждому процессу своего адресного пространства. Память выше первого мегабайта стала назваться XMS.
- А ещё с помощью виртуальной памяти можно эмулировать EMS! И помогает в этом режим виртуального 8086 - самая первая аппаратная виртуализация на x86. В чём суть: когда выяснилось, что 640 КБ таки каждому не хватает, сначала пришлось изобретать костыль в виде контроллеров дополнительной DRAM в виде ISA-карточек, которым надо было эту дополнительную DRAM отображать куда-то в первый мегабайт - выше 640 килобайта или ниже (поначалу - ниже), но именно в первый мегабайт - вот так работала EMS. А с появлением 386 и защищённого режима, EMS хоть и стала реализовываться программно, но изначально-то стандарт EMS был на оборудование, т.е. теперь нужно было это оборудование эмулировать. Вот тут и пригодилась и виртуальная память, и режим V86 - с ним EMM386 делал DOS, из которого запускался, виртуалкой внутри задачи защищённого режима, а она работала с EMM386, как с обычным драйвером EMS-карточки. Вот это и был первый гипервизор на x86.
Потом были DesqView, Windows от 2.1/386 до ME, полуось - они уже эти DOS-окружения могли плодить и гонять одновременно, и, фактически, тоже были гипервизорами. Да даже 32-разрядная WinNT вплоть до последней 10 обеспечивала прозрачный запуск DOS-приложений именно так. Короче, вот с чего начались гипервизоры.
- Ну и, конечно, "длинный режим" - единственный 64-разрядный. До появления VT-x/SVM (например, на атлонах на 939 сокете) в нём было скучно, поскольку как раз в нём V86-задачи запускать уже нельзя, поэтому неудивительно, что 64-разрядная XP оказалась нахуй никому нинужна, и смысла выпускать её локализованные дистрибутивы не было (что только усилило её нинужность). Гораздо интереснее было в последние годы распространённости XP (когда иметь больше 4 ГБ ОЗУ стало уже вполне реально) заставлять её включать PAE, ломая ядро (а потом удивляться, какого хуя отъёбывает WLAN от Atheros или USB-контроллер Intel при попытке заюзать устройство, работающее через драйвер WinUSB.
Вспомним о режимах процессора x86:
https://www.seabios.org/Memory_Model.html
- Реальный режим: команды 16-разрядные, видно только первый 1 МБ ОЗУ со всеми правилами относительно 384 КБ от 640 килобайта до конца первого мегабайта, адресация вида "сегмент:смещение".
- "Нереальный режим", или "большой реальный" - уже видно первые 4 ГБ, но остальное - всё то же самое. А, ну и VirtualBox его не поддерживает.
- Появляющийся в 286 защищённый режим, который, начиная с 386 может ещё быть 32-разрядным, адресация может быть "плоской", т.е. только "смещение" от начала, без сегмента, а ещё появляется "виртуальная память" - и основной её функцией является отнюдь не дисковая подкачка, а защита приложений друг от друга через выдачу каждому процессу своего адресного пространства. Память выше первого мегабайта стала назваться XMS.
- А ещё с помощью виртуальной памяти можно эмулировать EMS! И помогает в этом режим виртуального 8086 - самая первая аппаратная виртуализация на x86. В чём суть: когда выяснилось, что 640 КБ таки каждому не хватает, сначала пришлось изобретать костыль в виде контроллеров дополнительной DRAM в виде ISA-карточек, которым надо было эту дополнительную DRAM отображать куда-то в первый мегабайт - выше 640 килобайта или ниже (поначалу - ниже), но именно в первый мегабайт - вот так работала EMS. А с появлением 386 и защищённого режима, EMS хоть и стала реализовываться программно, но изначально-то стандарт EMS был на оборудование, т.е. теперь нужно было это оборудование эмулировать. Вот тут и пригодилась и виртуальная память, и режим V86 - с ним EMM386 делал DOS, из которого запускался, виртуалкой внутри задачи защищённого режима, а она работала с EMM386, как с обычным драйвером EMS-карточки. Вот это и был первый гипервизор на x86.
Потом были DesqView, Windows от 2.1/386 до ME, полуось - они уже эти DOS-окружения могли плодить и гонять одновременно, и, фактически, тоже были гипервизорами. Да даже 32-разрядная WinNT вплоть до последней 10 обеспечивала прозрачный запуск DOS-приложений именно так. Короче, вот с чего начались гипервизоры.
- Ну и, конечно, "длинный режим" - единственный 64-разрядный. До появления VT-x/SVM (например, на атлонах на 939 сокете) в нём было скучно, поскольку как раз в нём V86-задачи запускать уже нельзя, поэтому неудивительно, что 64-разрядная XP оказалась нахуй никому нинужна, и смысла выпускать её локализованные дистрибутивы не было (что только усилило её нинужность). Гораздо интереснее было в последние годы распространённости XP (когда иметь больше 4 ГБ ОЗУ стало уже вполне реально) заставлять её включать PAE, ломая ядро (а потом удивляться, какого хуя отъёбывает WLAN от Atheros или USB-контроллер Intel при попытке заюзать устройство, работающее через драйвер WinUSB.
Ещё одной особенностью защищённого и длинного режимов стало появление колец защиты, с 3-го по 0-ое:
в 3 исполнялся весь юзерленд,
в 0 - ядро и дровишки,
а 1-2 почти никто не юзал, разве что полуось гоняла драйвера в 2.
Вот это и помогло при реализации бинарной трансляции:
инструкции, используемые приложениями юзерленда, бывшие, в основном непривилегированными, можно было тупо исполнять так же, как используемые приложениям хоста,
а код 0 кольца виртуалки - исполнять в 1 кольце хоста.
Со 2-ым кольцом чуть посложнее - MSVPC его использование виртуалками, вроде, поддерживал, а VirtualBox - нихуя. И именно поэтому нихуя не умел запускать вируталки с полуосью на том самом атлончике с 939 сокетом, ранних несерверных Атомах или любых других ЦП без VT-x/SVM.
Дальнейшее развитие ЦП привело к появлению дополнительных уровней привилегий, также присутствующих в этой иерархии:
- System Management Mode, считающийся -2 "кольцом" (но упомянутый раньше, потому что был уже в 486) - из полезного, в нём BIOS может крутить свой USB-стек, позволяя ОС без драйверов (и себе самому) видеть USB-клавы и мыши как PS/2, а флешки и DAS - как обычные IDE-диски.
- Как раз-таки "режим гипервизора" на позиции -1 (похоже, относительно 0 кольца у виртуальных ЦП, реализуемых с помощью VT-x/SVM);
- Incel Management Engine, этот ебучий чипсетно-микропрограммный бэкдор (впрочем, подрабатывающий аналогом BMC и эмулем TPM) в связи с тем, что он "сильнее" всех остальных подсистем, получил позицию -3.
В ARM тоже были режимы разной разрядности (26, 32, 64) и режимы совместимости, вместо колец защиты - "уровни выполнения":
EL0 - юзерленд,
EL1 - ядро,
EL2 - гипервизор (начиная с ядер Cortex-A15).
Ну и, начиная с ARMv8 ещё появился EL3 для местных аналогов Incel ME, которые, впрочем, на процессорах Qualcomm издавна уже крутились в EL2, из-за чего собирать ядро с поддержкой KVM для ведроид-смартфонов и планшетов смысла не имеет нихуя, потому что EL2 занят ебучим baseband'ом (впрочем, на Люмиях 950XL это как-то решили, даже скрин с Hyper-V был). Вот у медиатеков с этим получше, и подтверждение тому - возможность спокойно запускать KVM на хромбуках с MT8173C. А ещё аппаратная виртуализация доступна на малинке, причём уже на второй (BCM2836), а на четвёртой (BCM2711) даже работает без хаков, и, нихуя себе, на 4 малинку есть нативный ESXi!
И такая же подлянка, как у длинного режима x86, совсем недавно в ARM появилась. А именно, из ядер Cortex-A76 и новее вырезали возможность исполнять 32-битный код где-то, кроме EL1, а в ARMv9 нет даже этого. Из-за чего разрабы RISC OS очень сильно охуевают и собирают лямы фунтов, чтобы нанять разрабов, которые сию ОС исторической ценности, с которой вообще начинался ARM, перепишут с ассемблера на C, чтобы она могла на новых ARM работать...
в 3 исполнялся весь юзерленд,
в 0 - ядро и дровишки,
а 1-2 почти никто не юзал, разве что полуось гоняла драйвера в 2.
Вот это и помогло при реализации бинарной трансляции:
инструкции, используемые приложениями юзерленда, бывшие, в основном непривилегированными, можно было тупо исполнять так же, как используемые приложениям хоста,
а код 0 кольца виртуалки - исполнять в 1 кольце хоста.
Со 2-ым кольцом чуть посложнее - MSVPC его использование виртуалками, вроде, поддерживал, а VirtualBox - нихуя. И именно поэтому нихуя не умел запускать вируталки с полуосью на том самом атлончике с 939 сокетом, ранних несерверных Атомах или любых других ЦП без VT-x/SVM.
Дальнейшее развитие ЦП привело к появлению дополнительных уровней привилегий, также присутствующих в этой иерархии:
- System Management Mode, считающийся -2 "кольцом" (но упомянутый раньше, потому что был уже в 486) - из полезного, в нём BIOS может крутить свой USB-стек, позволяя ОС без драйверов (и себе самому) видеть USB-клавы и мыши как PS/2, а флешки и DAS - как обычные IDE-диски.
- Как раз-таки "режим гипервизора" на позиции -1 (похоже, относительно 0 кольца у виртуальных ЦП, реализуемых с помощью VT-x/SVM);
- Incel Management Engine, этот ебучий чипсетно-микропрограммный бэкдор (впрочем, подрабатывающий аналогом BMC и эмулем TPM) в связи с тем, что он "сильнее" всех остальных подсистем, получил позицию -3.
В ARM тоже были режимы разной разрядности (26, 32, 64) и режимы совместимости, вместо колец защиты - "уровни выполнения":
EL0 - юзерленд,
EL1 - ядро,
EL2 - гипервизор (начиная с ядер Cortex-A15).
Ну и, начиная с ARMv8 ещё появился EL3 для местных аналогов Incel ME, которые, впрочем, на процессорах Qualcomm издавна уже крутились в EL2, из-за чего собирать ядро с поддержкой KVM для ведроид-смартфонов и планшетов смысла не имеет нихуя, потому что EL2 занят ебучим baseband'ом (впрочем, на Люмиях 950XL это как-то решили, даже скрин с Hyper-V был). Вот у медиатеков с этим получше, и подтверждение тому - возможность спокойно запускать KVM на хромбуках с MT8173C. А ещё аппаратная виртуализация доступна на малинке, причём уже на второй (BCM2836), а на четвёртой (BCM2711) даже работает без хаков, и, нихуя себе, на 4 малинку есть нативный ESXi!
И такая же подлянка, как у длинного режима x86, совсем недавно в ARM появилась. А именно, из ядер Cortex-A76 и новее вырезали возможность исполнять 32-битный код где-то, кроме EL1, а в ARMv9 нет даже этого. Из-за чего разрабы RISC OS очень сильно охуевают и собирают лямы фунтов, чтобы нанять разрабов, которые сию ОС исторической ценности, с которой вообще начинался ARM, перепишут с ассемблера на C, чтобы она могла на новых ARM работать...
>Вот это и помогло при реализации бинарной трансляции:
>инструкции, используемые приложениями юзерленда, бывшие, в основном непривилегированными, можно было тупо исполнять так же, как используемые приложениям хоста,
>а код 0 кольца виртуалки - исполнять в 1 кольце хоста.
>Со 2-ым кольцом чуть посложнее - MSVPC его использование виртуалками, вроде, поддерживал, а VirtualBox - нихуя. И именно поэтому нихуя не умел запускать вируталки с полуосью на том самом атлончике с 939 сокетом, ранних несерверных Атомах или любых других ЦП без VT-x/SVM.
Совсем забыл дописать в нужное место.
Во-первых - что V86-задачи виртуалки можно было виртуализировать так же, как и простые задачи 3 кольца, без проблем.
А во-вторых, что с 0 кольцом ситуация была с точностью до наоборот: поскольку он состоял практически полностью из привилегированных инструкций, которые надо было "отлавливать и эмулировать", чуть ли не интерпретировать - пытаться ускорять его было бесполезно. То же самое - про весь код реального режима, который исполняется в 0 кольце, потому что в нём понятия колец защиты нет.
И даже появление VT-x проблемы с виртуализацией это сразу не решило: на P4, CD/C2D и Nehalem, VT-x умел ускорять только защищённый режим, а реальный всё равно приходилось эмулировать, вплоть до Westmere с его фичей "unrestricted guest", для которой ещё EPT пришлось допилить (вложенную виртуальную память). Но осадочек всё равно остался, и наблюдается он, например на охуительных серваках HP с процессорами Haswell-Broadwell в количестве двух штук.
Коллегам ОПа приходится активно гонять по много экземпляров KVM, вложенного в другой KVM, что приводит к созданию слишком дохуя vCPU.
В результате этого вложенные виртуалки начинают ощутимо так протормаживать в BIOS, а потом, когда гостевая ОС загрузится - работают нормально. Или сразу работают нормально, если включить виртуалку на UEFI.
А разгадка проста: ОС не тормозит, потому что она вся работает в защищённом режиме, UEFI не тормозит по этой же причине. А вот когда виртуалка грузится в BIOS, запускать её приходится в реальном режиме, который так охуительно сложно эмулировать, что при таком количестве одновременно существующих vCPU даже этот "unrestricted guest" не справляется.
И небольшую подсказочку по этим самым расширениям:
1. Виртуализация исполнения
- VM8086 - с ним уже разобрались, умеет запускаться в защищённом режиме и виртуализировать DOS-окружения. Присутствует в ЦП любых вендоров, начиная с 386.
- Intel VT-x - появился в последних ревизиях четвёртых пней, умеет запускаться в 64-разрядном режиме. Изначально мог ускорять только защищённый режим.
- AMD-V, ранее SVM ("Secure Virtual Machines") - функциональный аналог VT-x, при этом только функциональный, т.е. сами команды у него совсем другие, и в гипервизорах его поддержку приходится реализовывать отдельно.
- Unrestricted guest - улучшение VT-x, реализующее реальный режим для vCPU и зависящее от EPT (об этом ниже). Появилось в микроархитектуре Westmere.
- VIA/Zhaoxin VT-x - аналог VT-x в процессорах VIA, появившийся в серии Nano, реализован совместимым с Intel VT-x по командам, как раз, чтобы не получилось, как с AMD-V, но хули толку, если строка вендора в CPUID у него отличается, а гипервизоры пугаются, когда не видят там строчку от Intel или AMD.
- HYP - название расширения аппаратной виртуализации архитектуры ARM, появившегося в ядре Cortex-A15 и использующего уровень выполнения EL2.
2. Виртуализация управления памятью
Поскольку управление виртуальной памятью подразумевало использование привилегированных инструкций, которые, как было сказано выше, хуёво ускорялись, в дополнение к VT-x и т.п. пришлось придумывать ещё т.н. вложенную трансляцию адресов (англ. second level address translation, SLAT).
У Intel это расширение называется "extended page tables" (EPT) и появилось то ли в Nehalem, то ли в Westmere; у Zhaoxin оно называется так же и по командам с Intel совместимо,
а вот у AMD - так же несовместимо, называется "rapid virtualization indexing" (RVI) и, в отличие от Intel, появилось раньше SVM, о чём повествуется в документе вмвари по ссылке из ОП-поста.
Да, у ARM оно тоже есть, но как-то оригинально не называется, и введено было, вроде, одновременно с HYP.
3. Виртуализация ввода-вывода
IOMMU (Input-Output Memory Mapping Unit) - узел, играющий ключевую роль в пробросе в вируталки видеокарт и прочих PCI-устройств (для проброса USB, к счастью, не требуется).
Есть он и у Intel, и у AMD, и у Zhaoxin (вот насчёт времён VIA не уверен). У Intel и Zhaoxin он называется "VT-d" (Virtualization Technologies for Directed I/O") и также совместим между ними двумя по командам, у AMD - "AMD-Vi", но в настройках прошивки хоста часто указывается просто как "IOMMU".
Ещё два важных расширения, которые почти всегда требуются гипервизорами - PAE (Physical Address Extensions) и NX (NoExecute). Первое - появилось, вроде, аж на втором пне и позволяет в 32-разрядном режиме системе видеть больше 4 ГБ ОЗУ и, подобно спектруму-128 или EMS, выбирать, какие 4 ГБ отображать каждому процессу, второе - помечать данные в памяти как исполняемые или нет, чтобы попытка исполнить не то через какое-нибудь переполнение обломалась с ошибкой.
1. Виртуализация исполнения
- VM8086 - с ним уже разобрались, умеет запускаться в защищённом режиме и виртуализировать DOS-окружения. Присутствует в ЦП любых вендоров, начиная с 386.
- Intel VT-x - появился в последних ревизиях четвёртых пней, умеет запускаться в 64-разрядном режиме. Изначально мог ускорять только защищённый режим.
- AMD-V, ранее SVM ("Secure Virtual Machines") - функциональный аналог VT-x, при этом только функциональный, т.е. сами команды у него совсем другие, и в гипервизорах его поддержку приходится реализовывать отдельно.
- Unrestricted guest - улучшение VT-x, реализующее реальный режим для vCPU и зависящее от EPT (об этом ниже). Появилось в микроархитектуре Westmere.
- VIA/Zhaoxin VT-x - аналог VT-x в процессорах VIA, появившийся в серии Nano, реализован совместимым с Intel VT-x по командам, как раз, чтобы не получилось, как с AMD-V, но хули толку, если строка вендора в CPUID у него отличается, а гипервизоры пугаются, когда не видят там строчку от Intel или AMD.
- HYP - название расширения аппаратной виртуализации архитектуры ARM, появившегося в ядре Cortex-A15 и использующего уровень выполнения EL2.
2. Виртуализация управления памятью
Поскольку управление виртуальной памятью подразумевало использование привилегированных инструкций, которые, как было сказано выше, хуёво ускорялись, в дополнение к VT-x и т.п. пришлось придумывать ещё т.н. вложенную трансляцию адресов (англ. second level address translation, SLAT).
У Intel это расширение называется "extended page tables" (EPT) и появилось то ли в Nehalem, то ли в Westmere; у Zhaoxin оно называется так же и по командам с Intel совместимо,
а вот у AMD - так же несовместимо, называется "rapid virtualization indexing" (RVI) и, в отличие от Intel, появилось раньше SVM, о чём повествуется в документе вмвари по ссылке из ОП-поста.
Да, у ARM оно тоже есть, но как-то оригинально не называется, и введено было, вроде, одновременно с HYP.
3. Виртуализация ввода-вывода
IOMMU (Input-Output Memory Mapping Unit) - узел, играющий ключевую роль в пробросе в вируталки видеокарт и прочих PCI-устройств (для проброса USB, к счастью, не требуется).
Есть он и у Intel, и у AMD, и у Zhaoxin (вот насчёт времён VIA не уверен). У Intel и Zhaoxin он называется "VT-d" (Virtualization Technologies for Directed I/O") и также совместим между ними двумя по командам, у AMD - "AMD-Vi", но в настройках прошивки хоста часто указывается просто как "IOMMU".
Ещё два важных расширения, которые почти всегда требуются гипервизорами - PAE (Physical Address Extensions) и NX (NoExecute). Первое - появилось, вроде, аж на втором пне и позволяет в 32-разрядном режиме системе видеть больше 4 ГБ ОЗУ и, подобно спектруму-128 или EMS, выбирать, какие 4 ГБ отображать каждому процессу, второе - помечать данные в памяти как исполняемые или нет, чтобы попытка исполнить не то через какое-нибудь переполнение обломалась с ошибкой.
Я подумал, но всё равно не понял. Когда тот же MSVPC типа перестаёт использовать бинарную трансляцию и начинает использовать VT-x/SVM, вроде, он ведёт себя так же, как тот же KVM - работает внутри обычной ОС, при этом взаимодействует с VT-x/SVM через модуль ядра для этой ОС. А по тем же, например, кольцам защиты отличий уже в этом случае нет.
Лучше бы тред по докеру сделал 🔆
Ух, вроде, с основной теорией закончили.
Надеюсь, вопросов, вроде "если виртуалка нужна, чтобы поставить в неё Win9x и играть в старые игры, зачем делать это в гипервизоре", теперь будет поменьше. Ответ именно на этот вопрос: потому что "динамическая перекомпиляция" или полная интерпретация тяжелее, чем trap-and-emulate, из-за чего эмуль приличного ретро-ПК требует вполне себе мощного хоста и может довести ноут до перегрева не хуже распоследнего AAA-тайтла. А поскольку задачи и железо у всех разные, я предлагаю подойти к вопросу более широко и вспомнить побольше различных решений виртуализации.
Надеюсь, вопросов, вроде "если виртуалка нужна, чтобы поставить в неё Win9x и играть в старые игры, зачем делать это в гипервизоре", теперь будет поменьше. Ответ именно на этот вопрос: потому что "динамическая перекомпиляция" или полная интерпретация тяжелее, чем trap-and-emulate, из-за чего эмуль приличного ретро-ПК требует вполне себе мощного хоста и может довести ноут до перегрева не хуже распоследнего AAA-тайтла. А поскольку задачи и железо у всех разные, я предлагаю подойти к вопросу более широко и вспомнить побольше различных решений виртуализации.
Нет проблем, вкидывай материал, тоже добавим в методичку.
Только тогда вкидывай, как я - не только про докер, но и про сам LXC, и про другие фронтенды к нему (LXD, Libvirt-LXC, подсистему systemd), и про то, например, в каких случаях лучше Docker Swarm, в каких случаях уже нужен k8s, а в каких хватит и k3s.
Как бы, у всех задачи для виртуализации разные, и, соответственно, инструменты всем подходят разные, поэтому я решил, что вспомнить их нужно побольше, для чего и возрождаю тут мозговой штурм.
У меня, например, большинство задач связаны с запуском в виртуалках именно винды и, например, анальным огораживанием её от ответственного исполнения на физике, т.е. их хостом винда по определению быть не может.
Так что мне даже Xen в режиме PV не подходит, хотя он способен даже, например, запустить фряху на линукс-хосте, чего контейнеры уже не умеют.
Зато для контейнеров мне приходит в голову от силы пара давно обкатанных сценариев, и микросервисы в них не входят - например, потому что виртуализацией я начинал заниматься в конце нулевых, когда ещё никакого докера не было.
Плюс, у меня зоопарк платформ на хостах. Какие-то - на ARM (и менять их на x86 - не особо вариант), какие-то - без VT-x, при этом достаточно мощные для виртуалок - но хотелось бы при этом не снижать их КПД, просто потому что в современных эмуляторах больше не поддерживают подход с меньшим оверхедом.
А теперь - ближе к делу, к частным случаям.
Во-первых, сначала вспомним, под какие платформы у нас есть вообще что-то, связанное с виртуальными машинами.
VirtualBox - II тип, работает под управлением WinNT/OSX/Linux/FreeBSD/Solaris, в зависимости от версии поддерживает как VT-x/SVM, так и trap-and-emulate, но есть куча нюансов (хорошей идеей будет их вспомнить и расписать, чтобы потенциальные пользователи понимали, с чем сталкиваются). Изначальный разработчик - никакие не Sun и не Oracle, а вполне себе Innotek, которая ещё адаптацией MSVPC под полуось (или полуоси к нему?) занималась.
VMWare Workstation/Player/Fusion - я бы охараткеризовал его "как VBox, только стабильнее и проприетарный" (а до недавнего времени был ещё и платный, так что к старым версиям ключ нужно искать на гитхабе). И да, под фряху с соляркой его нет.
Parallels... когда-то был и под винду, а ещё раньше назывался "twoOStwo" и "Serenity Virtual Station 2004", но вот набор эмулируемой периферии позволяет желать лучшего.
Hyper-V - I тип, и нет, это наследник нихуя не MS Virtual PC, а MS Virtual Server 2005, судя по набору функционала. Про Virtual Server можно сказать, что в нём есть драйвер для монтирования VHD на XP, про Virtual PC - чем отличаются версии (особенно, про малораспространённую версию 2011), чем отличается от Virtual Server, про версии для PowerPC-шных Маков...
Bochs - это чистой воды эмуль x86 (и, с недавнего времени, x86-64), который даже в динамическую перекомпиляцию особо не пытается, потому что предназначен для разработчиков ОС, но как дополнительный плюс, что у него куча портов (хотя и разной степени свежести). А, ещё у него паравиртуальный отладочный порт есть.
QEMU - тут вообще много можно рассказать: каких архитектуры помимо x86 эмулирует, на каких сам идёт, каких можно запускать ARM- и PowerPC-гостей (и какие machine type для этого нужны), про фронтенды (как UTM и Limbo), про кучу форков, чем его кроме KVM можно ускорять (старый kqemu, Xen, Intel HAXM, NetBSD NVMM, WHPX, Apple HVF).
Про KVM тоже можно рассказать, с чем ещё, кроме QEMU он работает - cros_vm, Clutterfish, Firecracker и т.д.
Про Xen - какие у него режимы и чем отличаются, что может запускать в режиме PV, а что - даже в роли dom0...
Ещё хорошие темы - как и для чего разные гнилые приложухи пытаются детектить, что они работают в виртуалке, как их можно попытаться наебать (и среди каких гипервизоров выбирать именно с учётом этого), почему наебать может всё равно не получиться.
Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
Во-первых, сначала вспомним, под какие платформы у нас есть вообще что-то, связанное с виртуальными машинами.
VirtualBox - II тип, работает под управлением WinNT/OSX/Linux/FreeBSD/Solaris, в зависимости от версии поддерживает как VT-x/SVM, так и trap-and-emulate, но есть куча нюансов (хорошей идеей будет их вспомнить и расписать, чтобы потенциальные пользователи понимали, с чем сталкиваются). Изначальный разработчик - никакие не Sun и не Oracle, а вполне себе Innotek, которая ещё адаптацией MSVPC под полуось (или полуоси к нему?) занималась.
VMWare Workstation/Player/Fusion - я бы охараткеризовал его "как VBox, только стабильнее и проприетарный" (а до недавнего времени был ещё и платный, так что к старым версиям ключ нужно искать на гитхабе). И да, под фряху с соляркой его нет.
Parallels... когда-то был и под винду, а ещё раньше назывался "twoOStwo" и "Serenity Virtual Station 2004", но вот набор эмулируемой периферии позволяет желать лучшего.
Hyper-V - I тип, и нет, это наследник нихуя не MS Virtual PC, а MS Virtual Server 2005, судя по набору функционала. Про Virtual Server можно сказать, что в нём есть драйвер для монтирования VHD на XP, про Virtual PC - чем отличаются версии (особенно, про малораспространённую версию 2011), чем отличается от Virtual Server, про версии для PowerPC-шных Маков...
Bochs - это чистой воды эмуль x86 (и, с недавнего времени, x86-64), который даже в динамическую перекомпиляцию особо не пытается, потому что предназначен для разработчиков ОС, но как дополнительный плюс, что у него куча портов (хотя и разной степени свежести). А, ещё у него паравиртуальный отладочный порт есть.
QEMU - тут вообще много можно рассказать: каких архитектуры помимо x86 эмулирует, на каких сам идёт, каких можно запускать ARM- и PowerPC-гостей (и какие machine type для этого нужны), про фронтенды (как UTM и Limbo), про кучу форков, чем его кроме KVM можно ускорять (старый kqemu, Xen, Intel HAXM, NetBSD NVMM, WHPX, Apple HVF).
Про KVM тоже можно рассказать, с чем ещё, кроме QEMU он работает - cros_vm, Clutterfish, Firecracker и т.д.
Про Xen - какие у него режимы и чем отличаются, что может запускать в режиме PV, а что - даже в роли dom0...
Ещё хорошие темы - как и для чего разные гнилые приложухи пытаются детектить, что они работают в виртуалке, как их можно попытаться наебать (и среди каких гипервизоров выбирать именно с учётом этого), почему наебать может всё равно не получиться.
Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
>Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
В смысле, как минимум, точно не KVM и, уж тем более, не Hyper-V.
Я ж говорю, тем много, и для тредов линуксового или даунгрейдерского они не совсем подходят.
Deepseek это одним запросом расписывает
Здравствуйте, какие инструменты подойдут лучше для:
1) создания и хранения отдельной интернет личности, со своими аккаунтами и прочим. изначально я думал что вообще будет достаточно просто профиля в браузере, но потом начал сомневаться (даже нормисные сайты уже в открытую профилируют с помощью фингерпринтинга)
2) проверки\использования софта из сомнительных источников. как организовать передачу файлов с хоста? смб диск шарить, встроенные функции с общей папкой, монтировать образ диска и тд
1) создания и хранения отдельной интернет личности, со своими аккаунтами и прочим. изначально я думал что вообще будет достаточно просто профиля в браузере, но потом начал сомневаться (даже нормисные сайты уже в открытую профилируют с помощью фингерпринтинга)
2) проверки\использования софта из сомнительных источников. как организовать передачу файлов с хоста? смб диск шарить, встроенные функции с общей папкой, монтировать образ диска и тд
Хм...
>1) создания и хранения отдельной интернет личности, со своими аккаунтами и прочим. изначально я думал что вообще будет достаточно просто профиля в браузере, но потом начал сомневаться (даже нормисные сайты уже в открытую профилируют с помощью фингерпринтинга)
Да, отдельного профиля в браузерах действительно будет маловато, изоляция нужна будет более серьёзная, плюс прокси всякие. Её можно попытаться намутить самому, но могу сразу порекомендовать готовое решение, которое, возможно, будет оверкилл, и при этом точно будет релейтед.
QubesOS - десктопный дистрибутив Fedora GNU/Linux/Xen, судя по отзывам - даже освоивший какие-то Xen'овские уникальные фичи. Признан различными практикующими ИБ-специалистами и другими энтузиастами. Вообще, мне её посоветовали, когда я попросил дистр Xen, подходящий для вката в него.
Также, к нему стоит добавить Whonix - более серьёзный аналог TAILS, являющийся виртуальным эпплаенсом, в качестве самодостаточного хоста как раз поддерживающий преимущественно Qубики.
Конечно, придётся вспоминать, что TAILS и Whonix - это эпплаенсы Тора, и соответствующие нюансы, вроде запрета на постинг здесь или пробивания ТСПУ тебе придётся разгребать самому. С ТСПУ, возможно, помогут в соседнем треде.
Вообще, для обхода фингерпринтинга есть ещё более готовые решения - специальные браузеры под винду, скорее всего - пилятся специально для ботоводов.
Их даже Овер рекламировал. Но, вопервых, они только под винду и только под распоследнюю, а во-вторых - платные. А вообще, раз мы заговорили про ботоводов - читая этот текст, ты автоматически даёшь присягу, что таковым не являешься.
>2) проверки\использования софта из сомнительных источников.
Да, гипервизоры для этого подходят идеально, это именно одно из направлений, где они активно используются. Так или иначе аппаратная виртуализация используется Касперским для усиления защиты (но со всеми решениями для запуска ВМ конфликтует) и нашим "любимым" ЗаSHITником Виндоуз (он вообще с гипервизорами интегрироваться путается, с той же ВМВарью или Гиперв). А есть вообще решения, как PT Sandbox, серьёзные и дорогие. Сайты вроде ВирусТотала, скорее всего, что-то подобное и используют.
Правда, сейчас вирусописатели про виртуализацию прочухали, и вирусы теперь больно умные пошли, которые могут попытаться задетектить не только отладчик, но и гипервизор, и, если задетектят... кто-то просто изменит поведение или самоликвидируется, а кто-то - может попробовать заразить гипервизор, хост и другие виртуалки, и у некоторых вирусов это успешно получается. Наебать их тоже успешно получается, но есть и методики детекта, которые обойти будет трудно, например - тайминг-атака (приложение внутри ВМ может попытаться замерить время исполнения привилегированной команды ЦП, и если оно больше, чем на физике - значит, идёт интроспекция (перехват этой команды гипервизором), и приложение в виртуалке. Есть и ещё методики, более простые в реализации, до чего-то я даже сам допёр. Например, оптический привод - есть он есть, то у любой современной физической пекарни они пишущий, а у виртуалки - ни разу такого не видел. Да, старый физический комп вызовет ложное срабатывание, но некоторые софтины сразу предполагают запуск в виртуалке, даже если их просто запустят, скажем, на Windows XP - и уже не разбираются, правда это виртуалка или очень старая физика. Или, если у виртуалки ОЗУ не кратна гигабайту (или меньше гигабайта). Подозрительно малый аптайм там...
>как организовать передачу файлов с хоста?
А, вот этот вопрос провтыкал.(
>смб диск шарить
Да, сетевая шара (не обязательно по SMB, зависит от гостевой ОС... хотя в случае винды лучше именно SMB) - почти единственный вариант.
>встроенные функции с общей папкой
А вот про это сразу забудь. Всякие VMWare Tools/VBox Guest Additions/QEMU-GA и прочее такое для твоей задачи сносить обязательно, и более того - прописывать в конфиг виртуалки директивы, отключающие хаки со стороны гипервизора, позволяющие этим штукам работать.
Вообще, нестандартных конфигурационыых директив придётся прописывать много, для KVM и VMWare есть гайды (правда, они разрозненные, поэтому хорошо бы их ИТТ процитировать). Xen тоже так умеет (но это я понял после полного чтения man-страницы по конфигу виртуалки для xl), и немного даже ритуалбокс (но уже плохо, и его для этого надо патчить).
Есть куча моментов, которые характерны почти для всех гипервизоров, но вышеупомянутые хотя бы позволяют их настраивать:
- CPUID (бит гипервизора, иногда - строчка вендора и флаги/MSR конкретной модели - их можно менять в QEMU);
- SMBIOS (строки версий BIOS, вендора/модели/версии/серийника материнской платы/корпуса и т.д., меняетя или пробрасывается с хоста во всём вышеперечисленном);
- SCSI-атрибуты накопителей (тоже производитель/модель/серийник/WWN диска, точно можно менять в QEMU и VBox).
TL;DR: для такой задачи, если готовые решения слишком дорахие и проприетарные, то выбор гипервизоров сильно сокращается до:
- VMWare
- QEMU/KVM
- QEMU/Xen в режиме HVM
и конфиг ВМ в любом случае придётся дорабатывать напильником - можно уже начинать гуглить, как.
Пожалуйста, цитируй, что он тебе написал. Что он расписал это так же подробно, и ты уверен, что он ничего не напутал. Вообще, по идее, чтобы он лучше понимал, нужно ему такие треды скармливать (правда, двачу это может не понравиться), но при этом всё равно нет никакой гарантии, что поймёт.
Нейронки - вещь, конечно, удобная, но сомнительная.
Да, удобно, конечно, что в поисковик теперь можно тупо вводить вопросы, а не совокупность ключевых слов под синтаксисом уточнения их веса, и ответ от нейросети не потребует даже оплаты или доп. запроса. НО! "Доверяй, но проверяй" - это точно про нейросети.
http://tv-games.ru/emulator/open/pcem.html
>Эмулятор поддерживает оборудование, начиная от самых первых классических моделей IBM PC, и заканчивая чипсетами Socket 8, Slot 1, то есть Pentium MMX, Pro и II, до 500 МГц. Впрочем, новое железо эмулируется явно с запасом. Полноценной игры на таких частотах вряд ли добиться, особенно явно это будет отражаться на звуке.
>Более реально запускать конфигурацию Pentium MMX 230-250 МГц с Windows 98 на процессорах от Intel 5-го поколения, но i7 всё же предпочтительнее. Pentium II с частотой 450 МГц пока недостижим даже не топовых Core i9 и Ryzen. Это при том, что для Пентиумов доступна динамическая рекомпиляция. Так же сообщается о приемлемой эмуляции с полноценным звуком Pentium 75 МГц на AMD Ryzen 7 3700X.
Вот поэтому для виртуализации ретро-ПК всё-таки VT-x/SVM были бы очень кстати... или хотя бы реализация подхода trap-and-emulate - всё равно тот же PCem только под x86 пишется.
Но, к сожалению, про trap-and-emulate забыли совсем все, в том числе - разработчики опенсорсных решений. Не весь же ретро-софт в реальном режиме или нулевом кольце исполняется.
>Эмулятор поддерживает оборудование, начиная от самых первых классических моделей IBM PC, и заканчивая чипсетами Socket 8, Slot 1, то есть Pentium MMX, Pro и II, до 500 МГц. Впрочем, новое железо эмулируется явно с запасом. Полноценной игры на таких частотах вряд ли добиться, особенно явно это будет отражаться на звуке.
>Более реально запускать конфигурацию Pentium MMX 230-250 МГц с Windows 98 на процессорах от Intel 5-го поколения, но i7 всё же предпочтительнее. Pentium II с частотой 450 МГц пока недостижим даже не топовых Core i9 и Ryzen. Это при том, что для Пентиумов доступна динамическая рекомпиляция. Так же сообщается о приемлемой эмуляции с полноценным звуком Pentium 75 МГц на AMD Ryzen 7 3700X.
Вот поэтому для виртуализации ретро-ПК всё-таки VT-x/SVM были бы очень кстати... или хотя бы реализация подхода trap-and-emulate - всё равно тот же PCem только под x86 пишется.
Но, к сожалению, про trap-and-emulate забыли совсем все, в том числе - разработчики опенсорсных решений. Не весь же ретро-софт в реальном режиме или нулевом кольце исполняется.
Я-то думал, что условных FX-8320e или хотя бы топового Kaby Lake (десктопного, с 20-сантиметровой башней 3,5-кратного запаса по TDP) для эмуляции второпня уже хватит.
Но, походу, от сборки 370-775 конфигов для ретро-софта виртуализация нас избавить ещё не готова. Или, как минимум, всё равно нужно будет доставать на Авито какую-нибудь хорошую карточку на conventional PCI для проброса (потому что слот PCIe x16 будет занят актуальной видеокартой, проброшенной в дейлидрайверную виртуалку).
А задачи у меня всё те же, что были во время номерных тредов и переноса обсуждения виртуализации в тред по линуксу:
- запуск окружения на 9x/XP с минимумом аутентичного железа;
- домашний мини-VDI (потому что винда слишком глючная для запуска на физике да и линукс только из-за KVM терпят, возлагая большие надежды на солярку);
- всё это - с максимально возможным КПД и доступом вирталок к нормальному GPU-ускорению;
- конечно же, желательно - обеспечиваемому одной десктопной карточкой.
- запуск окружения на 9x/XP с минимумом аутентичного железа;
- домашний мини-VDI (потому что винда слишком глючная для запуска на физике да и линукс только из-за KVM терпят, возлагая большие надежды на солярку);
- всё это - с максимально возможным КПД и доступом вирталок к нормальному GPU-ускорению;
- конечно же, желательно - обеспечиваемому одной десктопной карточкой.
Ок, что эта настройка Vbox делает на самом деле, когда в винде есть установленный Hyper-V
Выпадающий список сверху - меняет виртуализацию таймингов: как в Hyper-V, как в KVM, как в просто произвольном гипервизоре ("Минимальный", в зависимости от указанной в настройка гостевой ОС ("Совместимый") или без виртуализации таймингов. Переключать его в KVM для подключения сетевой карты VirtIO - не обязательно. Очень неочевидный параметр, да. Пока не увидел в мануале https://www.virtualbox.org/manual/topics/working-with-vms.html#gimproviders - думал, что его выбор зависит от ОС хоста.
Флажок снизу - вручную включает использование аппаратной вложенной виртуальной памяти (Intel EPT/AMD RVI).
Кстати, про коробокс интересный факт.
Имеются сведения, что он заимствует ~30% кода QEMU...
В отличие от Proxmox VE и его многочисленных (но это не точно) функциональных аналогов, скорее всего, речь идёт про всякие подсистемы вроде используемого BIOS и когда эмулируемой периферии.
С другой стороны, когда-то у у коробокса был и серверный вариант, может даже - в виде решения "I типа" (в Википедии есть упоминания некоего "Virtual Iron")... а сейчас серверное решение виртуализации от Oracle - это тупо Oracle Linux с KVM.
Похоже, что в Oracle сами осознают глючность коробокса... зачем тогда они до сих пор его поддерживают, интересно.
TL;DR: Верхнюю опцию можно не трогать, если не критично для гостя, нижнюю - предпочтительно включать, поскольку улучшает производительность. Но только если с ней работает, поскольку это зависит от свежести ЦП.
Имеются сведения, что он заимствует ~30% кода QEMU...
В отличие от Proxmox VE и его многочисленных (но это не точно) функциональных аналогов, скорее всего, речь идёт про всякие подсистемы вроде используемого BIOS и когда эмулируемой периферии.
С другой стороны, когда-то у у коробокса был и серверный вариант, может даже - в виде решения "I типа" (в Википедии есть упоминания некоего "Virtual Iron")... а сейчас серверное решение виртуализации от Oracle - это тупо Oracle Linux с KVM.
Похоже, что в Oracle сами осознают глючность коробокса... зачем тогда они до сих пор его поддерживают, интересно.
TL;DR: Верхнюю опцию можно не трогать, если не критично для гостя, нижнюю - предпочтительно включать, поскольку улучшает производительность. Но только если с ней работает, поскольку это зависит от свежести ЦП.
Виртуалбокс это жопа, аптайм максимум месяц был и падал. Вмваре 400 дней аптайм перевалил гость венда7. И там и там хосты венда 10. Думайте.
Даже интересно стало, какие задачи были, с таким аптаймом и десктопными ОС?)
Просто интересуюсь, к M$ отношения не имею, честно-пречестно. В смысле, сдавал MTA по паре направлений, но работать к ним идти точно в рот ебал.
Старый софт асутп
Тогда сразу понятно.
Это, конечно, легче, чем у меня - никакие GPU пробрасывать не надо, наверное, достаточно пары USB/COM-портов.)
Хм, а насколько старый? Это он на 7 шёл, или внутри 7 ещё какие-то костыли были?
Образ снят со старого мёртвого системника и просто запущен на современном железе под виртуалкой. Из настроек сетевой мост добавлен и там usb ключ ещё проброшен.
Это вы ещё довольно легко отделались... не считая, что 7 не сильно ожидала быть включенной на другом железе. Но и с этим, как я понимаю, повезло.
Осенью 2021 дело было. По работе практике в техникуме читал, что у клиента интегратор отечественные ПЛК забраковал - потому что управляющий софт у них был только под QNX - а QNX - поддерживала только 486, которые уже непонятно, где покупать.
Тогда даже я не вспомнил, что QNX, вообще-то, живее всех живых и, вроде, даже имеет локализованно-сертифицированные варианты...
https://ru.wikipedia.org/wiki/QNX
>ЗОСРВ «Нейтрино» КПДА.10964-01
>ЗОСРВ «Нейтрино-Э» КПДА.10965-01
>ЗОСРВ «QNX» КПДА.00002-01
Да, всё так. Но мысль "как так, в двух крупных-долгоживущих-серьёзных интеграторах никто не вспомнил...?" всё равно появлялась - правда, про, например Zhaoxin и Vortex86, из которых как минимум последний именно в таких кейсах часто используется.
А вот это напишу вне спойлера, потому что у QNX сейчас, вроде, и встроенный гипервизор есть, и ARM-версия, и её даже можно на малинках запускать... и я вполне допускаю, что штатный гипервизор под ARM портировать уже успели.
Правда, образ официально достать трудно но, вроде, легче, чем у той же, например, QP ОС. А с этим кто-то здесь опыт имел?
Из более недавнего и реального: тут 10 переносил в Workstation 15.5.7 (первая версия с поддержкой WHPX) - я для неё и SMBIOS пробросил, и MAC прописал, и ещё что-то сделал, но заново искать драйвера она всё равно начала.
ЧСХ, OEM-активация не слетела (!!). Хотя, вроде, кстати, ACPI-таблицы я не пробрасывал (что VMWS, вроде, и не умел никогда).
Заодно узнал, что создание qemu-img не умеет конвертировать в vmdk (даже того варианта, который использует Workstation) - а вот коробокс с этим справился вполне - после него (и только после него) варя подцепить образ смогла.
>Заодно узнал, что qemu-img не умеет конвертировать в vmdk (даже того варианта, который использует Workstation)
Быстрофикс
>штатный гипервизор под ARM портировать уже успели
https://qnx.software/content/dam/qnx-xwalk/pdf/product-briefs/qnx-hypervisor-8-product-brief.pdf
>64-bit support for the latest ARMv8 and x86-64 SoCs
Всё так.
Хоть доки у них доступны без регистрации (которая сломана).
https://github.com/sickcodes/Docker-OSX
>Эпплаенс хакинтоша на базе Docker и KVM
Звучит хайпово как годнота...
Потестить сейчас не смогу, так что, аноны, налетайте.
>Эпплаенс хакинтоша на базе Docker и KVM
Звучит хайпово как годнота...
Потестить сейчас не смогу, так что, аноны, налетайте.
Где то видел докеры виртуалки венды и дройда
Android только x86 поддерживает? Если этот образ с ARM совместим - есть нехилая вероятность, что там Anbox Waydroid (и в случае Linux-хоста лучше всего именно так).
А вообще, есть одна тема, которую я тоже планировал в этом треде обсудить (если, конечно, есть, что обсуждать, а не один раз нормально чекнуть и (публично) записать).
"VMOS" и ещё несколько похожих приложений, естественно, со своими особенностями... первое, что вспоминается - версия системы во вложенном окружении и возможность рутования. Короче, Android-приложения, реализующие контейнер с отдельным экземпляром его же, например, для задач песочницы, но посерьёзнее, чем Island какой-нибудь, который я уже особо сильно релейтедом не считаю даже здесь, хотя здесь релейтедом считается много чего.
Раз альтернативные архитектуры здесь релейтед - вопрос к владельцам маков на PowerPC: на G4-G5 аппаратная виртуализация есть? Или только на мейнфреймах с PowerVM?
http://sanbarrow.com/moa.html
Смотрите, что нашёл. Сайт полуживой, но для понимания сути (а то и восстановления сборки) данныз достаточно. С PE 2.0-10.0.22000 и Workstation до 10.0.7 включительно насколько легко будет повторить?
Смотрите, что нашёл. Сайт полуживой, но для понимания сути (а то и восстановления сборки) данныз достаточно. С PE 2.0-10.0.22000 и Workstation до 10.0.7 включительно насколько легко будет повторить?
А теперь - переходим к интересному.
Вот, с чего начались гипервизоры на x86!
Виртуализировали они часто просто DOS-сеансы - но делали это уже с помощью аппаратной виртуализации, образца 386.
На пике приводится небольшое сравнение решений данного класса.
Вот, с чего начались гипервизоры на x86!
Виртуализировали они часто просто DOS-сеансы - но делали это уже с помощью аппаратной виртуализации, образца 386.
На пике приводится небольшое сравнение решений данного класса.
Вот на этом моменте я разочаровался во FreeDOS.
В ней даже "PC-DOS Shell" (тот, из которого первые хоткеи винды, вроде Alt+Tab, пошли) - и тот крашил ядро.
А ещё, оказывается, от майковского EMM386 зависит ф-ционал, например, пакета драйверов USBDOS - хорошо хоть, именно в этом случае - нестрого зависит.
Так что, походу, там в принципе с настоящими мультитаскерами плохо, а поддержка VM86 лишь на том уровне, на котором она нужна EMM.
Ну да ничего - есть же HX и вложенный досбокс (либо его форк, даже со специальной сборкой под HX) - под его франкенштейновым ядром хоть 3.1 и 95 запускается.
А есть совсем другой вариант - хоть EMM386 многозадачности и не даёт, но любая программная реализация EMS - она ведь эмулирует железку, для и так достаточно низкоуровневой ОСи => без VM86 она вряд ли может.
И это наводит на более эффективный вариант - ставить фриддос внутрь того же Workstation 8-10, а затем как можно раньше запускать в виртуалке XMM, EMM и подсистему энергосбережения (вроде DOSIDLE, FDAPM или встроенной в ядро) - тогда окружение виртуалки переезжает в V86, из-за чего, как в принципе с кодом 3 кольца, варя так же начинает транслировать его и задействует для этого V86 хоста.
Один экземпляр под веб-сервер Майка Брутмана, второй - под FTP того же автора, общее хранилище для них через XFS286, а раздавать его с соседней виртуалки с легковесными никсами (ну, или поставить на хосте SFU. Офигеть, уже сценарий "консолидированных виртуальных серверов", и всё это - без VT-x!
Что ж, вот теперь варианты стека ретро-виртуализации приходят в голову "сами собой"...
В ней даже "PC-DOS Shell" (тот, из которого первые хоткеи винды, вроде Alt+Tab, пошли) - и тот крашил ядро.
А ещё, оказывается, от майковского EMM386 зависит ф-ционал, например, пакета драйверов USBDOS - хорошо хоть, именно в этом случае - нестрого зависит.
Так что, походу, там в принципе с настоящими мультитаскерами плохо, а поддержка VM86 лишь на том уровне, на котором она нужна EMM.
Ну да ничего - есть же HX и вложенный досбокс (либо его форк, даже со специальной сборкой под HX) - под его франкенштейновым ядром хоть 3.1 и 95 запускается.
А есть совсем другой вариант - хоть EMM386 многозадачности и не даёт, но любая программная реализация EMS - она ведь эмулирует железку, для и так достаточно низкоуровневой ОСи => без VM86 она вряд ли может.
И это наводит на более эффективный вариант - ставить фриддос внутрь того же Workstation 8-10, а затем как можно раньше запускать в виртуалке XMM, EMM и подсистему энергосбережения (вроде DOSIDLE, FDAPM или встроенной в ядро) - тогда окружение виртуалки переезжает в V86, из-за чего, как в принципе с кодом 3 кольца, варя так же начинает транслировать его и задействует для этого V86 хоста.
Один экземпляр под веб-сервер Майка Брутмана, второй - под FTP того же автора, общее хранилище для них через XFS286, а раздавать его с соседней виртуалки с легковесными никсами (ну, или поставить на хосте SFU. Офигеть, уже сценарий "консолидированных виртуальных серверов", и всё это - без VT-x!
Что ж, вот теперь варианты стека ретро-виртуализации приходят в голову "сами собой"...
Можно ещё рассмотреть для не очень требовательных приложений вариант с притаскиванием NTVDM (и WoW) в WinPE 1.6 - с относительным максимумом нюансов, конечно, но большей вероятностью запуститься в роли хоста, чем 9x и, уж тем более, полуось.
Тут и наработки MOA по ссылке выше могут пригодиться.)
Какой смысл ставить Win98 на DOSBox, если уже есть PCEm настроеный на P166 MMX с той же 98-й виндой?
Такой, что динамическая перекомпиляция медленнее и прожорливее, чем trap-and-emulate, и уж тем более, чем современная аппаратная виртуализация. А о эмуляции методом полной интерпретации и говорить нечего.
Поэтому, Win98 по-любому нужно ставить в гипервизор.
А если хост не имеет VT-x/AMD-V - там спасает только MSVPC, старые Workstation с коробоксом и, если удастся найти ключ, виндовый Parallels.
А даже если и имеет - в апстриме QEMU до сих пор нихуя нет нормальной паравиртуальной видеокарты, которая бы поддерживала ретро-ОС (тот же qemu-3dfx в апстриме нет и вряд ли будет).
Но, даже так, PCem (и большинство форков DOSBox, за исключением DOSBox-X) эту же 3Dfx умеет только низкоуровнево эмлировать, а DOSBox-X - с меньшими накладными расходами паравиртуализировать её с помощью патченой glide2x.dll (?) и dgVoodoo на хосте.
А так, PCem - лютая годнота (и был таковой до продакшн-готовности, пока DOSBox-X ещё не было.
Т.е. 98-я будет лучше работать в DOSBox-X? В смысле быстрее?
Нет. В целом она лучше всего будет работать в QEMU/KVM, VMWare ESXi, в зависимости от версии, VMWare Workstation, HVM-режиме Xen. Т.е. гипервизорах, которые используют VT-x/AMD-V.
Но проблема в том, что паравиртуальные видеокарты у этих гипервизоров (драйверы, взаимодействующие с гипервизором и реализующие трансляцию вызовов графических API на видеокарту хоста) - либо напрочь отсутствуют, либо в зачаточном состоянии, либо ограничены по функционалу, и, наконец, Win98 точно не поддерживают:
В QEMU/KVM и HVM-режиме Xen есть QXL, но он поддерживает только 2D-ускорение и только на XP и новее.
VirtIO-GPU и его аналоги я вообще не рассматриваю, потому что он "в зачаточном состоянии":
- рассчитан, в основном, на GNU/Linux;
- версия для Windows устанавливается как "display-only driver", т.е. неускоренный, поддерживает 8.1+, и, скорее всего, именно она приводила к постоянному вылету виндовых ВМ у меня (как переставил со всеми драйверами без этого - сразу вылеты прекратились).
С ESXi похоже. Он, конечно, реализует драйвер, работающий по принципу такового из Workstation, но есть нюансы:
- На XP - только 2D, 3D есть только начиная с некоей версии новее. Это относится даже к ESXi 5.5 (у которого ещё вебки нет, поэтому нужно заходить на него через фирменное локальное приложение).
- При отсутствии установленного VIB для видеокарты хоста, тупо переключается на программную отрисовку: исполняет графические функции ВМ с помощью ЦП), но ВМ об этом не знает.
- Соответственно, для десктопных видеокарт этих VIB не существует. Есть, конечно, призрачная надежда обнаружить определённую микроархитектуру, которая использовалась и в десктопных видеокартах, и в серверных, для которых есть VIB - но затем, скорее всего, придётся патчить, в лучшем случае, метаданные этого VIB, в худшем - патчить VBIOS, что, возможно, потребует сравнения двух дампов с IDA. Но работы будет много, при этом вероятность успеха - NaN процентов => это вариант только для тех профи ассемблера, которые с IDA обращаются даже на на "ты", а на "moya sladkaya :3".
VIB - это формат пакетов для ESXi, в данном случае имелся в виду пакет видеодрайвера, который ESXi нужен так же, как любому хосту Workstation. Если интересно, могу рассказать, как у VMWare "пакетная система" устроена, и как этот VIB можно установить вручную, даже если твоя инсталляция ESXi вдруг перестала опознавать загрузочный FAT-раздел, стала симлинкать /bootbank в /tmp, а сам этот раздел ты видишь только по пути /vmfs/volumes/метка_тома.
А серверные видеокарты позволяют варианты и поинтереснее - вплоть до того же проброса через IOMMU, но уже во много ВМ сразу одновременно. И, конечно, в этом случае гостевой ВМ тоже нужны особые драйвера, но уже от вендора серверной видеокарты, поддерживающие только, в лучшем случае, 10+ и Linux, не говоря уже, что иногда простым смертным частникам и не скачать, а иногда у этих драйверов бывают ещё и срочные лицензии - эту тему же для сурьёзного бизнеса сделали, с его VDI и прочими нейронками.
Остаётся только VMWare Workstation, но я не уверен, что в последних версиях поддержку 98 не убрали, или что она вообще была, потмоу что даже в коробоксе-
Стоп, так и есть. Там же флажок "Enable 3D Support" в настройках ВМ недоступен, если ставить что-то, старее то ли XP, то ли 2K.
Про VirtualBox я даже забыл, потому что давно не рассматриваю его всерьёз, т.к. он достаточно кривой. Единственный его плюс - это что он (поддерживает и винду (в зависимости от версии - и XP), и Linux, и даже более экзотические н- и не только никсы && опенсорсный). Конечно, и опенсорсный-то он условно: интересные фичи вынесены в фриварный-для-дома Extension Pack... который можно просто не ставить. Пару примеров кривизны могу привести, но, даже если они тебя не убедят, для меня они критичны - в том числе именно из-за того, что они затрагивают ретро-ОС.
Так что, если отбросить принципы и требования ИБ - и пиратский Workstation сойдёт, на гитхаб-гисте паст с ключами гуляет много.
Не говоря уже о том, что с версии 6.1 видеодрайвер коробокса на XP и старее работать перестал, а под 9x гостевых дополнений вообще никогда не было.
Что поддерживает эмуляцию хоть какого-то 3D-ускорителя, совместимого с 9x - это DOSBox-X и PCem... ах да, ещё последние версии Bochs.
При этом, PCem и Bochs умеют его только полностью эмулировать, как устройство: в ВМ ставится драйвер на настоящую Voodoo, а в эмуляторе отдельный поток занимается тем, что симулирует её поведение... и обсчитывает графику в рамках него же, на ЦП, а не на видеокарте хоста.
А DOSBox-X поддерживает вариант с меньшими накладными расходами: в ВМ ставятся патченые библиотеки Glide (а драйвер, вроде, вообще не нужен), взаимодействующие с эмулятором (собственно, примерно это и называют паравиртуализацией), а на хост ставится приложение, вроде dgVoodoo, транслирующее вызовы Glide в вызовы поддерживаемых графических API (DX/OGL)... которое, в общем-то, в первую очередь, рассчитано просто на обеспечение совместимости со старыми играми именно в части Glide при их запуске на физике - а DOSBox-X рассчитан прямо на взаимодействие с ним. Вангую, что он и ведёт себя для этого как такое же Glide-совместимое приложение, т.е. на физическом старом компе с Voodoo - он будет общаться с физической картой через её штатные драйверы.
Поэтому, если ты собираешься в этой 9x играть - DOSBox-X обеспечит минимальные накладные расходы (и, как следствие, повышение производительности) при, как раз, обсчёте графики этих игр. Но не всего остального - остальное он эмулирует, хорошо хоть - что при эмуляции ЦП задействует динамическую перекомпиляцию, - которая, хотя и быстрее полной эмуляции (интерпретации), но медленнее классической бинарной трансляции, как в
>MSVPC, старые Workstation с коробоксом и, если удастся найти ключ, виндовый Parallels
которую я для называю "trap-and-emulate" для краткости, даже там, где гипервизор использует другие подходы к программному ускорению.
Поэтому, чтобы корректно эмулировать в DOSBox-X или PCem что-то существенное - тебе понадобится достаточно мощный хост с хорошим охладом.
На ноуте с Arrandale или Ivy Birdge стабильный максимум - это 486DX2 с S3 Virge DX... или, возможно, этой самой паравиртуальной Voodoo. При попытке эмуляции чего-то мощнее - как минимум, будут проблемы со звуком в ВМ, а в худшем случае - в какой-то момент просто сработает защита хоста от перегрева.
При эмуляции x86 на ARM дела обстоят ещё более грустно:
На малинке стабильный максимум в DOSBox-X - это 386 @25 МГц, или просто cycles=8100 и cputype=386. Но хостом у меня в этом случае была RISC OS, на которую я надеялся, как на ОС легковеснее всяких юниксов, - но там могли быть потери производительности в связи с отсутствием поддержки каких-то расширений системы команд хоста, потому что скорость в районе мегабита при запуске тестов через Ethernet со скоростью гигабита - "это как вообще понимать?".
На моём хромбуке (Lenovo 300e 1st Gen) на MT8173C на линуксе - тоже 386, при этом максимальное число циклов было где-то 12000, но здесь его можно не фиксировать: просто поставить cputype=386. И да, во время установки 95 была существенная вероятность зависания по чипсетной защите.
Что же до смартфонов-хостов... Мне даже на Mi A1 так и не удалось добиться нормальной эмуляции SB на сборке досбокса из F-Droid, а какие-то звуковые устройства там просто отключены на этапе компиляции, поэтому из звука я оставил только GUS (который мне негде было использовать), и, вроде, даже спикер выключил. А может, вообще, в конце концов эмуляцию звука выключил в принципе (всю подсистему), потому что на последних тестах производительность стала на порядок выше малинки и хромбука, и вполне возможно, что именно поэтому.
Так что Limbo x86 Emulator, а равно и любые другие сборки qemu-system-i386, я на телефонах гонять больше даже не пытаюсь, максимум - этот самый досбокс.
Если попросить эмулятор пытаться эмулировать что-то лучше "стабильного максимума" - он, конечно, работать будет, но, наоборот, очень медленно: представь себе процесс установки 95 на 386-486, почему-то даунклокнувшийся до уровня какого-нибудь 286 @12 МГц, и то, в самом лучшем случае...
>Что поддерживает эмуляцию хоть какого-то 3D-ускорителя, совместимого с 9x - это DOSBox-X и PCem... ах да, ещё последние версии Bochs.
Но самый быстрый реализуемый в них метод эмуляции ЦП - это динамическая перекомпиляция, которая, как я уже писал,
>хотя и быстрее полной эмуляции (интерпретации), но медленнее [и тежелее] классической бинарной трансляции [trap-and-emulate].
Конечно, есть форк QEMU под названием "qemu-3dfx", вроде, даже поддерживающий KVM, а от того же автора есть наработки и под коробокс с варей (настольной)... но, сейчас их надо ставить из исходников, что сможет сделать не каждый "пауэр юзер" - даже тупо правильно запустить ./configure и make/make install, в среде, в которой он отработал бы без ошибок.
Также, на binary-based дистре с пакетным менеджером - мешать софт, установленный из нативных пакетов, с софтом, установленным через git clone и make install - иногда действительно является плохой идеей..
Поэтому, например, pip в дебиане или фряхе отказывается работать снаружи venv - библиотеки нужные поставляются через нативный пакетный менеджер, а если pip возьмётся их ставить, то нативный ПМ об этом не узнает, но в каких-то случаях (например, зависимость другого пакета) может попытаться обновить его сам, и будут конфликты.
И я что-то не верю, что наработки проекта qemu-3dfx примут в апстрим - основными пользователями QEMU являются суровые девопсы, которые используют QEMU/KVM как бесплатно-безопасную замену ESXi, и им эмуляция 3Dfx, получается, как правило, нинужна.
Динамическая перекомпиляция - она скорее для случаев эмуляции одной архитектуры на другой: например, тот же Limbo PC Emulator, который, как правило, запускают на ARM-устройствах, или, наоборот, Microsoft Device Emulator, под который, в отличие от x86-сборок WinCE, загружаемых LoadCEPC.exe, не надо искать особые сборки приложений, потому что он ARM эмулирует.
Или тот же PowerPC: MSVPC для MacOS 9 или NTVDM в NT4 для PowerPC.
Вот в таких случаях - ничего лучше динамической перекомпиляции нет.
А trap-and-emulate ориентируется на то, что как ВМ, так и хост, на x86 (причём 32-рязрадном), поэтому непривилегированные инструкции (большая часть кода на 3 кольце защиты) гостевой ОС гипервизор может просто вызывать как свои собственные, а в случае хоста другой архитектуры так уже не получится.
Поэтому, наверное, DOSBox, Bochs и QEMU классическую трансляцию сейчас реализуют - их же собирают под кучу архитектур (и, подозреваю, пишут так, чтобы на новую архитектуру легко портировались), и эмуляция одной архитектуры поверх другой там является штатной функцией.
Но вот на x86 без VT-x/AMD-V с ней грустно, там лучше бы был trap-and-emulate - но его нет, - по крайней мере, актуального и/или опенсорсного.
Вернее, раньше, конечно, у QEMU был драйвер kqemu, внезапно, даже с версией под XP/2003 (в статье на QEMU Wiki упоминались некие inf-файлы, а забросили драйвер kqemu примерно в середине нулевых), но с появлением VT-x на него забили. Да в период актуальности последних версий, которые этот драйвер поддерживают, регулярных бинарников для Windows никто не публиковал, поэтому снова: откапывать архивные исходники, пытаться их собрать.
Или ставить пиратку Workstation не новее 10.0.7...
Или MSVPC, но он эмулирует S3 Trio...64?, которая особо-то ничего не ускоряла.
Или тот же PowerPC: MSVPC для MacOS 9 или NTVDM в NT4 для PowerPC.
Вот в таких случаях - ничего лучше динамической перекомпиляции нет.
А trap-and-emulate ориентируется на то, что как ВМ, так и хост, на x86 (причём 32-рязрадном), поэтому непривилегированные инструкции (большая часть кода на 3 кольце защиты) гостевой ОС гипервизор может просто вызывать как свои собственные, а в случае хоста другой архитектуры так уже не получится.
Поэтому, наверное, DOSBox, Bochs и QEMU классическую трансляцию сейчас реализуют - их же собирают под кучу архитектур (и, подозреваю, пишут так, чтобы на новую архитектуру легко портировались), и эмуляция одной архитектуры поверх другой там является штатной функцией.
Но вот на x86 без VT-x/AMD-V с ней грустно, там лучше бы был trap-and-emulate - но его нет, - по крайней мере, актуального и/или опенсорсного.
Вернее, раньше, конечно, у QEMU был драйвер kqemu, внезапно, даже с версией под XP/2003 (в статье на QEMU Wiki упоминались некие inf-файлы, а забросили драйвер kqemu примерно в середине нулевых), но с появлением VT-x на него забили. Да в период актуальности последних версий, которые этот драйвер поддерживают, регулярных бинарников для Windows никто не публиковал, поэтому снова: откапывать архивные исходники, пытаться их собрать.
Или ставить пиратку Workstation не новее 10.0.7...
Или MSVPC, но он эмулирует S3 Trio...64?, которая особо-то ничего не ускоряла.
>Поэтому, наверное, DOSBox, Bochs и QEMU классическую трансляцию сейчас не реализуют - их же собирают под кучу архитектур (и, подозреваю, пишут так, чтобы на новую архитектуру легко портировались), и эмуляция одной архитектуры поверх другой там является штатной функцией.
Быстрофикс
>Что поддерживает эмуляцию хоть какого-то 3D-ускорителя, совместимого с 9x - это DOSBox-X и PCem... ах да, ещё последние версии Bochs.
Э? Про связку qemu-3dfx + softgpu в вашем графоманском бараке еще не слышали?
->
Лень читать портянку. Хотя нет, прочитаю.
>в среде, в которой он отработал бы без ошибок.
Але, автор прямым текстом пишет что сборка где-либо кроме бубунты 22.04 не гарантируется. Дистробоксы, докеры, хуекеры вам на что дали?
То есть, для сборки на другом дистре или архитектуре, тут уже нужно браться переписывать, как минимум, мейкфайлы, а то и ими не ограничиваться. То, что я в архитектуре разбираюсь, это ещё не значит, что у меня с программированием не ужасно. Было бы нормально - может, давно бы портировал kqemu на актуальные никсы или прикрутил к PCem/DOSBox/Bochs поддержку аппаратной виртуализации, включая VIA.
>Дистробоксы, докеры, хуекеры вам на что дали?
Накладные расходы...
>докеры, хуекеры вам на что дали?
Хм... запуск окружения GNU/Linux на тех смартах, под которые нет pmOS или её ядро сильно хуже, чем стоковое... установка инструментов разработки, которых прод-среда содержать не должна т.к. тогда хакер сможет собирать свой софт прямо на ней (но больше это актуально для винды, где до-дотнетовские визуалки криво деинсталлятся)... установка окружения другой версии дистра, чтобы не было dependency hell в основном... вроде, всё.
Я админ старой закалки и привык к монолиту, ёптыть.
>до-дотнетовские визуалки
А ещё у них установщик сильно тупит, если в системе смонтированы слишком большие тома...
>Я админ старой закалки и привык к монолиту, ёптыть.
Оно и видно что с бородой и свитером, отсюда и желание срать в /usr/local хостсистемы. А реальность такова: нет правильного окружения - нет билда.
Понятие "переносимость" по-твоему какая-то шутка?
Если бывают "правильные" и "неправильные" дистры, то бубунта - как ты понимаешь, неправильный.
>Понятие "переносимость" по-твоему какая-то шутка?
Контейнер и есть лучшая переносимость-воспроизводимость. Захуячено единожды @ работает везде.
Или, точнее, "написано однажды @ собирается везде и под всё". А не "избыточное кол-во отдельных stateful-окружений под каждую мокропиську".
Ох, я ж забыл, что такое бубунта, и кто её мейнтейнеры.
Эти ребята сначала какой-нибудь Genisoimage по-тихому форкнут, доработки в мейнстрим не вернут, а мне потом - сиди и гадай, почему гайд с официальной Syslinux Wiki по сборке с ним UEFI-совместимого ISO-ника на дебиане не работает. Пока дня через 2 случайно не обнаружится тред на Stack Overflow с ответом в духе: "вообще-то, cdrkit никогда UEFI не поддерживал и до сих пор не поддерживает, это всё дело рук убунтовцев". При этом в Syslinux Wiki о том, что этот гайд нужно исполнять на конкретном дистре, в отличие от твоего случая, не сказано => я могу это интерпретировать как "поддерживается любое окружение с актуальными cdrtools/cdrkit" и буду прав.
>Пока дня через 2 случайно не обнаружится тред на Stack Overflow с ответом в духе: "вообще-то, cdrkit никогда UEFI не поддерживал и до сих пор не поддерживает, это всё дело рук убунтовцев".
...а коллега потом скажет, что для бубунты это реально давно обычное дело. Так что на корп. машину пришлось её поставить, но на домашнюю - нахуй. Мне одной 10 хватает, чтобы постоянно её деблоатить.
>срать в /usr/local хостсистемы
Так проблема в том, что оно не только по /usr/local растекается. В отличие, кстати, от FreeBSD, где благодаря тому, что большая часть пакетов за пределы /usr/local даже не заглядывает - получается явное разделение системного окружения и приложений. Правда, и от него хотят отказаться, чтобы вместо base.txz была куча пакетиков.
Возрождённый, новогодний, маргинальный, твой.
Ссылки:
1. https://docs.google.com/document/d/1dS18-MDSAexZ4YqN3uegwkmyc73pMIYG3xP5TDMm35o/edit - методичка из последнего номерного треда
2. https://www.vmware.com/docs/x86-virt-esx-perf - описание и сравнение основных методик виртуализации x86
3. То же, что и в п. 2, более актуально, но с менее подробными примерами:
https://en.wikipedia.org/wiki/Virtualization
https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualization_requirements
https://en.wikipedia.org/wiki/X86_virtualization
https://en.wikipedia.org/wiki/Hardware_virtualization
Первыми постами, скорее всего, будет теория и списки тем для более подробного обсуждения, предпочтительно будет из этого составить новую методичку, подобную п. 1.
Шебмку сам снимал, 1 ноября 2024 года, и планирую юзать её в других местах, поэтому на всякий случай она под copyright и all rights reserved.