Виртуализации тред возрождённый
Аноним (Microsoft Windows 10: Chromium based)
03/01/26 Суб 02:07:10
№
1
Возрождённый, новогодний, маргинальный, твой.
Ссылки:
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.
Полная виртуализация - виртуализация целой системы с типовым аппаратным обеспечением. Бывает аппаратно ускоренной, программно ускоренной (бинарная трансляция) и не ускоренной (эмуляция).
Паравиртуализация - используется в 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 не умеют.
А вот ЦП, не имеющие поддержки нужных расширений системы команд, до сих пор иногда используются, о чём можно почитать в соседних тредах.
Помимо эмуляции и эмуляторов есть ещё гипервизоры, они же "virtual machine monitor". Как правило, так называются решения виртуализации, работающие преимущественно засчёт аппаратной виртуализации... впрочем, пока её не было, так назывались и эмуляторы, реализующие подход trap-and-emulate.
Различают гипервизоры I и II типа, но на самом деле разница между ними охуительно размыта. Сейчас рассмотрим на примерах.
К ним обычно относят те же 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.
>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
Во-первых, они тоже используют аппаратную виртуализацию, когда могут.
И тоже используют свои модули ядра.
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.
в 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 ГБ отображать каждому процессу, второе - помечать данные в памяти как исполняемые или нет, чтобы попытка исполнить не то через какое-нибудь переполнение обломалась с ошибкой.
Я подумал, но всё равно не понял. Когда тот же MSVPC типа перестаёт использовать бинарную трансляцию и начинает использовать VT-x/SVM, вроде, он ведёт себя так же, как тот же KVM - работает внутри обычной ОС, при этом взаимодействует с VT-x/SVM через модуль ядра для этой ОС. А по тем же, например, кольцам защиты отличий уже в этом случае нет.
Надеюсь, вопросов, вроде "если виртуалка нужна, чтобы поставить в неё 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...
Ещё хорошие темы - как и для чего разные гнилые приложухи пытаются детектить, что они работают в виртуалке, как их можно попытаться наебать (и среди каких гипервизоров выбирать именно с учётом этого), почему наебать может всё равно не получиться.
Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
>Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
В смысле, как минимум, точно не KVM и, уж тем более, не Hyper-V.
Deepseek это одним запросом расписывает
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
и конфиг ВМ в любом случае придётся дорабатывать напильником - можно уже начинать гуглить, как.
Пожалуйста, цитируй, что он тебе написал. Что он расписал это так же подробно, и ты уверен, что он ничего не напутал. Вообще, по идее, чтобы он лучше понимал, нужно ему такие треды скармливать (правда, двачу это может не понравиться), но при этом всё равно нет никакой гарантии, что поймёт.
Нейронки - вещь, конечно, удобная, но сомнительная.
Да, удобно, конечно, что в поисковик теперь можно тупо вводить вопросы, а не совокупность ключевых слов под синтаксисом уточнения их веса, и ответ от нейросети не потребует даже оплаты или доп. запроса. НО! "Доверяй, но проверяй" - это точно про нейросети.
>Эмулятор поддерживает оборудование, начиная от самых первых классических моделей 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 забыли совсем все, в том числе - разработчики опенсорсных решений. Не весь же ретро-софт в реальном режиме или нулевом кольце исполняется.
- запуск окружения на 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 сами осознают глючность коробокса... зачем тогда они до сих пор его поддерживают, интересно.
>>3683061
TL;DR: Верхнюю опцию можно не трогать, если не критично для гостя, нижнюю - предпочтительно включать, поскольку улучшает производительность. Но только если с ней работает, поскольку это зависит от свежести ЦП.
Даже интересно стало, какие задачи были, с таким аптаймом и десктопными ОС?)
Просто интересуюсь, к 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
Всё так.
Хоть доки у них доступны без регистрации (которая сломана).
>Эпплаенс хакинтоша на базе Docker и KVM
Звучит хайпово как годнота...
Потестить сейчас не смогу, так что, аноны, налетайте.
Где то видел докеры виртуалки венды и дройда
Android только x86 поддерживает? Если этот образ с ARM совместим - есть нехилая вероятность, что там Anbox Waydroid (и в случае Linux-хоста лучше всего именно так).
А вообще, есть одна тема, которую я тоже планировал в этом треде обсудить (если, конечно, есть, что обсуждать, а не один раз нормально чекнуть и (публично) записать).
"VMOS" и ещё несколько похожих приложений, естественно, со своими особенностями... первое, что вспоминается - версия системы во вложенном окружении и возможность рутования. Короче, Android-приложения, реализующие контейнер с отдельным экземпляром его же, например, для задач песочницы, но посерьёзнее, чем Island какой-нибудь, который я уже особо сильно релейтедом не считаю даже здесь, хотя здесь релейтедом считается много чего.