582 Кб, webm,800x600, 0:21
Виртуализации тред - ретро и ARM Edition
Возрождённый, новогодний, маргинальный, твой.
Ссылки:
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.
Возрождённый, новогодний, маргинальный, твой.
Ссылки:
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.
Полная виртуализация - виртуализация целой системы с типовым аппаратным обеспечением. Бывает аппаратно ускоренной, программно ускоренной (бинарная трансляция) и не ускоренной (эмуляция).
Паравиртуализация - используется в 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.
А теперь давайте попробуем разобрать различия между ними.
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.
>>682804
А вообще, если откопать на торрентах ESX, попробовать поставить его на какой-нибудь старенький хост и понаблюдать в это время за консолью - то сначала там будет процесс загрузки RHEL, а потом уже "Starting VMKernel...". Т.е. термин VMKernel появился ещё до ESXi, и, если он обозначал то же самое, то, получается, Service Console OS сначала грузилась на железе, а потом уже, кхм, перемещалась в виртуалку. Удивляет, но вообще, сделать окружение хоста виртуалкой - для гипервизоров обычное дело. Так до сих пор делают, например, отладчики, использующие аппаратную виртуализацию, или Касперский, когда использует её же для усиления защиты.
>ESX/ESXi
А вообще, если откопать на торрентах ESX, попробовать поставить его на какой-нибудь старенький хост и понаблюдать в это время за консолью - то сначала там будет процесс загрузки RHEL, а потом уже "Starting VMKernel...". Т.е. термин VMKernel появился ещё до ESXi, и, если он обозначал то же самое, то, получается, Service Console OS сначала грузилась на железе, а потом уже, кхм, перемещалась в виртуалку. Удивляет, но вообще, сделать окружение хоста виртуалкой - для гипервизоров обычное дело. Так до сих пор делают, например, отладчики, использующие аппаратную виртуализацию, или Касперский, когда использует её же для усиления защиты.
>>682804
Где-то ещё презентация с наглядным сравнением архитектур была, ищу ссылку.
>Hyper-V... с ним, как с Xen, поскольку его разработчики прямо вдохновлялись архитектурой последнего, и сделали её очень похожей.
Где-то ещё презентация с наглядным сравнением архитектур была, ищу ссылку.
>>682806
Нашёл. Правда, уже только в Wayback - пидорасы из SlideShare у себя её потёрли.
https://web.archive.org/web/20160324063800/http://www.slideshare.net/xen_com_mgr/why-xen-slides
Нашёл. Правда, уже только в 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 включительно.
>>682812
А ты рассмотри эту разницу через исполнение на блоках цп.
>разница между гипервизорами 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.
Дальше разберём некоторые особенности архитектуры, необходимые для понимания нюансов, возникающих в связи с различными подходами виртуализации.
Вспомним о режимах процессора 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 работать...
Ещё одной особенностью защищённого и длинного режимов стало появление колец защиты, с 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 работать...
>>682816
Совсем забыл дописать в нужное место.
Во-первых - что 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" не справляется.
>Вот это и помогло при реализации бинарной трансляции:
>инструкции, используемые приложениями юзерленда, бывшие, в основном непривилегированными, можно было тупо исполнять так же, как используемые приложениям хоста,
>а код 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" не справляется.
>>682816
Совсем забыл дописать в нужное место.
Во-первых - что 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" не справляется.
>Вот это и помогло при реализации бинарной трансляции:
>инструкции, используемые приложениями юзерленда, бывшие, в основном непривилегированными, можно было тупо исполнять так же, как используемые приложениям хоста,
>а код 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 ГБ отображать каждому процессу, второе - помечать данные в памяти как исполняемые или нет, чтобы попытка исполнить не то через какое-нибудь переполнение обломалась с ошибкой.
И небольшую подсказочку по этим самым расширениям:
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 ГБ отображать каждому процессу, второе - помечать данные в памяти как исполняемые или нет, чтобы попытка исполнить не то через какое-нибудь переполнение обломалась с ошибкой.
>>682813
Я подумал, но всё равно не понял. Когда тот же MSVPC типа перестаёт использовать бинарную трансляцию и начинает использовать VT-x/SVM, вроде, он ведёт себя так же, как тот же KVM - работает внутри обычной ОС, при этом взаимодействует с VT-x/SVM через модуль ядра для этой ОС. А по тем же, например, кольцам защиты отличий уже в этом случае нет.
Я подумал, но всё равно не понял. Когда тот же MSVPC типа перестаёт использовать бинарную трансляцию и начинает использовать VT-x/SVM, вроде, он ведёт себя так же, как тот же KVM - работает внутри обычной ОС, при этом взаимодействует с VT-x/SVM через модуль ядра для этой ОС. А по тем же, например, кольцам защиты отличий уже в этом случае нет.
Ух, вроде, с основной теорией закончили.
Надеюсь, вопросов, вроде "если виртуалка нужна, чтобы поставить в неё Win9x и играть в старые игры, зачем делать это в гипервизоре", теперь будет поменьше. Ответ именно на этот вопрос: потому что "динамическая перекомпиляция" или полная интерпретация тяжелее, чем trap-and-emulate, из-за чего эмуль приличного ретро-ПК требует вполне себе мощного хоста и может довести ноут до перегрева не хуже распоследнего AAA-тайтла. А поскольку задачи и железо у всех разные, я предлагаю подойти к вопросу более широко и вспомнить побольше различных решений виртуализации.
Надеюсь, вопросов, вроде "если виртуалка нужна, чтобы поставить в неё Win9x и играть в старые игры, зачем делать это в гипервизоре", теперь будет поменьше. Ответ именно на этот вопрос: потому что "динамическая перекомпиляция" или полная интерпретация тяжелее, чем trap-and-emulate, из-за чего эмуль приличного ретро-ПК требует вполне себе мощного хоста и может довести ноут до перегрева не хуже распоследнего AAA-тайтла. А поскольку задачи и железо у всех разные, я предлагаю подойти к вопросу более широко и вспомнить побольше различных решений виртуализации.
>>682825
Нет проблем, вкидывай материал, тоже добавим в методичку.
Только тогда вкидывай, как я - не только про докер, но и про сам LXC, и про другие фронтенды к нему (LXD, Libvirt-LXC, подсистему systemd), и про то, например, в каких случаях лучше Docker Swarm, в каких случаях уже нужен k8s, а в каких хватит и k3s.
Как бы, у всех задачи для виртуализации разные, и, соответственно, инструменты всем подходят разные, поэтому я решил, что вспомнить их нужно побольше, для чего и возрождаю тут мозговой штурм.
У меня, например, большинство задач связаны с запуском в виртуалках именно винды и, например, анальным огораживанием её от ответственного исполнения на физике, т.е. их хостом винда по определению быть не может.
Так что мне даже Xen в режиме PV не подходит, хотя он способен даже, например, запустить фряху на линукс-хосте, чего контейнеры уже не умеют.
Зато для контейнеров мне приходит в голову от силы пара давно обкатанных сценариев, и микросервисы в них не входят - например, потому что виртуализацией я начинал заниматься в конце нулевых, когда ещё никакого докера не было.
Плюс, у меня зоопарк платформ на хостах. Какие-то - на ARM (и менять их на x86 - не особо вариант), какие-то - без VT-x, при этом достаточно мощные для виртуалок - но хотелось бы при этом не снижать их КПД, просто потому что в современных эмуляторах больше не поддерживают подход с меньшим оверхедом.
Нет проблем, вкидывай материал, тоже добавим в методичку.
Только тогда вкидывай, как я - не только про докер, но и про сам 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...
Ещё хорошие темы - как и для чего разные гнилые приложухи пытаются детектить, что они работают в виртуалке, как их можно попытаться наебать (и среди каких гипервизоров выбирать именно с учётом этого), почему наебать может всё равно не получиться.
Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
А теперь - ближе к делу, к частным случаям.
Во-первых, сначала вспомним, под какие платформы у нас есть вообще что-то, связанное с виртуальными машинами.
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...
Ещё хорошие темы - как и для чего разные гнилые приложухи пытаются детектить, что они работают в виртуалке, как их можно попытаться наебать (и среди каких гипервизоров выбирать именно с учётом этого), почему наебать может всё равно не получиться.
Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
>>682833
В смысле, как минимум, точно не KVM и, уж тем более, не Hyper-V.
>Или, например, что можно ставить на мишн-критикал хосты (настолько мишн-критикал, что даже можно пожертвовать функционалом гипервизора).
В смысле, как минимум, точно не KVM и, уж тем более, не Hyper-V.
Я ж говорю, тем много, и для тредов линуксового или даунгрейдерского они не совсем подходят.
Здравствуйте, какие инструменты подойдут лучше для:
1) создания и хранения отдельной интернет личности, со своими аккаунтами и прочим. изначально я думал что вообще будет достаточно просто профиля в браузере, но потом начал сомневаться (даже нормисные сайты уже в открытую профилируют с помощью фингерпринтинга)
2) проверки\использования софта из сомнительных источников. как организовать передачу файлов с хоста? смб диск шарить, встроенные функции с общей папкой, монтировать образ диска и тд
1) создания и хранения отдельной интернет личности, со своими аккаунтами и прочим. изначально я думал что вообще будет достаточно просто профиля в браузере, но потом начал сомневаться (даже нормисные сайты уже в открытую профилируют с помощью фингерпринтинга)
2) проверки\использования софта из сомнительных источников. как организовать передачу файлов с хоста? смб диск шарить, встроенные функции с общей папкой, монтировать образ диска и тд
>>682874
Хм...
Да, отдельного профиля в браузерах действительно будет маловато, изоляция нужна будет более серьёзная, плюс прокси всякие. Её можно попытаться намутить самому, но могу сразу порекомендовать готовое решение, которое, возможно, будет оверкилл, и при этом точно будет релейтед.
QubesOS - десктопный дистрибутив Fedora GNU/Linux/Xen, судя по отзывам - даже освоивший какие-то Xen'овские уникальные фичи. Признан различными практикующими ИБ-специалистами и другими энтузиастами. Вообще, мне её посоветовали, когда я попросил дистр Xen, подходящий для вката в него.
Также, к нему стоит добавить Whonix - более серьёзный аналог TAILS, являющийся виртуальным эпплаенсом, в качестве самодостаточного хоста как раз поддерживающий преимущественно Qубики.
Конечно, придётся вспоминать, что TAILS и Whonix - это эпплаенсы Тора, и соответствующие нюансы, вроде запрета на постинг здесь или пробивания ТСПУ тебе придётся разгребать самому. С ТСПУ, возможно, помогут в соседнем треде.
Вообще, для обхода фингерпринтинга есть ещё более готовые решения - специальные браузеры под винду, скорее всего - пилятся специально для ботоводов.
Их даже Овер рекламировал. Но, вопервых, они только под винду и только под распоследнюю, а во-вторых - платные. А вообще, раз мы заговорили про ботоводов - читая этот текст, ты автоматически даёшь присягу, что таковым не являешься.
Да, гипервизоры для этого подходят идеально, это именно одно из направлений, где они активно используются. Так или иначе аппаратная виртуализация используется Касперским для усиления защиты (но со всеми решениями для запуска ВМ конфликтует) и нашим "любимым" За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
и конфиг ВМ в любом случае придётся дорабатывать напильником - можно уже начинать гуглить, как.
Хм...
>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
и конфиг ВМ в любом случае придётся дорабатывать напильником - можно уже начинать гуглить, как.
>>682874
Хм...
Да, отдельного профиля в браузерах действительно будет маловато, изоляция нужна будет более серьёзная, плюс прокси всякие. Её можно попытаться намутить самому, но могу сразу порекомендовать готовое решение, которое, возможно, будет оверкилл, и при этом точно будет релейтед.
QubesOS - десктопный дистрибутив Fedora GNU/Linux/Xen, судя по отзывам - даже освоивший какие-то Xen'овские уникальные фичи. Признан различными практикующими ИБ-специалистами и другими энтузиастами. Вообще, мне её посоветовали, когда я попросил дистр Xen, подходящий для вката в него.
Также, к нему стоит добавить Whonix - более серьёзный аналог TAILS, являющийся виртуальным эпплаенсом, в качестве самодостаточного хоста как раз поддерживающий преимущественно Qубики.
Конечно, придётся вспоминать, что TAILS и Whonix - это эпплаенсы Тора, и соответствующие нюансы, вроде запрета на постинг здесь или пробивания ТСПУ тебе придётся разгребать самому. С ТСПУ, возможно, помогут в соседнем треде.
Вообще, для обхода фингерпринтинга есть ещё более готовые решения - специальные браузеры под винду, скорее всего - пилятся специально для ботоводов.
Их даже Овер рекламировал. Но, вопервых, они только под винду и только под распоследнюю, а во-вторых - платные. А вообще, раз мы заговорили про ботоводов - читая этот текст, ты автоматически даёшь присягу, что таковым не являешься.
Да, гипервизоры для этого подходят идеально, это именно одно из направлений, где они активно используются. Так или иначе аппаратная виртуализация используется Касперским для усиления защиты (но со всеми решениями для запуска ВМ конфликтует) и нашим "любимым" За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
и конфиг ВМ в любом случае придётся дорабатывать напильником - можно уже начинать гуглить, как.
Хм...
>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
и конфиг ВМ в любом случае придётся дорабатывать напильником - можно уже начинать гуглить, как.
>>682839
Пожалуйста, цитируй, что он тебе написал. Что он расписал это так же подробно, и ты уверен, что он ничего не напутал. Вообще, по идее, чтобы он лучше понимал, нужно ему такие треды скармливать (правда, двачу это может не понравиться), но при этом всё равно нет никакой гарантии, что поймёт.
Нейронки - вещь, конечно, удобная, но сомнительная.
Да, удобно, конечно, что в поисковик теперь можно тупо вводить вопросы, а не совокупность ключевых слов под синтаксисом уточнения их веса, и ответ от нейросети не потребует даже оплаты или доп. запроса. НО! "Доверяй, но проверяй" - это точно про нейросети.
Пожалуйста, цитируй, что он тебе написал. Что он расписал это так же подробно, и ты уверен, что он ничего не напутал. Вообще, по идее, чтобы он лучше понимал, нужно ему такие треды скармливать (правда, двачу это может не понравиться), но при этом всё равно нет никакой гарантии, что поймёт.
Нейронки - вещь, конечно, удобная, но сомнительная.
Да, удобно, конечно, что в поисковик теперь можно тупо вводить вопросы, а не совокупность ключевых слов под синтаксисом уточнения их веса, и ответ от нейросети не потребует даже оплаты или доп. запроса. НО! "Доверяй, но проверяй" - это точно про нейросети.
http://tv-games.ru/emulator/open/pcem.html
Вот поэтому для виртуализации ретро-ПК всё-таки 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-ускорению;
- конечно же, желательно - обеспечиваемому одной десктопной карточкой.
49 Кб, 976x471>>682833
Ок, что эта настройка Vbox делает на самом деле, когда в винде есть установленный Hyper-V
Ок, что эта настройка Vbox делает на самом деле, когда в винде есть установленный Hyper-V
>>683060
Выпадающий список сверху - меняет виртуализацию таймингов: как в Hyper-V, как в KVM, как в просто произвольном гипервизоре ("Минимальный", в зависимости от указанной в настройка гостевой ОС ("Совместимый") или без виртуализации таймингов. Переключать его в KVM для подключения сетевой карты VirtIO - не обязательно. Очень неочевидный параметр, да. Пока не увидел в мануале https://www.virtualbox.org/manual/topics/working-with-vms.html#gimproviders - думал, что его выбор зависит от ОС хоста.
Флажок снизу - вручную включает использование аппаратной вложенной виртуальной памяти (Intel EPT/AMD RVI).
Выпадающий список сверху - меняет виртуализацию таймингов: как в 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 сами осознают глючность коробокса... зачем тогда они до сих пор его поддерживают, интересно.
>>683061
TL;DR: Верхнюю опцию можно не трогать, если не критично для гостя, нижнюю - предпочтительно включать, поскольку улучшает производительность. Но только если с ней работает, поскольку это зависит от свежести ЦП.
Имеются сведения, что он заимствует ~30% кода QEMU...
В отличие от Proxmox VE и его многочисленных (но это не точно) функциональных аналогов, скорее всего, речь идёт про всякие подсистемы вроде используемого BIOS и когда эмулируемой периферии.
С другой стороны, когда-то у у коробокса был и серверный вариант, может даже - в виде решения "I типа" (в Википедии есть упоминания некоего "Virtual Iron")... а сейчас серверное решение виртуализации от Oracle - это тупо Oracle Linux с KVM.
Похоже, что в Oracle сами осознают глючность коробокса... зачем тогда они до сих пор его поддерживают, интересно.
>>683061
TL;DR: Верхнюю опцию можно не трогать, если не критично для гостя, нижнюю - предпочтительно включать, поскольку улучшает производительность. Но только если с ней работает, поскольку это зависит от свежести ЦП.
Виртуалбокс это жопа, аптайм максимум месяц был и падал. Вмваре 400 дней аптайм перевалил гость венда7. И там и там хосты венда 10. Думайте.
>>683328
Даже интересно стало, какие задачи были, с таким аптаймом и десктопными ОС?)
Просто интересуюсь, к M$ отношения не имею, честно-пречестно. В смысле, сдавал MTA по паре направлений, но работать к ним идти точно в рот ебал.
Даже интересно стало, какие задачи были, с таким аптаймом и десктопными ОС?)
Просто интересуюсь, к M$ отношения не имею, честно-пречестно. В смысле, сдавал MTA по паре направлений, но работать к ним идти точно в рот ебал.
>>683512
Тогда сразу понятно.
Это, конечно, легче, чем у меня - никакие GPU пробрасывать не надо, наверное, достаточно пары USB/COM-портов.)
Хм, а насколько старый? Это он на 7 шёл, или внутри 7 ещё какие-то костыли были?
Тогда сразу понятно.
Это, конечно, легче, чем у меня - никакие GPU пробрасывать не надо, наверное, достаточно пары USB/COM-портов.)
Хм, а насколько старый? Это он на 7 шёл, или внутри 7 ещё какие-то костыли были?
>>683516
Образ снят со старого мёртвого системника и просто запущен на современном железе под виртуалкой. Из настроек сетевой мост добавлен и там usb ключ ещё проброшен.
Образ снят со старого мёртвого системника и просто запущен на современном железе под виртуалкой. Из настроек сетевой мост добавлен и там usb ключ ещё проброшен.
>>683520
Это вы ещё довольно легко отделались... не считая, что 7 не сильно ожидала быть включенной на другом железе. Но и с этим, как я понимаю, повезло.
Осенью 2021 дело было. По работе практике в техникуме читал, что у клиента интегратор отечественные ПЛК забраковал - потому что управляющий софт у них был только под QNX - а QNX - поддерживала только 486, которые уже непонятно, где покупать.
Тогда даже я не вспомнил, что QNX, вообще-то, живее всех живых и, вроде, даже имеет локализованно-сертифицированные варианты...
https://ru.wikipedia.org/wiki/QNX
Да, всё так. Но мысль "как так, в двух крупных-долгоживущих-серьёзных интеграторах никто не вспомнил...?" всё равно появлялась - правда, про, например Zhaoxin и Vortex86, из которых как минимум последний именно в таких кейсах часто используется.
А вот это напишу вне спойлера, потому что у QNX сейчас, вроде, и встроенный гипервизор есть, и ARM-версия, и её даже можно на малинках запускать... и я вполне допускаю, что штатный гипервизор под ARM портировать уже успели.
Правда, образ официально достать трудно но, вроде, легче, чем у той же, например, QP ОС. А с этим кто-то здесь опыт имел?
Из более недавнего и реального: тут 10 переносил в Workstation 15.5.7 (первая версия с поддержкой WHPX) - я для неё и SMBIOS пробросил, и MAC прописал, и ещё что-то сделал, но заново искать драйвера она всё равно начала.
ЧСХ, OEM-активация не слетела (!!). Хотя, вроде, кстати, ACPI-таблицы я не пробрасывал (что VMWS, вроде, и не умел никогда).
Заодно узнал, что создание qemu-img не умеет конвертировать в vmdk (даже того варианта, который использует Workstation) - а вот коробокс с этим справился вполне - после него (и только после него) варя подцепить образ смогла.
Это вы ещё довольно легко отделались... не считая, что 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) - а вот коробокс с этим справился вполне - после него (и только после него) варя подцепить образ смогла.
>>683532
Быстрофикс
>Заодно узнал, что qemu-img не умеет конвертировать в vmdk (даже того варианта, который использует Workstation)
Быстрофикс
>>683532
https://qnx.software/content/dam/qnx-xwalk/pdf/product-briefs/qnx-hypervisor-8-product-brief.pdf
Всё так.
Хоть доки у них доступны без регистрации (которая сломана).
>штатный гипервизор под 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
Звучит хайпово как годнота...
Потестить сейчас не смогу, так что, аноны, налетайте.
>>683883
Android только x86 поддерживает? Если этот образ с ARM совместим - есть нехилая вероятность, что там Anbox Waydroid (и в случае Linux-хоста лучше всего именно так).
А вообще, есть одна тема, которую я тоже планировал в этом треде обсудить (если, конечно, есть, что обсуждать, а не один раз нормально чекнуть и (публично) записать).
"VMOS" и ещё несколько похожих приложений, естественно, со своими особенностями... первое, что вспоминается - версия системы во вложенном окружении и возможность рутования. Короче, Android-приложения, реализующие контейнер с отдельным экземпляром его же, например, для задач песочницы, но посерьёзнее, чем Island какой-нибудь, который я уже особо сильно релейтедом не считаю даже здесь, хотя здесь релейтедом считается много чего.
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 включительно насколько легко будет повторить?
56 Кб, 1051x441А теперь - переходим к интересному.
Вот, с чего начались гипервизоры на 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!
Что ж, вот теперь варианты стека ретро-виртуализации приходят в голову "сами собой"...
>>686227
Можно ещё рассмотреть для не очень требовательных приложений вариант с притаскиванием NTVDM (и WoW) в WinPE 1.6 - с относительным максимумом нюансов, конечно, но большей вероятностью запуститься в роли хоста, чем 9x и, уж тем более, полуось.
Тут и наработки MOA по ссылке выше могут пригодиться.)
Можно ещё рассмотреть для не очень требовательных приложений вариант с притаскиванием NTVDM (и WoW) в WinPE 1.6 - с относительным максимумом нюансов, конечно, но большей вероятностью запуститься в роли хоста, чем 9x и, уж тем более, полуось.
Тут и наработки MOA по ссылке выше могут пригодиться.)
342 Кб, 427x426Какой смысл ставить Win98 на DOSBox, если уже есть PCEm настроеный на P166 MMX с той же 98-й виндой?
>>686849
Такой, что динамическая перекомпиляция медленнее и прожорливее, чем 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 ещё не было.
Такой, что динамическая перекомпиляция медленнее и прожорливее, чем 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 ещё не было.
>>686888
Нет. В целом она лучше всего будет работать в 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 обеспечит минимальные накладные расходы (и, как следствие, повышение производительности) при, как раз, обсчёте графики этих игр. Но не всего остального - остальное он эмулирует, хорошо хоть - что при эмуляции ЦП задействует динамическую перекомпиляцию, - которая, хотя и быстрее полной эмуляции (интерпретации), но медленнее классической бинарной трансляции, как в
которую я для называю "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 МГц, и то, в самом лучшем случае...
Нет. В целом она лучше всего будет работать в 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 МГц, и то, в самом лучшем случае...
>>686888
Нет. В целом она лучше всего будет работать в 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 обеспечит минимальные накладные расходы (и, как следствие, повышение производительности) при, как раз, обсчёте графики этих игр. Но не всего остального - остальное он эмулирует, хорошо хоть - что при эмуляции ЦП задействует динамическую перекомпиляцию, - которая, хотя и быстрее полной эмуляции (интерпретации), но медленнее классической бинарной трансляции, как в
которую я для называю "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 МГц, и то, в самом лучшем случае...
Нет. В целом она лучше всего будет работать в 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 МГц, и то, в самом лучшем случае...
>>686969
Но самый быстрый реализуемый в них метод эмуляции ЦП - это динамическая перекомпиляция, которая, как я уже писал,
Конечно, есть форк QEMU под названием "qemu-3dfx", вроде, даже поддерживающий KVM, а от того же автора есть наработки и под коробокс с варей (настольной)... но, сейчас их надо ставить из исходников, что сможет сделать не каждый "пауэр юзер" - даже тупо правильно запустить ./configure и make/make install, в среде, в которой он отработал бы без ошибок.
Также, на binary-based дистре с пакетным менеджером - мешать софт, установленный из нативных пакетов, с софтом, установленным через git clone и make install - иногда действительно является плохой идеей..
Поэтому, например, pip в дебиане или фряхе отказывается работать снаружи venv - библиотеки нужные поставляются через нативный пакетный менеджер, а если pip возьмётся их ставить, то нативный ПМ об этом не узнает, но в каких-то случаях (например, зависимость другого пакета) может попытаться обновить его сам, и будут конфликты.
И я что-то не верю, что наработки проекта qemu-3dfx примут в апстрим - основными пользователями QEMU являются суровые девопсы, которые используют QEMU/KVM как бесплатно-безопасную замену ESXi, и им эмуляция 3Dfx, получается, как правило, нинужна.
>Что поддерживает эмуляцию хоть какого-то 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?, которая особо-то ничего не ускоряла.
>>687005
Быстрофикс
>Поэтому, наверное, DOSBox, Bochs и QEMU классическую трансляцию сейчас не реализуют - их же собирают под кучу архитектур (и, подозреваю, пишут так, чтобы на новую архитектуру легко портировались), и эмуляция одной архитектуры поверх другой там является штатной функцией.
Быстрофикс
>>686969
Э? Про связку qemu-3dfx + softgpu в вашем графоманском бараке еще не слышали?
>Что поддерживает эмуляцию хоть какого-то 3D-ускорителя, совместимого с 9x - это DOSBox-X и PCem... ах да, ещё последние версии Bochs.
Э? Про связку qemu-3dfx + softgpu в вашем графоманском бараке еще не слышали?
>>687019
Лень читать портянку. Хотя нет, прочитаю.
Але, автор прямым текстом пишет что сборка где-либо кроме бубунты 22.04 не гарантируется. Дистробоксы, докеры, хуекеры вам на что дали?
Лень читать портянку. Хотя нет, прочитаю.
>в среде, в которой он отработал бы без ошибок.
Але, автор прямым текстом пишет что сборка где-либо кроме бубунты 22.04 не гарантируется. Дистробоксы, докеры, хуекеры вам на что дали?
>>687028
То есть, для сборки на другом дистре или архитектуре, тут уже нужно браться переписывать, как минимум, мейкфайлы, а то и ими не ограничиваться. То, что я в архитектуре разбираюсь, это ещё не значит, что у меня с программированием не ужасно. Было бы нормально - может, давно бы портировал kqemu на актуальные никсы или прикрутил к PCem/DOSBox/Bochs поддержку аппаратной виртуализации, включая VIA.
То есть, для сборки на другом дистре или архитектуре, тут уже нужно браться переписывать, как минимум, мейкфайлы, а то и ими не ограничиваться. То, что я в архитектуре разбираюсь, это ещё не значит, что у меня с программированием не ужасно. Было бы нормально - может, давно бы портировал kqemu на актуальные никсы или прикрутил к PCem/DOSBox/Bochs поддержку аппаратной виртуализации, включая VIA.
>>687028
Хм... запуск окружения GNU/Linux на тех смартах, под которые нет pmOS или её ядро сильно хуже, чем стоковое... установка инструментов разработки, которых прод-среда содержать не должна т.к. тогда хакер сможет собирать свой софт прямо на ней (но больше это актуально для винды, где до-дотнетовские визуалки криво деинсталлятся)... установка окружения другой версии дистра, чтобы не было dependency hell в основном... вроде, всё.
Я админ старой закалки и привык к монолиту, ёптыть.
>докеры, хуекеры вам на что дали?
Хм... запуск окружения GNU/Linux на тех смартах, под которые нет pmOS или её ядро сильно хуже, чем стоковое... установка инструментов разработки, которых прод-среда содержать не должна т.к. тогда хакер сможет собирать свой софт прямо на ней (но больше это актуально для винды, где до-дотнетовские визуалки криво деинсталлятся)... установка окружения другой версии дистра, чтобы не было dependency hell в основном... вроде, всё.
Я админ старой закалки и привык к монолиту, ёптыть.
>>687115
А ещё у них установщик сильно тупит, если в системе смонтированы слишком большие тома...
>до-дотнетовские визуалки
А ещё у них установщик сильно тупит, если в системе смонтированы слишком большие тома...
>>687115
Оно и видно что с бородой и свитером, отсюда и желание срать в /usr/local хостсистемы. А реальность такова: нет правильного окружения - нет билда.
>Я админ старой закалки и привык к монолиту, ёптыть.
Оно и видно что с бородой и свитером, отсюда и желание срать в /usr/local хостсистемы. А реальность такова: нет правильного окружения - нет билда.
>>687119
Понятие "переносимость" по-твоему какая-то шутка?
Если бывают "правильные" и "неправильные" дистры, то бубунта - как ты понимаешь, неправильный.
Понятие "переносимость" по-твоему какая-то шутка?
Если бывают "правильные" и "неправильные" дистры, то бубунта - как ты понимаешь, неправильный.
>>687120
Контейнер и есть лучшая переносимость-воспроизводимость. Захуячено единожды @ работает везде.
>Понятие "переносимость" по-твоему какая-то шутка?
Контейнер и есть лучшая переносимость-воспроизводимость. Захуячено единожды @ работает везде.
>>687121
Или, точнее, "написано однажды @ собирается везде и под всё". А не "избыточное кол-во отдельных stateful-окружений под каждую мокропиську".
Или, точнее, "написано однажды @ собирается везде и под всё". А не "избыточное кол-во отдельных stateful-окружений под каждую мокропиську".
>>687120
Ох, я ж забыл, что такое бубунта, и кто её мейнтейнеры.
Эти ребята сначала какой-нибудь Genisoimage по-тихому форкнут, доработки в мейнстрим не вернут, а мне потом - сиди и гадай, почему гайд с официальной Syslinux Wiki по сборке с ним UEFI-совместимого ISO-ника на дебиане не работает. Пока дня через 2 случайно не обнаружится тред на Stack Overflow с ответом в духе: "вообще-то, cdrkit никогда UEFI не поддерживал и до сих пор не поддерживает, это всё дело рук убунтовцев". При этом в Syslinux Wiki о том, что этот гайд нужно исполнять на конкретном дистре, в отличие от твоего случая, не сказано => я могу это интерпретировать как "поддерживается любое окружение с актуальными cdrtools/cdrkit" и буду прав.
Ох, я ж забыл, что такое бубунта, и кто её мейнтейнеры.
Эти ребята сначала какой-нибудь Genisoimage по-тихому форкнут, доработки в мейнстрим не вернут, а мне потом - сиди и гадай, почему гайд с официальной Syslinux Wiki по сборке с ним UEFI-совместимого ISO-ника на дебиане не работает. Пока дня через 2 случайно не обнаружится тред на Stack Overflow с ответом в духе: "вообще-то, cdrkit никогда UEFI не поддерживал и до сих пор не поддерживает, это всё дело рук убунтовцев". При этом в Syslinux Wiki о том, что этот гайд нужно исполнять на конкретном дистре, в отличие от твоего случая, не сказано => я могу это интерпретировать как "поддерживается любое окружение с актуальными cdrtools/cdrkit" и буду прав.
>>687152
...а коллега потом скажет, что для бубунты это реально давно обычное дело. Так что на корп. машину пришлось её поставить, но на домашнюю - нахуй. Мне одной 10 хватает, чтобы постоянно её деблоатить.
>Пока дня через 2 случайно не обнаружится тред на Stack Overflow с ответом в духе: "вообще-то, cdrkit никогда UEFI не поддерживал и до сих пор не поддерживает, это всё дело рук убунтовцев".
...а коллега потом скажет, что для бубунты это реально давно обычное дело. Так что на корп. машину пришлось её поставить, но на домашнюю - нахуй. Мне одной 10 хватает, чтобы постоянно её деблоатить.
>>687119
Так проблема в том, что оно не только по /usr/local растекается. В отличие, кстати, от FreeBSD, где благодаря тому, что большая часть пакетов за пределы /usr/local даже не заглядывает - получается явное разделение системного окружения и приложений. Правда, и от него хотят отказаться, чтобы вместо base.txz была куча пакетиков.
>срать в /usr/local хостсистемы
Так проблема в том, что оно не только по /usr/local растекается. В отличие, кстати, от FreeBSD, где благодаря тому, что большая часть пакетов за пределы /usr/local даже не заглядывает - получается явное разделение системного окружения и приложений. Правда, и от него хотят отказаться, чтобы вместо base.txz была куча пакетиков.
Оказывается, варя не так уж и охуенна - с полуосью у неё до сих пор плохо. Не, ArcaOS с рутрекера, может, устанавливалась именно в неё, но на старых версиях (новее 2.0!) - этот же исошник нихуя не загрузился.
Предпочтительно полуось запускать таки в виндовом Parallels... если удастся к нему ключ найти. А если не удастся - качать со "Старого DOS" последнюю версию свиста-2004 - именно её как раз разрабатывали для запуска полуоси или под полуосью (по заказу той же компании, которая занималась eComStation), при участии Parallels же.
Примечание:
TwoOStwo, Serenity Virtual Station 2004 и Paralles Workstation (именно в таком хронологическом порядке) - технически, разные версии одного и того же, просто к ним имели отношение разные компании - они и переименовывали.
Предпочтительно полуось запускать таки в виндовом Parallels... если удастся к нему ключ найти. А если не удастся - качать со "Старого DOS" последнюю версию свиста-2004 - именно её как раз разрабатывали для запуска полуоси или под полуосью (по заказу той же компании, которая занималась eComStation), при участии Parallels же.
Примечание:
TwoOStwo, Serenity Virtual Station 2004 и Paralles Workstation (именно в таком хронологическом порядке) - технически, разные версии одного и того же, просто к ним имели отношение разные компании - они и переименовывали.
>>688930
Затем, что с поддержкой современного железа у неё не сильно лучше, чем у реактоси, и немного хуже, чем у NT4.
Затем, что с поддержкой современного железа у неё не сильно лучше, чем у реактоси, и немного хуже, чем у NT4.
>>688930
А ты её на реальном железе используешь? Я, вроде, пробовал загружать с образа всё, где eCS 2.1 не запустилась - лучше не стало.
Хотя мне и нравится "лучшая DOS, чем DOS и лучшая Windows, чем Windows 3.1x" (причём, преимущественно именно поэтому), мне кажется, что, к сожалению, как бы ArcaOS ни поддерживалась - это всё равно, по сути, про легаси-окружения, которые накладно мигрировать.
А ты её на реальном железе используешь? Я, вроде, пробовал загружать с образа всё, где eCS 2.1 не запустилась - лучше не стало.
Хотя мне и нравится "лучшая DOS, чем DOS и лучшая Windows, чем Windows 3.1x" (причём, преимущественно именно поэтому), мне кажется, что, к сожалению, как бы ArcaOS ни поддерживалась - это всё равно, по сути, про легаси-окружения, которые накладно мигрировать.
>>688966
Нет, я вобще никогда не пользовался OS/2, только в журналах и интернетах видел. Поэтому и не вижу пока смысла ее даже в виртуалке запускать.
Хотя из-за того что она умеет win3.1 программы запускать, может и стоит заморочиться, ради win3.1-игрушек.. 🤔
>А ты её на реальном железе используешь?
Нет, я вобще никогда не пользовался OS/2, только в журналах и интернетах видел. Поэтому и не вижу пока смысла ее даже в виртуалке запускать.
Хотя из-за того что она умеет win3.1 программы запускать, может и стоит заморочиться, ради win3.1-игрушек.. 🤔
>>689013
Даже больше, она может параллельно гонять несколько изолированных сеансов с этой 3.1, она может давать прямой доступ к диску и даже запускать загрузочные окружения реального режима (как минимум, в Warp 3 в окне "Система\Командный режим" был ярлык "Запуск ОС с дискеты A:"). Также, в Win-OS2 уже предустановлена Win32s, а в ArcaOS, вроде, есть и порт Wine.
И лучше ставить именно ArcaOS (есть на рутрекере), потому что только там добавлена поддержка дисков больше 2 Гбайт (в более ранних версиях с этим проблемы... как минимум, в случае того же "прямого доступа").
Даже больше, она может параллельно гонять несколько изолированных сеансов с этой 3.1, она может давать прямой доступ к диску и даже запускать загрузочные окружения реального режима (как минимум, в Warp 3 в окне "Система\Командный режим" был ярлык "Запуск ОС с дискеты A:"). Также, в Win-OS2 уже предустановлена Win32s, а в ArcaOS, вроде, есть и порт Wine.
И лучше ставить именно ArcaOS (есть на рутрекере), потому что только там добавлена поддержка дисков больше 2 Гбайт (в более ранних версиях с этим проблемы... как минимум, в случае того же "прямого доступа").
Сап, виртуач! Хочу Mac OS Ventura под VirtualBox в Раче. Попробовал с русракера скачать пару ISO образов, но установить не смог, падают в цикл ребут. Качал ещё один образ по ссылке васяна с YouTube, но почти тоже самое. Система на свИнцел 10900X с noVideo 3080. Как зделоть, чтобы работало? В какое СпортЛото тут написать, чтобы аноны помогли?
>>689016
☕☕
А на чем ее лучше запускать? На какой виртуалке, чтобы была еще и аппаратная поддержка (как PCEm и 3dfx)?
☕☕
А на чем ее лучше запускать? На какой виртуалке, чтобы была еще и аппаратная поддержка (как PCEm и 3dfx)?
>>689056
Как раз-таки только PCem, его форки (не особо их признаю), Bochs или qemu-3dfx/softgpu (нужно собирать из исходников).
Если ускорение графики не нужно, но в целом лучше бы было побыстрее - только Parallels, он же под старыми названиями, или Connectix/Microsoft Virtual PC.
>PCEm и 3dfx?
Как раз-таки только PCem, его форки (не особо их признаю), Bochs или qemu-3dfx/softgpu (нужно собирать из исходников).
Если ускорение графики не нужно, но в целом лучше бы было побыстрее - только Parallels, он же под старыми названиями, или Connectix/Microsoft Virtual PC.
>>689056
Вообще, рекомендуют для этого дела собирать старую пекарню на чипсете i440BX (его эмулирует и Варя, и MSVPC, и Bochs умеет, и PCem в случае выбора GA-686BX в качестве типа машины) - она и полуось, и NT4 подхватит, и даже реактось (собственно, единственный чипсет, на котором она уверенно работает).
Проблема в том, что там, как правило, Slot 1, а я hui ego znaet, насколько у него вообще нормально с физикой (кулер висит на ЦП, сам он - иногда не цельный картридж, а переходник на сокет, и, в свою очередь картридж висит на слоте без дополнительных креплений... Но, вроде, на 440BX бывал и 370 сокет.
Вообще, рекомендуют для этого дела собирать старую пекарню на чипсете i440BX (его эмулирует и Варя, и MSVPC, и Bochs умеет, и PCem в случае выбора GA-686BX в качестве типа машины) - она и полуось, и NT4 подхватит, и даже реактось (собственно, единственный чипсет, на котором она уверенно работает).
Проблема в том, что там, как правило, Slot 1, а я hui ego znaet, насколько у него вообще нормально с физикой (кулер висит на ЦП, сам он - иногда не цельный картридж, а переходник на сокет, и, в свою очередь картридж висит на слоте без дополнительных креплений... Но, вроде, на 440BX бывал и 370 сокет.
>>689090
Паравиртуальная видеокарта, пробрасывающая вызовы графических API на видеокарту хоста. Кстати, гостевая ОС с неё не может обращаться, как с обычным устройством - ей обязательно нужно, чтобы "бэкдор" (так у VMWare называется служебный канал для взаимодействия VMWare Tools с гипером) оставался включен, т.е. скрыть факт виртуализации от гостевой ОС будет проблематично.
Паравиртуальная видеокарта, пробрасывающая вызовы графических API на видеокарту хоста. Кстати, гостевая ОС с неё не может обращаться, как с обычным устройством - ей обязательно нужно, чтобы "бэкдор" (так у VMWare называется служебный канал для взаимодействия VMWare Tools с гипером) оставался включен, т.е. скрыть факт виртуализации от гостевой ОС будет проблематично.
>>689101
т.е. у вари все отлично с аппаратным ускорением видеокарты, в OS/2 4.5(2)?
>Паравиртуальная видеокарта, пробрасывающая вызовы графических API на видеокарту хоста.
т.е. у вари все отлично с аппаратным ускорением видеокарты, в OS/2 4.5(2)?
>>689149
В NT 5.x-10 и никсах - да, насчёт полуоси - не уверен. Ещё раз, у вари с полуосью в принципе плохо.
Плюс, самые последние физ. GPU, которые полуось поддерживала (драйвером SNAP) - это 6600, что-то новее под полуосью способно максимум в VESA.
А насчёт Voodoo меня вообще терзают смутные сомнения - не игровая же система была. А Voodoo вряд ли можно назвать профессиональным ускорителем.
В NT 5.x-10 и никсах - да, насчёт полуоси - не уверен. Ещё раз, у вари с полуосью в принципе плохо.
Плюс, самые последние физ. GPU, которые полуось поддерживала (драйвером SNAP) - это 6600, что-то новее под полуосью способно максимум в VESA.
А насчёт Voodoo меня вообще терзают смутные сомнения - не игровая же система была. А Voodoo вряд ли можно назвать профессиональным ускорителем.
Хм. Допустим, мне действительно попалась такая видеокарта, которая при пробросе через IOMMU продолжает выводить видео на собственные разъёмы.
Но, допустим, я могу поставить в виртуалку ТугоVNC. Или, может, даже подглючить QXL в режиме второй видеокарты, включить в гостевой ОС дублирование экрана, и ходить в эту ВМ удалённо, как будто кроме этой QXL ничего и нет, но продолжать пользоваться ускорением от проброшенной карты?
Рабочая тема? Хм, а если я собрался в этой виртуалке играть - тоже рабочая схема? Или вместо VNC тогда лучше другой протокол рассмотреть (но и только, т.е. в целом, всё равно рабочая)?
Применять эту схему я, конечно, планирую для XP и 98 в качестве гостевых ОС, где даже если RDP-сервер и есть, то даже 2D-тесты в dxdiag быстрее проходят на QXL-"консоли".
Но, допустим, я могу поставить в виртуалку ТугоVNC. Или, может, даже подглючить QXL в режиме второй видеокарты, включить в гостевой ОС дублирование экрана, и ходить в эту ВМ удалённо, как будто кроме этой QXL ничего и нет, но продолжать пользоваться ускорением от проброшенной карты?
Рабочая тема? Хм, а если я собрался в этой виртуалке играть - тоже рабочая схема? Или вместо VNC тогда лучше другой протокол рассмотреть (но и только, т.е. в целом, всё равно рабочая)?
Применять эту схему я, конечно, планирую для XP и 98 в качестве гостевых ОС, где даже если RDP-сервер и есть, то даже 2D-тесты в dxdiag быстрее проходят на QXL-"консоли".
>>689149
ArcaOS лучше бери. UI, если что, всё равно сможешь перенастроить, зато там как раз в её V86-подсистеме исправлена работа с дисками 2ГБ+.
Образ есть на рутрекере. Но, хоть в раздаче и фигурирует каталог от вари, ИМХО ставить всё равно лучше в MSVPC/Parallels/Svista2004 (если что, там и ISO есть). Видеоускорение в варе всё равно вряд ли будет, максимум - поддержка VBE и то, на что хватает её одной.
Или, как вариант, - KVM, если сможешь откопать PCI-видеокарту с поддержкой полуоси и материснкую плату с IOMMU. Вообще, у тебя хост какой (матплата, ЦП, ОЗУ, ОС)?
>OS/2 4.5(2)
ArcaOS лучше бери. UI, если что, всё равно сможешь перенастроить, зато там как раз в её V86-подсистеме исправлена работа с дисками 2ГБ+.
Образ есть на рутрекере. Но, хоть в раздаче и фигурирует каталог от вари, ИМХО ставить всё равно лучше в MSVPC/Parallels/Svista2004 (если что, там и ISO есть). Видеоускорение в варе всё равно вряд ли будет, максимум - поддержка VBE и то, на что хватает её одной.
Или, как вариант, - KVM, если сможешь откопать PCI-видеокарту с поддержкой полуоси и материснкую плату с IOMMU. Вообще, у тебя хост какой (матплата, ЦП, ОЗУ, ОС)?
>>689391
Или любой другой гипервизор с IOMMU и поддерживающий эмуляцию всего остального железа, нужного для полуоси (=> не гиперв и не бхуйв).
Как кто-то уже, наверное, заметил, тред был возрождён, потому что стек "libvirt/QEMU/KVM/Linux" не является "серебряной пулей", и вообще, осложнения от 12309 ещё не прошли, поэтому кунилинукс тоже лучше бы прятать в виртуалки, а хост-окружение для KVM строить на базе солярки.
>Или, как вариант, - KVM,
Или любой другой гипервизор с IOMMU и поддерживающий эмуляцию всего остального железа, нужного для полуоси (=> не гиперв и не бхуйв).
Как кто-то уже, наверное, заметил, тред был возрождён, потому что стек "libvirt/QEMU/KVM/Linux" не является "серебряной пулей", и вообще, осложнения от 12309 ещё не прошли, поэтому кунилинукс тоже лучше бы прятать в виртуалки, а хост-окружение для KVM строить на базе солярки.
Вообще, аноны, раз уж на то пошло, предлагаю сравнительно обсудить варианты хост-окружений для современных гиперов. Перспективными мне видятся такие комбинации:
- QEMU/KVM/Solaris;
- Xen, но Dom0 на чём угодно, кроме Linux;
- Bhyve на всех поддерживаемых ядрах (и фряха, и солярка, и что там ещё... кроме OS X);
- QEMU/NVMM;
- OpenBSD vmm.
- QEMU/KVM/Solaris;
- Xen, но Dom0 на чём угодно, кроме Linux;
- Bhyve на всех поддерживаемых ядрах (и фряха, и солярка, и что там ещё... кроме OS X);
- QEMU/NVMM;
- OpenBSD vmm.
815 Кб, 720x720> win server + vmware
скоро третий десяток лет пойдет как у нас работает лол. удобно сук
>>689698
VMFS у тебя не выёбывается, что у неё места нихуя нет, когда его ещё с пол-диска?
С All Path Down без выключения затронутых ВМ справишься?
Термодатчики на хосте без IPMI увидишь?
VMFS у тебя не выёбывается, что у неё места нихуя нет, когда его ещё с пол-диска?
С All Path Down без выключения затронутых ВМ справишься?
Термодатчики на хосте без IPMI увидишь?
>>689698
А это, вложенная виртуализация одновременно с пробросом видеокарты и скрытием hypervisor bit в CPUID работает?
Если да, версия ESXi какая?
Много дополнительных директив в *.vmx вписывать приходится?
ESXi - с виду, лютейшая годнота, я даже хотел включить его в свою сборку WinPE для пары сценариев.
Но у него тоже есть свои нюансы (не касающиеся принципиальных вопросов лицензии/ИБ!), и так вот неожиданно они всплывают.
А это, вложенная виртуализация одновременно с пробросом видеокарты и скрытием hypervisor bit в CPUID работает?
Если да, версия ESXi какая?
Много дополнительных директив в *.vmx вписывать приходится?
ESXi - с виду, лютейшая годнота, я даже хотел включить его в свою сборку WinPE для пары сценариев.
Но у него тоже есть свои нюансы (не касающиеся принципиальных вопросов лицензии/ИБ!), и так вот неожиданно они всплывают.
67 Кб, 272x185>>689727
ты че злой такой? у нас нет видюх в контуре лол
>>689759
обычное дело, пробегаем раз в неделю скриптом, один хуй куб видит что линуксовая нода в дауне и раунд робином рестартит поды
такого пиздеца у нас не было даже лол, может потому что у нас админы нормально все настроили
в иб сказали видеть хост нельзя. галочки на иомму ставить нельзя.
>>689763
у нас воркстейшон чел) в вмх обычно только е1000е на вмхнет3 меняем, ну и по мелочи типа игровой режим у мыша настроить, чтобы не дергался, в остальном в любой непонятной ситуации контрол ц контрол в на другой хост. плюс вмку в скрипт автозапуска вписать и все!
ты че злой такой? у нас нет видюх в контуре лол
>>689759
> VMFS у тебя не выёбывается
обычное дело, пробегаем раз в неделю скриптом, один хуй куб видит что линуксовая нода в дауне и раунд робином рестартит поды
> С All Path Down
такого пиздеца у нас не было даже лол, может потому что у нас админы нормально все настроили
> Термодатчики на хосте
в иб сказали видеть хост нельзя. галочки на иомму ставить нельзя.
>>689763
у нас воркстейшон чел) в вмх обычно только е1000е на вмхнет3 меняем, ну и по мелочи типа игровой режим у мыша настроить, чтобы не дергался, в остальном в любой непонятной ситуации контрол ц контрол в на другой хост. плюс вмку в скрипт автозапуска вписать и все!
>>689794
Т.е. Windows Server в качестве хоста? А версия гипера какая?
Вообще, для экспериментального стенда думаю аналогичную тему забабахать: 2019 сервер с ролью HyperVV + VMWS 15.5.7 (или какая там первая версия поддерживала WHPX), коробокс и QEMU/WHPX с выбором версии по тому же принципу... а также все эти Bochs, DOSBox-X, PCem... всё пригодится. На этом стенде будут собираться и эталонные образы, и WinPE для разных архитектур, и эпплаенсы на базе дебича, включая конфиг для быстрого развёртывания KVM, в который переедет "прод" (первое время поживёт тут же), и другие экспериментальные гиперы во вложенном режиме.
Так что в окружение хоста пойдут всякие AIK и утилиты для работы с образами (ImDisk там всякие, Ext2Fsd...)... WinMerge, скорее всего.
>у нас воркстейшон чел)
Т.е. Windows Server в качестве хоста? А версия гипера какая?
Вообще, для экспериментального стенда думаю аналогичную тему забабахать: 2019 сервер с ролью HyperVV + VMWS 15.5.7 (или какая там первая версия поддерживала WHPX), коробокс и QEMU/WHPX с выбором версии по тому же принципу... а также все эти Bochs, DOSBox-X, PCem... всё пригодится. На этом стенде будут собираться и эталонные образы, и WinPE для разных архитектур, и эпплаенсы на базе дебича, включая конфиг для быстрого развёртывания KVM, в который переедет "прод" (первое время поживёт тут же), и другие экспериментальные гиперы во вложенном режиме.
Так что в окружение хоста пойдут всякие AIK и утилиты для работы с образами (ImDisk там всякие, Ext2Fsd...)... WinMerge, скорее всего.
>>689794
Я имел в виду немного не это, но вопрос тоже отпадает (хотя винда тоже проблемами с мониторингом страдает, пусть и не так жёстко).
Дело в том, что ESXi нихуя не поддерживает хосты, кроме перечисленных в HCL, а перечисленные - это только всякие HP, Dell, Supermicro и прочие OEM-серваки, у которых всегда есть IPMI, и, мало того, часто под конкретного производителя серверов нужно ещё и VIB фирменный доставлять.
То есть, даже если вдруг условный NUC хорошо по драйверам к ESXi подошёл - во-первых, это счастливая случайность, а во-вторых, даже так, на таком NUC на странице "Hardware Monitoring" вместо данных термодатчиков будет хуй и подпись: "Ой, а хде IPMI? Чёт я SEL не вижу!" - и то же самое на вкладке, где должны быть данные SMART.
>> Термодатчики на хосте
>в иб сказали видеть хост нельзя. галочки на иомму ставить нельзя.
Я имел в виду немного не это, но вопрос тоже отпадает (хотя винда тоже проблемами с мониторингом страдает, пусть и не так жёстко).
Дело в том, что ESXi нихуя не поддерживает хосты, кроме перечисленных в HCL, а перечисленные - это только всякие HP, Dell, Supermicro и прочие OEM-серваки, у которых всегда есть IPMI, и, мало того, часто под конкретного производителя серверов нужно ещё и VIB фирменный доставлять.
То есть, даже если вдруг условный NUC хорошо по драйверам к ESXi подошёл - во-первых, это счастливая случайность, а во-вторых, даже так, на таком NUC на странице "Hardware Monitoring" вместо данных термодатчиков будет хуй и подпись: "Ой, а хде IPMI? Чёт я SEL не вижу!" - и то же самое на вкладке, где должны быть данные SMART.
Да и с гостевыми ОС у VMWare так - на запуск каких-то ОС кроме тех, которые можно выбрать в метаданных ВМ, он просто не рассчитывался, и это территория чистой американо-русской рулетки.
Да, в принципе, то же самое с коробоксом. Ведь почему он не может запустить без VT-x/SVM полуось (даже в тех версиях, когда остальное - может)? Да потому что в его движке бинарной трансляции возможность работы гостя на втором кольце защиты (в отличие, например, от того же MSVPC) - просто не предусмотрена. Где-то ещё было написано, что у коробокса проблемы с эмуляцией нереального режима. Которые, согласно ВП, кстати, есть и у Bochs (!!!), и у ванильного досбокса (впрочем, ничего нового).
Да, в принципе, то же самое с коробоксом. Ведь почему он не может запустить без VT-x/SVM полуось (даже в тех версиях, когда остальное - может)? Да потому что в его движке бинарной трансляции возможность работы гостя на втором кольце защиты (в отличие, например, от того же MSVPC) - просто не предусмотрена. Где-то ещё было написано, что у коробокса проблемы с эмуляцией нереального режима. Которые, согласно ВП, кстати, есть и у Bochs (!!!), и у ванильного досбокса (впрочем, ничего нового).
2 Мб, 1200x800>>689958
конкретно по термо сенсорам у нас зоопарк решений, есть заббикс, прометеус, кое-где даже аида64 в рамдиск по скрипту репорты сохраняет. стандартного решения нет.
никогда блять больше не буду покупать пеки от штеуда.
>>689963
именно поэтому на клиентах у нас нет ничего кроме винды, убунты, дебиана, центоси и рхел
>>689930
на новейших 17.5, на большинстве 16.2, еще кстати есть windows 2008r2 с 15 и gtx560, вот там проброс видюххи и директ 3д на клиенте работает вообще без вопросов сука,я не понимаю как так
> винда тоже проблемами с мониторингом страдает
конкретно по термо сенсорам у нас зоопарк решений, есть заббикс, прометеус, кое-где даже аида64 в рамдиск по скрипту репорты сохраняет. стандартного решения нет.
> условный NUC
никогда блять больше не буду покупать пеки от штеуда.
> win server не видит intel ethernet nic
> на форумах интел саппорт угорает: а у вас его и нет, мы вам его отключили, гоните шекели за серверные мамки
> поменяли термопасту на проце
> забыли положить поролон под хдми порт
> проц сгорел нахуй
> на форуме угорают "надо было обращаться к опытным ремонтникам в наших сервисах"
>>689963
> территория чистой американо-русской рулетки
именно поэтому на клиентах у нас нет ничего кроме винды, убунты, дебиана, центоси и рхел
>>689930
>версия гипера
на новейших 17.5, на большинстве 16.2, еще кстати есть windows 2008r2 с 15 и gtx560, вот там проброс видюххи и директ 3д на клиенте работает вообще без вопросов сука,я не понимаю как так
>>689991
Понял... среди серьёзных решений легковесного нет, только эти CMS-подобные конструкторы.
Я как раз об этом... Что она и все известные её аналоги - не имеют режима службы: они либо работают только во время наличия активной админской терминальной сессии, либо запускаются через политику скриптов запуска/планировщик, но тогда сильно вероятны проблемы при появлении необходимости интерактивного взаимодействия с ними.
Вот! Алсо, вне зависимости от платформы ещё бывает вопрос, как быть в случае зоопарка платформ (и, как следствие, вплоть до уникального набора датчиков на каждом узле, кроме совсем уж стандартных, вроде coretemp-isa и термозоны ACPI, в которой часто бывают неточные данные).
Только IPMI... Но это не вариант для SOHO-сегмента, где у серверов из серверного, как правило, только стоечный ATX-корпус ExeGate.
>>689991
Вот спасибо за предупреждения! Потому что NUC любят брать под ESXi, и я недавно поступил так же.
>заббикс, прометеус
Понял... среди серьёзных решений легковесного нет, только эти CMS-подобные конструкторы.
>аида64
Я как раз об этом... Что она и все известные её аналоги - не имеют режима службы: они либо работают только во время наличия активной админской терминальной сессии, либо запускаются через политику скриптов запуска/планировщик, но тогда сильно вероятны проблемы при появлении необходимости интерактивного взаимодействия с ними.
>стандартного решения нет
Вот! Алсо, вне зависимости от платформы ещё бывает вопрос, как быть в случае зоопарка платформ (и, как следствие, вплоть до уникального набора датчиков на каждом узле, кроме совсем уж стандартных, вроде coretemp-isa и термозоны ACPI, в которой часто бывают неточные данные).
Только IPMI... Но это не вариант для SOHO-сегмента, где у серверов из серверного, как правило, только стоечный ATX-корпус ExeGate.
>>689991
>> условный NUC
>
>никогда блять больше не буду покупать пеки от штеуда.
>> win server не видит intel ethernet nic
>> на форумах интел саппорт угорает: а у вас его и нет, мы вам его отключили, гоните шекели за серверные мамки
>
>> поменяли термопасту на проце
>> забыли положить поролон под хдми порт
>> проц сгорел нахуй
>> на форуме угорают "надо было обращаться к опытным ремонтникам в наших сервисах"
Вот спасибо за предупреждения! Потому что NUC любят брать под ESXi, и я недавно поступил так же.
>множественные промышленные внедрения Workstation
Так, а вот теперь становится интересно позиционирование Workstation, как в период актуальности GSX, так и после его отмены.
>>3691038
>- варя 16-я
>- хост винда 10-ка
>- гость XP с 3D, даже в игры можно играть старые
>- если гость 7-ка +, то тем более с 3D проблем быть не должно.
Это всё замечательно, для XP-шных гостей ситуация начала ухудшаться вообще относительно недавно. Вы мне лучше скажите если сможете, что делать, если гость - старее даже 2к (это 98 или NT4).
Так... Сам, блин, отвлёкся, теперь за частью ответов придётся идти в- Твою дивизию! И за частью релейтеда, ради которого и выносилось обсуждение в отдельный тред, теперь тоже в архивач.
Зато случилось тут вчера покопаться в решениях виртуализации для Mac OS 9.x/10.3 и сформировать по ним положняк:
1. Connectix/Microsoft Virtual PC 6.1 - скорее всего, флагман, потеснить который таки не удалось. Имеет весь привычный функционал от своего x86-воплощения, и даже больше - например, пробрасывать USB-устройства Мака (вроде, у меня даже в NT4 заработало).
Но производительности полугигагерцового iBook G3 ему, конечно, не то чтобы хватает, поэтому заставить адекватно выводить звук у меня удалось только эту самую NT4, а 9x и FreeDOS для этого гипервизора эмулятора решения виртуализации тяжеловатыми.
2. Но, если говорить о гостевой 9x - здесь, по идее, нужно вспоминать семейство решений компании Insignia (SoftPC/SoftAT/RealPC и прочие SoftWindows), поскольку они вопросом обеспечения совместимости PPC-x86/Win-Mac занимались серьёзно - так, с одной стороны, их наработки легли даже в основу NTVDM на её версиях для других архитектур, использовались наработки этой компании, а с другой - по информации с англоязычной Википедии, Insignia знакомили с исходниками 98, т.е. экземпляр 98, находившийся на эталонных образах, присутствовавших в составе дистрибутивов SoftPC ветки SoftWindows - подвергся низкоуровневым оптимизациям со стороны разработчика данного эмулятора, поэтому в RealPC - 98 должна чувствовать себя легче, чем в MSVPC. И, согласно наблюдениям, это скорее действительно так, чем нет. Повозиться, конечно, пришлось, но оно того (не) стоило, потому что, оказывается, 98 не увидела сетевую карту! Причём в установщике были флажки компонентов, отвечающие именно за сетевое взаимодействие с гостевой ОС), но они были про всякое легаси,, и точно не про TCP/IP.
На 3 и 4 месте расположились, соответственно, MacBochs и относительно недавний порт DOSBox для 9front.
Общим их плюсом можно назвать, что они работают с образами формата DD. А минусом - что в Интернет эти виртуалки вытаскивать может быть ой как недолго, если вообще возможно. Так что, выходит, лучше всех, как правило, именно MSVPC, даже со всеми его подвохами.
>>3691038
>- варя 16-я
>- хост винда 10-ка
>- гость XP с 3D, даже в игры можно играть старые
>- если гость 7-ка +, то тем более с 3D проблем быть не должно.
Это всё замечательно, для XP-шных гостей ситуация начала ухудшаться вообще относительно недавно. Вы мне лучше скажите если сможете, что делать, если гость - старее даже 2к (это 98 или NT4).
Так... Сам, блин, отвлёкся, теперь за частью ответов придётся идти в- Твою дивизию! И за частью релейтеда, ради которого и выносилось обсуждение в отдельный тред, теперь тоже в архивач.
Зато случилось тут вчера покопаться в решениях виртуализации для Mac OS 9.x/10.3 и сформировать по ним положняк:
1. Connectix/Microsoft Virtual PC 6.1 - скорее всего, флагман, потеснить который таки не удалось. Имеет весь привычный функционал от своего x86-воплощения, и даже больше - например, пробрасывать USB-устройства Мака (вроде, у меня даже в NT4 заработало).
Но производительности полугигагерцового iBook G3 ему, конечно, не то чтобы хватает, поэтому заставить адекватно выводить звук у меня удалось только эту самую NT4, а 9x и FreeDOS для этого гипервизора эмулятора решения виртуализации тяжеловатыми.
2. Но, если говорить о гостевой 9x - здесь, по идее, нужно вспоминать семейство решений компании Insignia (SoftPC/SoftAT/RealPC и прочие SoftWindows), поскольку они вопросом обеспечения совместимости PPC-x86/Win-Mac занимались серьёзно - так, с одной стороны, их наработки легли даже в основу NTVDM на её версиях для других архитектур, использовались наработки этой компании, а с другой - по информации с англоязычной Википедии, Insignia знакомили с исходниками 98, т.е. экземпляр 98, находившийся на эталонных образах, присутствовавших в составе дистрибутивов SoftPC ветки SoftWindows - подвергся низкоуровневым оптимизациям со стороны разработчика данного эмулятора, поэтому в RealPC - 98 должна чувствовать себя легче, чем в MSVPC. И, согласно наблюдениям, это скорее действительно так, чем нет. Повозиться, конечно, пришлось, но оно того (не) стоило, потому что, оказывается, 98 не увидела сетевую карту! Причём в установщике были флажки компонентов, отвечающие именно за сетевое взаимодействие с гостевой ОС), но они были про всякое легаси,, и точно не про TCP/IP.
На 3 и 4 месте расположились, соответственно, MacBochs и относительно недавний порт DOSBox для 9front.
Общим их плюсом можно назвать, что они работают с образами формата DD. А минусом - что в Интернет эти виртуалки вытаскивать может быть ой как недолго, если вообще возможно. Так что, выходит, лучше всех, как правило, именно MSVPC, даже со всеми его подвохами.
>>690240
https://matejhorvat.si/en/mac/dosbox/index.htm
Хотя порт досбокса под 9 совсем ещё свеженький - возможностей у него здесь ещё меньше, чем у порта под Колибри. Эх, лучше бы,, хотя бы, dosemu портировали...
https://matejhorvat.si/en/mac/dosbox/index.htm
Хотя порт досбокса под 9 совсем ещё свеженький - возможностей у него здесь ещё меньше, чем у порта под Колибри. Эх, лучше бы,, хотя бы, dosemu портировали...
>>690241
На Колибри, в смысле - как расписано выше, было бы эффективнее. На PowerPC, ясное дело, ничего лучше динамической перекомпиляции быть не может хотя, конечно, надеюсь, что ошибаюсь, и KVM если не на G4, то хотя бы на G5, надеюсь, бывает.
>Эх, лучше бы,, хотя бы, dosemu портировали...
На Колибри, в смысле - как расписано выше, было бы эффективнее. На PowerPC, ясное дело, ничего лучше динамической перекомпиляции быть не может хотя, конечно, надеюсь, что ошибаюсь, и KVM если не на G4, то хотя бы на G5, надеюсь, бывает.
>>690240
PCEm / 86Box, с Voodoo.
> Вы мне лучше скажите если сможете, что делать, если гость - старее даже 2к (это 98 или NT4)
PCEm / 86Box, с Voodoo.
> Вы мне лучше скажите если сможете, что делать, если гость - старее даже 2к
увольняться к хуям с этого завода
>>690260
А кроме PCem, DOSBox-X и SoftGPU/qemu-3dfx вообще какие-нибудь варианты есть? Чтобы так де легковесно, как в Virtual PC 2007, но для большей легковесности - и с dgVoodoo.
>>690267
С каким 3,14159 на этом заводе сталкиваться ни приходилось - как раз с такими хидден-гем-ОС техдир_ка пошлёт далеко и надолго даже самого блатного клиента.
Так что увольняться оттуда действительно надо, но точно не поэтому. А увольняться из личного ЦОДа как-то грустно - тем более, когда заводские энергеты только этого и ждут, а иногда и добиваются.
Но сначала нужно ограбить локалку завода.
А кроме PCem, DOSBox-X и SoftGPU/qemu-3dfx вообще какие-нибудь варианты есть? Чтобы так де легковесно, как в Virtual PC 2007, но для большей легковесности - и с dgVoodoo.
>>690267
С каким 3,14159 на этом заводе сталкиваться ни приходилось - как раз с такими хидден-гем-ОС техдир_ка пошлёт далеко и надолго даже самого блатного клиента.
Так что увольняться оттуда действительно надо, но точно не поэтому. А увольняться из личного ЦОДа как-то грустно - тем более, когда заводские энергеты только этого и ждут, а иногда и добиваются.
Но сначала нужно ограбить локалку завода.
>>690287
Если что - это исключительно ради "трофея" "на память"!.. ну и там, вдруг ещё в будущем с этими же темами столкнусь. Так что вероятность любых sleeve стремится к нулю.
Если что - это исключительно ради "трофея" "на память"!.. ну и там, вдруг ещё в будущем с этими же темами столкнусь. Так что вероятность любых sleeve стремится к нулю.
449 Кб, 1024x576>>690287
это не твой личный цод. тащи все на авито и постепенно опускай цену, не продатся в течение полугода - значит и нахуй никму не нужно
т.е. ты не смог элементарно сделать себя гейткипером на мишн-критикал-компетенции, или им принципиально не нужны ключевые сотрудники, без которых все развалится?
> увольняться из личного ЦОДа
это не твой личный цод. тащи все на авито и постепенно опускай цену, не продатся в течение полугода - значит и нахуй никму не нужно
> когда заводские энергеты только этого и ждут
т.е. ты не смог элементарно сделать себя гейткипером на мишн-критикал-компетенции, или им принципиально не нужны ключевые сотрудники, без которых все развалится?
Как вы там, потомки?
Я на больничном сидел, но, к счастью, не крепко, поэтому было не до отдыха, санитарную обстановку в комнате активно улучшал... Уже забыл, о чём сюда написать хотел последний раз.
Я на больничном сидел, но, к счастью, не крепко, поэтому было не до отдыха, санитарную обстановку в комнате активно улучшал... Уже забыл, о чём сюда написать хотел последний раз.
>>690240
Походу, единственная базовая база.
Никакие хитрые оптимизации сборочки 98 от создателей RealPC от тормозов звука в 9x не спасают, а спасает - использование в виртуалке NT4. Насчёт 2000 не знаю, но для XP возможностей эмуляции уже маловато. Насчёт 3.1 тоже не представляю, но в досовской виртуалке лучше выключить звук совсем.
ReactOS в нём установился, но с совсем неотзывчивой мышкой, KolibriOS - даже не стал грузиться, 9 (тот, который план) - крашнул виртуалку...
А из того, что можно эмулирнуть x86-го на Маке:
- NT4 - вроде, даже проброшенные USB-порты подхватывает;
- 2к - с ней непонятно, но маловероятно;
- FreeDOS - без звука, зато с сетью;
- 3.11 - тоже непонятно, может, будет немного лучше 9x.
- Debian 3.1 или что-то ещё на 2.6.18, *BSD или солярка версий схожего возраста... но это попса;
-Точно! Чуть не забыл! Нужно там попробовать ArcaOS погонять.
Ну, и для офлайновых игр, возможно, имеет смысл этот порт досбокса 0.65.)
>Connectix/Microsoft Virtual PC 6.1
Походу, единственная базовая база.
Никакие хитрые оптимизации сборочки 98 от создателей RealPC от тормозов звука в 9x не спасают, а спасает - использование в виртуалке NT4. Насчёт 2000 не знаю, но для XP возможностей эмуляции уже маловато. Насчёт 3.1 тоже не представляю, но в досовской виртуалке лучше выключить звук совсем.
ReactOS в нём установился, но с совсем неотзывчивой мышкой, KolibriOS - даже не стал грузиться, 9 (тот, который план) - крашнул виртуалку...
А из того, что можно эмулирнуть x86-го на Маке:
- NT4 - вроде, даже проброшенные USB-порты подхватывает;
- 2к - с ней непонятно, но маловероятно;
- FreeDOS - без звука, зато с сетью;
- 3.11 - тоже непонятно, может, будет немного лучше 9x.
- Debian 3.1 или что-то ещё на 2.6.18, *BSD или солярка версий схожего возраста... но это попса;
-Точно! Чуть не забыл! Нужно там попробовать ArcaOS погонять.
Ну, и для офлайновых игр, возможно, имеет смысл этот порт досбокса 0.65.)
>>691587
Тем более, оно там есть нативно. Ах да, как раз солярка, как и BeOS, там не пойдёт.
>- Debian 3.1 или что-то ещё на 2.6.18, *BSD или солярка версий схожего возраста... но это попса;
Тем более, оно там есть нативно. Ах да, как раз солярка, как и BeOS, там не пойдёт.
>>691587
О, точно, можно x86-варианты CE там попробовать погонять! Где там мой платформостроитель образы с 4пда?
О, точно, можно x86-варианты CE там попробовать погонять! Где там мой платформостроитель образы с 4пда?
>>689991
Вот благодарю за предупреждение... Я, правда, сразу не понял, что это и к моему NUC7i7BNB относится - минус ночь на 2019 eval (скачивание, установка, не очень корректный ребут... и карта отобразилась в device manager, даже без значков, но "для данного устройств не установлены драйверы"). Мог бы, наверное, из принципа с Snappy Driver Installer попвордиться, но решил LTSC 1809 (как последнюю, где можно RemoteFX хотя бы через помершелл включать) ставить.
Но интерес к их Compute Stick точнее, в целом к x86 форм-фактора stick PC, которого больше особо-то ни от кого и не было всё равно не пропал.
С 1809 пока полёт нормальный: сейчас
и гиперв включил,
и варя 15.5.7 с даунгрейдфайлов качается,
чай допью - пойду коробокс 6.0 на wayback отлавливать (ибо лежат с 402)
и версию QEMU выбирать, чтобы и WHPX, и нужные фичи не отменены.
Может, ещё хуёкер-диктоп поставлю, чтобы pmbootstrap и live-build в нём запускать (если, конечно, они от WSL не будут каличные сборки выдавать сблёвывать). И, конечно, всю классику:
DOSBox-X - самый последний и последний для хостов с RISC OS,
Bochs - последний, запускающийся в HX (скорее всего, самый последний 32-разрядный),
PCem - самый последний из оригинальной ветки...
Может, ещё Virtual PC 2007 в режиме бинарной трансляции... и ещё чего более обскьюрное, не только x86. И прочие среды сборки, вроде того же платформ-блидера.
Да, все эти окружения пригодятся. Как минимум, чтобы выбирать по лучшей совместимости с конкретными гостями и по необходимому для опр. задачи функционалу. А вообще, это будет, в первую очередь, "кухня" эталонных образов... а в следующую - пункт временного размещения и "прода", и экспериментальных окружений.
>> условный NUC
>
>никогда блять больше не буду покупать пеки от штеуда.
>> win server не видит intel ethernet nic
>> на форумах интел саппорт угорает: а у вас его и нет, мы вам его отключили, гоните шекели за серверные мамки
>
>> поменяли термопасту на проце
>> забыли положить поролон под хдми порт
>> проц сгорел нахуй
>> на форуме угорают "надо было обращаться к опытным ремонтникам в наших сервисах"
Вот благодарю за предупреждение... Я, правда, сразу не понял, что это и к моему NUC7i7BNB относится - минус ночь на 2019 eval (скачивание, установка, не очень корректный ребут... и карта отобразилась в device manager, даже без значков, но "для данного устройств не установлены драйверы"). Мог бы, наверное, из принципа с Snappy Driver Installer попвордиться, но решил LTSC 1809 (как последнюю, где можно RemoteFX хотя бы через помершелл включать) ставить.
Но интерес к их Compute Stick точнее, в целом к x86 форм-фактора stick PC, которого больше особо-то ни от кого и не было всё равно не пропал.
С 1809 пока полёт нормальный: сейчас
и гиперв включил,
и варя 15.5.7 с даунгрейдфайлов качается,
чай допью - пойду коробокс 6.0 на wayback отлавливать (ибо лежат с 402)
и версию QEMU выбирать, чтобы и WHPX, и нужные фичи не отменены.
Может, ещё хуёкер-диктоп поставлю, чтобы pmbootstrap и live-build в нём запускать (если, конечно, они от WSL не будут каличные сборки выдавать сблёвывать). И, конечно, всю классику:
DOSBox-X - самый последний и последний для хостов с RISC OS,
Bochs - последний, запускающийся в HX (скорее всего, самый последний 32-разрядный),
PCem - самый последний из оригинальной ветки...
Может, ещё Virtual PC 2007 в режиме бинарной трансляции... и ещё чего более обскьюрное, не только x86. И прочие среды сборки, вроде того же платформ-блидера.
Да, все эти окружения пригодятся. Как минимум, чтобы выбирать по лучшей совместимости с конкретными гостями и по необходимому для опр. задачи функционалу. А вообще, это будет, в первую очередь, "кухня" эталонных образов... а в следующую - пункт временного размещения и "прода", и экспериментальных окружений.
>>689991
Вот благодарю за предупреждение... Я, правда, сразу не понял, что это и к моему NUC7i7BNB относится - минус ночь на 2019 eval (скачивание, установка, не очень корректный ребут... и карта отобразилась в device manager, даже без значков, но "для данного устройств не установлены драйверы"). Мог бы, наверное, из принципа с Snappy Driver Installer попвордиться, но решил LTSC 1809 (как последнюю, где можно RemoteFX хотя бы через помершелл включать) ставить.
Но интерес к их Compute Stick точнее, в целом к x86 форм-фактора stick PC, которого больше особо-то ни от кого и не было всё равно не пропал.
С 1809 пока полёт нормальный: сейчас
и гиперв включил,
и варя 15.5.7 с даунгрейдфайлов качается,
чай допью - пойду коробокс 6.0 на wayback отлавливать (ибо лежат с 402)
и версию QEMU выбирать, чтобы и WHPX, и нужные фичи не отменены.
Может, ещё хуёкер-диктоп поставлю, чтобы pmbootstrap и live-build в нём запускать (если, конечно, они от WSL не будут каличные сборки выдавать сблёвывать). И, конечно, всю классику:
DOSBox-X - самый последний и последний для хостов с RISC OS,
Bochs - последний, запускающийся в HX (скорее всего, самый последний 32-разрядный),
PCem - самый последний из оригинальной ветки...
Может, ещё Virtual PC 2007 в режиме бинарной трансляции... и ещё чего более обскьюрное, не только x86. И прочие среды сборки, вроде того же платформ-блидера.
Да, все эти окружения пригодятся. Как минимум, чтобы выбирать по лучшей совместимости с конкретными гостями и по необходимому для опр. задачи функционалу. А вообще, это будет, в первую очередь, "кухня" эталонных образов... а в следующую - пункт временного размещения и "прода", и экспериментальных окружений.
>> условный NUC
>
>никогда блять больше не буду покупать пеки от штеуда.
>> win server не видит intel ethernet nic
>> на форумах интел саппорт угорает: а у вас его и нет, мы вам его отключили, гоните шекели за серверные мамки
>
>> поменяли термопасту на проце
>> забыли положить поролон под хдми порт
>> проц сгорел нахуй
>> на форуме угорают "надо было обращаться к опытным ремонтникам в наших сервисах"
Вот благодарю за предупреждение... Я, правда, сразу не понял, что это и к моему NUC7i7BNB относится - минус ночь на 2019 eval (скачивание, установка, не очень корректный ребут... и карта отобразилась в device manager, даже без значков, но "для данного устройств не установлены драйверы"). Мог бы, наверное, из принципа с Snappy Driver Installer попвордиться, но решил LTSC 1809 (как последнюю, где можно RemoteFX хотя бы через помершелл включать) ставить.
Но интерес к их Compute Stick точнее, в целом к x86 форм-фактора stick PC, которого больше особо-то ни от кого и не было всё равно не пропал.
С 1809 пока полёт нормальный: сейчас
и гиперв включил,
и варя 15.5.7 с даунгрейдфайлов качается,
чай допью - пойду коробокс 6.0 на wayback отлавливать (ибо лежат с 402)
и версию QEMU выбирать, чтобы и WHPX, и нужные фичи не отменены.
Может, ещё хуёкер-диктоп поставлю, чтобы pmbootstrap и live-build в нём запускать (если, конечно, они от WSL не будут каличные сборки выдавать сблёвывать). И, конечно, всю классику:
DOSBox-X - самый последний и последний для хостов с RISC OS,
Bochs - последний, запускающийся в HX (скорее всего, самый последний 32-разрядный),
PCem - самый последний из оригинальной ветки...
Может, ещё Virtual PC 2007 в режиме бинарной трансляции... и ещё чего более обскьюрное, не только x86. И прочие среды сборки, вроде того же платформ-блидера.
Да, все эти окружения пригодятся. Как минимум, чтобы выбирать по лучшей совместимости с конкретными гостями и по необходимому для опр. задачи функционалу. А вообще, это будет, в первую очередь, "кухня" эталонных образов... а в следующую - пункт временного размещения и "прода", и экспериментальных окружений.
>>694095
Пока пвордил, выяснилось следующее:
1. Хотя 1809 уже умеет WHPX, варя хочет, как минимум, 2004, или, если смотреть только на LTSC - 21H2.
2. Коробокс на 21H2 уже придётся ставить от 6.1, а не от 6.0.
3. WHPX не поддерживает вложенную виртуализацию. У меня получилось включить её только для машин, настроенных именно через фронтенд самого Hyper-V, отдельно для каждой ВМ через помершелл.
Так что ставить 1809 в варю, как я сначала хотел, без понту. Не судьба RemoteFX на проде потыкать.( Ну ничего, для виндовых виртуалок варя и есть, а RemoteFX - это и про обычный RDP, а не только про проброс графических API в виртуалки Hyper-V.
Пока пвордил, выяснилось следующее:
1. Хотя 1809 уже умеет WHPX, варя хочет, как минимум, 2004, или, если смотреть только на LTSC - 21H2.
2. Коробокс на 21H2 уже придётся ставить от 6.1, а не от 6.0.
3. WHPX не поддерживает вложенную виртуализацию. У меня получилось включить её только для машин, настроенных именно через фронтенд самого Hyper-V, отдельно для каждой ВМ через помершелл.
Так что ставить 1809 в варю, как я сначала хотел, без понту. Не судьба RemoteFX на проде потыкать.( Ну ничего, для виндовых виртуалок варя и есть, а RemoteFX - это и про обычный RDP, а не только про проброс графических API в виртуалки Hyper-V.
Так что, в итоге, конфиг моего стенда такой:
NUC7i7BNH
LTSC 21H2
Включены компоненты Hyper-V, "Платформа низкоуровневой оболочки Windows".
Workstation 15.5.7
Коробокс 6.1.50
QEMU 5.1.0 x64
NUC7i7BNH
LTSC 21H2
Включены компоненты Hyper-V, "Платформа низкоуровневой оболочки Windows".
Workstation 15.5.7
Коробокс 6.1.50
QEMU 5.1.0 x64
>>695114
P.S. 4. Для последний версии Android-x86 нужно следующее:
- скачать особый образ;
- поставить версию совместимости конфига не ниже Workstation 12 (!!!).
Иначе будет грузиться только с nomodeset. А ещё непонятно, какого хуя он перестал грузиться после вырубания всех пакетов com.google.android.*.
P.S. 4. Для последний версии Android-x86 нужно следующее:
- скачать особый образ;
- поставить версию совместимости конфига не ниже Workstation 12 (!!!).
Иначе будет грузиться только с nomodeset. А ещё непонятно, какого хуя он перестал грузиться после вырубания всех пакетов com.google.android.*.
>>695192
А ты сможешь на лине одновременно вокрстейшон+коробокс+QEMU, и всё это в Xen Dom0 подглючить вокрстеёшон и коробокс к Xen как девайс-модели если, конечно, Xen ещё хоть где-то не рушится от установщика 10 и не протормаживает в UEFI сильнее, чем вложенный KVM в реальном режиме?
Что важнее, ADK и WinCE Platform DeBuilder в вайне запустить сможешь?
А ты сможешь на лине одновременно вокрстейшон+коробокс+QEMU, и всё это в Xen Dom0 подглючить вокрстеёшон и коробокс к Xen как девайс-модели если, конечно, Xen ещё хоть где-то не рушится от установщика 10 и не протормаживает в UEFI сильнее, чем вложенный KVM в реальном режиме?
Что важнее, ADK и WinCE Platform DeBuilder в вайне запустить сможешь?
>>695192
Тем более. Думаешь, зачем ещё RemoteFX? Не для САПРов же всяких.
>Венда это не более чем софт для игрулек
Тем более. Думаешь, зачем ещё RemoteFX? Не для САПРов же всяких.
Zvzдц, не успел привести свой гибридный хост в состояние, пригодное к обживанию, как он по рабочей задаче пригодился. Эхх, на сколько же страниц опустился тред, пока я пордил виртуальный кластер для задачи все вечера и свободное от созвонов время (которого было чуть более чем нихуя).
Сейчас сформулирую и расскажу, во что вляпался. Впрочем, всё из этого - более-менее терпимое, в отличие от, на удивление, ESXi.
Сейчас сформулирую и расскажу, во что вляпался. Впрочем, всё из этого - более-менее терпимое, в отличие от, на удивление, ESXi.
>А хуйпер-VVV не так уж и бестолков... когда рядом есть альтернативная device model к нему от вари.
>>690501
Смочь-то-смог, но от аморальщины со стороны техдира это нихуя не спасло. Ключевые сотрудники им, конечно, нужны, и именно тот факт, что без меня всё развалится - пока и спасает. Но, боюсь, ключевым словом тут вполне может быть "пока", так что главное - успеть, пока ещё можно уйти реально самому. И чтобы внутуре всё развалилось, ибо никакая топовая должность нихуя не даёт права ссорить подчинённых, да ещё так изподтишка.
>т.е. ты не смог элементарно сделать себя гейткипером на мишн-критикал-компетенции, или им принципиально не нужны ключевые сотрудники, без которых все развалится?
Смочь-то-смог, но от аморальщины со стороны техдира это нихуя не спасло. Ключевые сотрудники им, конечно, нужны, и именно тот факт, что без меня всё развалится - пока и спасает. Но, боюсь, ключевым словом тут вполне может быть "пока", так что главное - успеть, пока ещё можно уйти реально самому. И чтобы внутуре всё развалилось, ибо никакая топовая должность нихуя не даёт права ссорить подчинённых, да ещё так изподтишка.
>>682784 (OP)
Крутейший гайд по GPU passthrough для линуксобояр:
https://github.com/bryansteiner/gpu-passthrough-tutorial
Крутейший гайд по GPU passthrough для линуксобояр:
https://github.com/bryansteiner/gpu-passthrough-tutorial
>>697359
Тебе не особо нужен проброс GPU на ноутбуке/проброс встроенной GPU в виртуалку, я думаю.
Тебе не особо нужен проброс GPU на ноутбуке/проброс встроенной GPU в виртуалку, я думаю.
>>697174
Прикольно. Может расписать гайд как сунуть невидию ртыкс в фряшный бхуйв? То еще веселье, но однако рабочее.
Прикольно. Может расписать гайд как сунуть невидию ртыкс в фряшный бхуйв? То еще веселье, но однако рабочее.
>>697369
На самом деле, в ютюбе есть туториалы, где делается пропброс на ноуте, с одной видяхой. Ну там типа происходит переключение на лету. Для десктопов тоже подходит.
На самом деле, в ютюбе есть туториалы, где делается пропброс на ноуте, с одной видяхой. Ну там типа происходит переключение на лету. Для десктопов тоже подходит.
>>697369
Да, там мне нужен гипервизор II типа. Так что:
1. приходится выбирать между опенсорсным, стабильным и тем, который и то, и другое, и даже blockjob делает хорошо умеет заставлять виртуалку идентифицировать себя как физику, пробрасывать графические API не умеет, поэтому лже-физика получается с VBE вместо видеодрайвера;
2. когда виртуализация применяется только ради одной гостевой ОС и только, потому что у неё нет драйверов на железо хоста (по сути, гипервизор II типа в этом случае таки выполняет задачу гипервизора I типа), то приходится выбирать хост-окружение, а потом либо чистить его до уровня / у ESXi, либо мириться с тем, что оно блоатед и нестабильное (в случае винды/линукса) или не имеет дров на всё железо, особенно то, которое должно обеспечивать гипервизору II типа эмуляцию своего виртуального аналога (например, в случае коробокса на фряхе/солярке).
>>697456
И от такого я бы, конечно, тоже не отказался.
Да, там мне нужен гипервизор II типа. Так что:
1. приходится выбирать между опенсорсным, стабильным и тем, который и то, и другое, и даже blockjob делает хорошо умеет заставлять виртуалку идентифицировать себя как физику, пробрасывать графические API не умеет, поэтому лже-физика получается с VBE вместо видеодрайвера;
2. когда виртуализация применяется только ради одной гостевой ОС и только, потому что у неё нет драйверов на железо хоста (по сути, гипервизор II типа в этом случае таки выполняет задачу гипервизора I типа), то приходится выбирать хост-окружение, а потом либо чистить его до уровня / у ESXi, либо мириться с тем, что оно блоатед и нестабильное (в случае винды/линукса) или не имеет дров на всё железо, особенно то, которое должно обеспечивать гипервизору II типа эмуляцию своего виртуального аналога (например, в случае коробокса на фряхе/солярке).
>>697456
И от такого я бы, конечно, тоже не отказался.
>>697480
Похоже я ошибся, там был разговор про ноут с игровой видяхой и с процом со встроенной видяхой...
>И от такого я бы, конечно, тоже не отказался.
Похоже я ошибся, там был разговор про ноут с игровой видяхой и с процом со встроенной видяхой...
>>695192
большая часть инженерного софта доступна только на винде увы
большая часть инженерного софта доступна только на винде увы
Что-то появилась мысль - можно ли считать Bochs "профессиональным аналогом" PCem? Функционал у них, вроде, почти такой же (за исключением того, что Bochs не ориентирован на аутентичные конфиги, но, в целом, по существу, они сопоставимы).
Или, может, DOSBox-X его в вопросе профессиональности давно уже переплюнул?
Или, может, DOSBox-X его в вопросе профессиональности давно уже переплюнул?
Впрочем, думаю, бенчмарки покажут.
Из того, что могу сказать уже сейчас - DOSBox-X медленнее PCem (либо по умолчанию слишком сильно подкручен под аутентичность).
Просто, по времени установки ME в тот и в другой при сопоставимом эмулируемом конфиге, в PCem ей хватает 30-40 минут, а в DOSBox-X - чуть ли не 4 часа.
Впрочем, с другой стороны, PCem нихуя не умеет в "паравиртуальный 3Dfx" через dgVoodoo и патченную glide2x.dll/GLIDE2X.OVL, так что DOSBox-X точно есть киллер-фича. А, и то, что он официально поддерживает HX... что, между прочим, можно использовать как костыль для запуска 3.x-9x под чистым фридосом!
Из того, что могу сказать уже сейчас - DOSBox-X медленнее PCem (либо по умолчанию слишком сильно подкручен под аутентичность).
Просто, по времени установки ME в тот и в другой при сопоставимом эмулируемом конфиге, в PCem ей хватает 30-40 минут, а в DOSBox-X - чуть ли не 4 часа.
Впрочем, с другой стороны, PCem нихуя не умеет в "паравиртуальный 3Dfx" через dgVoodoo и патченную glide2x.dll/GLIDE2X.OVL, так что DOSBox-X точно есть киллер-фича. А, и то, что он официально поддерживает HX... что, между прочим, можно использовать как костыль для запуска 3.x-9x под чистым фридосом!
996 Кб, 1280x853Сап, виртуач. Как известно windows containers поддерживают ТОЛЬКО CLI. А GUI не поддерживает. Максимум что мне удалось запустить гуёвое это FAR MANAGER с псевдогуем. Появилась мысль накатить в контейнер X-server виндову версию и попытаться подключиться по RDP как это работает в Linux containers. Кто-нибудь из анонов экспериментировал в данном направлении?
44 Кб, 451x545>>700524
Ставишь докер, клацаешь на него в трее пкм, потом жамкаешь как на пикрелейтед
https://xakep.ru/2016/03/31/windows-containers/
https://habr.com/ru/companies/ruvds/articles/901004/?ysclid=mmeueekax9851752908
https://learn.microsoft.com/ru-ru/virtualization/windowscontainers/about/
>что это?
Ставишь докер, клацаешь на него в трее пкм, потом жамкаешь как на пикрелейтед
https://xakep.ru/2016/03/31/windows-containers/
https://habr.com/ru/companies/ruvds/articles/901004/?ysclid=mmeueekax9851752908
https://learn.microsoft.com/ru-ru/virtualization/windowscontainers/about/
Есть два стула:
Есть один физический комп, в теории в кластер будут добавлены еще 2.
Proxmox или MaaS? Или вообще на голом KVM/Ubuntu Server заехать? Всё-таки прохмох можно терраформом манагерить.
Есть один физический комп, в теории в кластер будут добавлены еще 2.
Proxmox или MaaS? Или вообще на голом KVM/Ubuntu Server заехать? Всё-таки прохмох можно терраформом манагерить.
>>700507
Гугли WSL + XMing, должно работать по аналогии.
Гугли WSL + XMing, должно работать по аналогии.
>>700507
Во-первых, внутри контейнера не X-сервер, а X-клиенты должны быть. Т.е. приложения, собранные под винду, но зачем-то пытающиеся отображаться через иксы. Из такого я видел только демки на сайте Xming.
А X-сервер в этом случае нужно ставить, как раз, на хост/тонкий клиент.
В третьих - согласен с >>700562, потому что в сборке для контейнеров (Nano Server) нет даже такой базированной базы, как WoW64.
Во-первых, внутри контейнера не X-сервер, а X-клиенты должны быть. Т.е. приложения, собранные под винду, но зачем-то пытающиеся отображаться через иксы. Из такого я видел только демки на сайте Xming.
А X-сервер в этом случае нужно ставить, как раз, на хост/тонкий клиент.
В третьих - согласен с >>700562, потому что в сборке для контейнеров (Nano Server) нет даже такой базированной базы, как WoW64.
>>700784
THIS. А лучше - libvirt/KVM/Alpine. А ещё лучше - погоняй Bhyve, libvirt/NVMM/NetBSD и, если для твоих задач хватит функционала, vmx в 9front и vmm в OpenBSD. Да, QEMU сейчас аналогов нет, но 12309-му ядру аналоги нужны отчаянно.
Если у тебя будет именно KVM - в качестве вебки ставь virtlyst (есть в виде Docker-образа), если Bhyve - консольную управлялку vm-bhyve (CBSD, при всей её крутости и уважении к разработчикам, кажется слегка оверкилл, и она создаёт кучу своих сущностей вместо того, чтобы пытаться подхватывать существующие... прямо, как OpenNebula, так что CBSD/MyBee/ClonOS ставь, только если сильно хочешь вебку).
Но это всё - только если тебе для себя, и ты не против орекстрировать ВМ ручками.
Если же тебе нужен ESXi-подобный эпплаенс на базе KVM (или просто свободный), и стоять он будет не в домашней серверной, а то и админиться не совсем юниксоидом - да, Proxmox сойдёт. Но повторю мою претензию к нему - работает мимо libvirt.
Ещё в этом направлении можно посмотреть:
- SmartOS/OmniOS;
- ClonOS/MyBee;
- XCP-ng (редфлаг: XAPI в качестве управлялки, который слишком stateful);
- XigmaNAS (а может, и TrueNAS Core) - в них есть коробокс с вебкой, лол.
OpenStack, oVirt тебе, скорее всего, нинужны, OpenNebula со своей логикой работы БД точно нинужна вообще никому, кроме российских, khm, продавцов линукса.
Если вдруг нагуглишь Kimchi - знай, что она не сама по себе, а как модуль для Wok, который ставить будет так же муторно, как CMS-ку... а если ты к такому готов, то модуль для работы с libvirt вполне есть и у Cockpit.
>KVM/Ubuntu Server
THIS. А лучше - libvirt/KVM/Alpine. А ещё лучше - погоняй Bhyve, libvirt/NVMM/NetBSD и, если для твоих задач хватит функционала, vmx в 9front и vmm в OpenBSD. Да, QEMU сейчас аналогов нет, но 12309-му ядру аналоги нужны отчаянно.
Если у тебя будет именно KVM - в качестве вебки ставь virtlyst (есть в виде Docker-образа), если Bhyve - консольную управлялку vm-bhyve (CBSD, при всей её крутости и уважении к разработчикам, кажется слегка оверкилл, и она создаёт кучу своих сущностей вместо того, чтобы пытаться подхватывать существующие... прямо, как OpenNebula, так что CBSD/MyBee/ClonOS ставь, только если сильно хочешь вебку).
Но это всё - только если тебе для себя, и ты не против орекстрировать ВМ ручками.
Если же тебе нужен ESXi-подобный эпплаенс на базе KVM (или просто свободный), и стоять он будет не в домашней серверной, а то и админиться не совсем юниксоидом - да, Proxmox сойдёт. Но повторю мою претензию к нему - работает мимо libvirt.
Ещё в этом направлении можно посмотреть:
- SmartOS/OmniOS;
- ClonOS/MyBee;
- XCP-ng (редфлаг: XAPI в качестве управлялки, который слишком stateful);
- XigmaNAS (а может, и TrueNAS Core) - в них есть коробокс с вебкой, лол.
OpenStack, oVirt тебе, скорее всего, нинужны, OpenNebula со своей логикой работы БД точно нинужна вообще никому, кроме российских, khm, продавцов линукса.
Если вдруг нагуглишь Kimchi - знай, что она не сама по себе, а как модуль для Wok, который ставить будет так же муторно, как CMS-ку... а если ты к такому готов, то модуль для работы с libvirt вполне есть и у Cockpit.
>>700454
С другой стороны... Bochs явно не умеет симулировать горячую замену единственного ЦП с выниманием прямо из-под кулера в остановленном времени, как это делает PCem на ОПвебмке.
С другой стороны... Bochs явно не умеет симулировать горячую замену единственного ЦП с выниманием прямо из-под кулера в остановленном времени, как это делает PCem на ОПвебмке.
758 Кб, 700x700>>700829
есть альтернативы?
база есть LTSC
https://hub.docker.com/r/microsoft/windows
>>700562
Чтобы изолированно устанавливать windows-приложения и не привязываться к ОС и железу. Можно конечно городить костыли и пускать виндовые прилаги через wine в Linux контейнерах, но тут троллейбус.джпг
>но зачем-то пытающиеся отображаться через иксы.
есть альтернативы?
>в сборке для контейнеров (Nano Server) нет даже такой базированной базы
база есть LTSC
https://hub.docker.com/r/microsoft/windows
>>700562
>Но зачем?
Чтобы изолированно устанавливать windows-приложения и не привязываться к ОС и железу. Можно конечно городить костыли и пускать виндовые прилаги через wine в Linux контейнерах, но тут троллейбус.джпг
>>701724
Как говорил наш бывший CTO: "Не использовать данное ПО". То есть - использовать внутри Windows-контейнера приложения, у которых есть нормальные виндовые порты, не требующие таких костылей.
Для Linux-контейнеров - ставить Xming на хост или конкретно твоего тонкого клиента. Но лучше - на хост, чтобы потом ходить на него по RDP, а то в чистом X11 не предусмотрено восстановления состояния клиентов при обрыве связи с сервером.
>есть альтернативы?
Как говорил наш бывший CTO: "Не использовать данное ПО". То есть - использовать внутри Windows-контейнера приложения, у которых есть нормальные виндовые порты, не требующие таких костылей.
Для Linux-контейнеров - ставить Xming на хост или конкретно твоего тонкого клиента. Но лучше - на хост, чтобы потом ходить на него по RDP, а то в чистом X11 не предусмотрено восстановления состояния клиентов при обрыве связи с сервером.
129 Кб, 850x1445>>701724
Единственное бескостыльное решение для тебя это виртуалка.
Linux просто лучше, поэтому в нём работает то, что индусы в микрослопе заставить работать не смогли. Поэтому не надо на Linux смотреть и гадать, как такое сделать в шиндовсе. Никак.
Единственное бескостыльное решение для тебя это виртуалка.
Linux просто лучше, поэтому в нём работает то, что индусы в микрослопе заставить работать не смогли. Поэтому не надо на Linux смотреть и гадать, как такое сделать в шиндовсе. Никак.
>>701782
Так это всё CLI серверная параша
Ну заводить зоопарк виртуалок под каждый условный Фотошоп, Ворд, Ексель такое себе. Короче наебать хитрых индусов, которые хотят чтобы ты платил за лицуху и каждый раз ебался с нажатием кнопки ДАЛЕЕ при переезде на новое железо\сносе забагованной ОСи не получится. Я понял тебя, анон.
> использовать внутри Windows-контейнера приложения, у которых есть нормальные виндовые порты
Так это всё CLI серверная параша
>Единственное бескостыльное решение для тебя это виртуалка.
Ну заводить зоопарк виртуалок под каждый условный Фотошоп, Ворд, Ексель такое себе. Короче наебать хитрых индусов, которые хотят чтобы ты платил за лицуху и каждый раз ебался с нажатием кнопки ДАЛЕЕ при переезде на новое железо\сносе забагованной ОСи не получится. Я понял тебя, анон.
>>701962
Почему, вполне нормально. Да и тебе не обязательно под каждый новый попожоп новую виртуалку заводить, для всякой лицушной дряни одну большую помойку оставь и пусть там всё булькает и кривляеся, для удалёнки ещё одну чистую виртуалку, и может одну максимально изолированную чтобы в ней какой-нибудь странный исошник запустить, всё, куда больше-то. Потом всю эту виртуалку целиком на новый комп передвинешь.
Почему, вполне нормально. Да и тебе не обязательно под каждый новый попожоп новую виртуалку заводить, для всякой лицушной дряни одну большую помойку оставь и пусть там всё булькает и кривляеся, для удалёнки ещё одну чистую виртуалку, и может одну максимально изолированную чтобы в ней какой-нибудь странный исошник запустить, всё, куда больше-то. Потом всю эту виртуалку целиком на новый комп передвинешь.
1,2 Мб, 1302x1842>>701962
Ну я типа могу такой же аргумент и про контейнеры представить, "кококо, под каждый условный фотожоп образ делать, кудах". Так что хз, странная претензия.
Другое дело, что каждая виртуалка 1. жрёт память как отдельная операционка 2. запускается по времени как отдельная операционка.
Но ты вроде бы это как проблемы не перечислял, так что хуй тя знает, может, тебе это некритично.
Но главное, это что спермоконтейнеры тоже один хрен жрут памяти как отдельная операционка и запускаются по времени как отдельная операционка. Так что даже если бы ты их каким-то чудом допилил для своей задачи, ты бы ничего особо не выиграл. Такие дела, да.
>Ну заводить зоопарк виртуалок под каждый условный Фотошоп, Ворд, Ексель такое себе.
Ну я типа могу такой же аргумент и про контейнеры представить, "кококо, под каждый условный фотожоп образ делать, кудах". Так что хз, странная претензия.
Другое дело, что каждая виртуалка 1. жрёт память как отдельная операционка 2. запускается по времени как отдельная операционка.
Но ты вроде бы это как проблемы не перечислял, так что хуй тя знает, может, тебе это некритично.
Но главное, это что спермоконтейнеры тоже один хрен жрут памяти как отдельная операционка и запускаются по времени как отдельная операционка. Так что даже если бы ты их каким-то чудом допилил для своей задачи, ты бы ничего особо не выиграл. Такие дела, да.
>>701964
Всё это будет жутко лагать + туда надо делать проброс GPU
И что на ней делать? Только думскроллить?
В этом тоже не вижу особого смысла, поскольку используя пиратский софт там всегда малварь, инфа соточка. Но работать надо, а не выяснять насколько оно безопасно.
Вот бы на родном ядре замутить оверлей как в прыщах, ну или хотябы слоистый контейнер как в докере. Но индусы учли это всё и их не обманешь
>для всякой лицушной дряни одну большую помойку оставь и пусть там всё булькает и кривляеся
Всё это будет жутко лагать + туда надо делать проброс GPU
>для удалёнки ещё одну чистую виртуалку
И что на ней делать? Только думскроллить?
>и может одну максимально изолированную чтобы в ней какой-нибудь странный исошник запустить, всё, куда больше-то.
В этом тоже не вижу особого смысла, поскольку используя пиратский софт там всегда малварь, инфа соточка. Но работать надо, а не выяснять насколько оно безопасно.
Вот бы на родном ядре замутить оверлей как в прыщах, ну или хотябы слоистый контейнер как в докере. Но индусы учли это всё и их не обманешь
>>701991
Чего им лагать, когда ты один раз аппаратное ускорение настроил и всё работает. Особенно в последние лет пятнадцать, когда виртуальный гпу твои попожопы спокойно будет вертеть.
Работать, ёбана. Это если у тебя нет отдельного ноута под весь тот мусор который требуется для копроративного впн или всякий рабочий софт который в здравом уме не будешь запускать.
Дед, проснись, какая малварь, всё давно на русракере есть.
Запускайся сразу на прыщах, хули. Когда ответишь на вопрос что тебя реально на винде держит, окажется что не так уж много.
Чего им лагать, когда ты один раз аппаратное ускорение настроил и всё работает. Особенно в последние лет пятнадцать, когда виртуальный гпу твои попожопы спокойно будет вертеть.
> И что на ней делать?
Работать, ёбана. Это если у тебя нет отдельного ноута под весь тот мусор который требуется для копроративного впн или всякий рабочий софт который в здравом уме не будешь запускать.
> поскольку используя пиратский софт там всегда малварь
Дед, проснись, какая малварь, всё давно на русракере есть.
> Вот бы на родном ядре замутить оверлей как в прыщах,
Запускайся сразу на прыщах, хули. Когда ответишь на вопрос что тебя реально на винде держит, окажется что не так уж много.
>>701990
Это. Плюс vGPU != GPU. RemoteFX чрезвычайно тормозное говно.
>>701990
Нет, не жрут. Хотя демон докера+контейнер с базовой ОС не медаль на шее конечно, но там облегчённый образ. Он не может жрать столько же.
>>702008
Ну так там всё с малварью и ничего без неё.
Отвечаю: хочу иметь на компе весь пакет Adobe CC в котором лежит таблетка с малварью и при этом не засрать этим систему. Хочу после перезагрузки иметь чистую ОС без параши с русракеров. Костыли типа wine не предлагать.
Короче вариантов нет, господа. Индусы имба
>Другое дело, что каждая виртуалка 1. жрёт память как отдельная операционка
Это. Плюс vGPU != GPU. RemoteFX чрезвычайно тормозное говно.
>>701990
>Но главное, это что спермоконтейнеры тоже один хрен жрут памяти как отдельная операционка
Нет, не жрут. Хотя демон докера+контейнер с базовой ОС не медаль на шее конечно, но там облегчённый образ. Он не может жрать столько же.
>>702008
>Дед, проснись, какая малварь, всё давно на русракере есть.
Ну так там всё с малварью и ничего без неё.
>Запускайся сразу на прыщах, хули. Когда ответишь на вопрос что тебя реально на винде держит, окажется что не так уж много.
Отвечаю: хочу иметь на компе весь пакет Adobe CC в котором лежит таблетка с малварью и при этом не засрать этим систему. Хочу после перезагрузки иметь чистую ОС без параши с русракеров. Костыли типа wine не предлагать.
Короче вариантов нет, господа. Индусы имба
>>702020
Дед, пей таблетки, а то получишь по жопе. То что твой бесплатный антивирус любой кейген вирусом видит не значит что там по факту малварь.
Ну впрочем как всегда
> Ну так там всё с малварью и ничего без неё.
Дед, пей таблетки, а то получишь по жопе. То что твой бесплатный антивирус любой кейген вирусом видит не значит что там по факту малварь.
> хочу очевидно решаемую задачу, очевидное решение не предлагать
Ну впрочем как всегда
>>701990
Всё по делу, истину глаголишь!
Каждый этот камтейнер - это очередное окружение, которое таки stateful, так что именно поэтому в рот я ебал эти ваши микросервисы. Zа Монолит!
>Ну я типа могу такой же аргумент и про контейнеры представить, "кококо, под каждый условный фотожоп образ делать, кудах". Так что хз, странная претензия.
Всё по делу, истину глаголишь!
Каждый этот камтейнер - это очередное окружение, которое таки stateful, так что именно поэтому в рот я ебал эти ваши микросервисы. Zа Монолит!
>>702008
Здраво мыслишь. А теперь этот софт берёт, детектит, что он работает в виртуалке, и начинает об этом визжать, кукарекать и репортить тебя рпоративному админу. Твои действия? Вернее, твои действия, чтобы этого не случилось?
>Это если у тебя нет отдельного ноута под весь тот мусор который требуется для копроративного впн или всякий рабочий софт который в здравом уме не будешь запускать.
Здраво мыслишь. А теперь этот софт берёт, детектит, что он работает в виртуалке, и начинает об этом визжать, кукарекать и репортить тебя рпоративному админу. Твои действия? Вернее, твои действия, чтобы этого не случилось?
>>702032
Они последнее время сами той ещё спайварью стали.
Так что теперь нужно откапывать все эти Symantec Endpoint Protection (и копаться в настройках, пока не закончатся ложные срабатывания), McAfee Endpoint Security (правда, он у меня почему-то полную проверку за 5 минут заканчивал, и писал, что "проверено файлов: 0"), FortiClient (то же самое, вариант для XP), или что там ещё было из "клиентских модулей корпоративных антивирусов, врубающих штатный вечный триал, если их к управляющему серверу не подключать".
Или пвордить комплексное решение безопасности уровня /s/:
AVZ в качестве сканера, переписанный под него ClamSentiel в качестве монитора, плюс ежечасные/дневные/недельные/месячные сканы разного масштаба через штатный планировщик, Defendnot (а лучше - код из него в переписанном ClamSentiel) - чтобы 10+ не выёживалась, а также PeerBlock и Sandboxie. Ах да, и сеть весёлых и находчивых, чтобы нахаляву обновлять PeerBlock или просто иметь возможность обновить вирусные базы, если вместо AVZ юзаешь ClamWin/Symantec/McAffee... И, чуть не забыл, PeerBlock с отконвертированными правилами AB+ как "браузерная защита".
Но это - уже другая история. Но если кому-то идея под спойлером зашла - создавайте тред.
>бесплатный антивирус
Они последнее время сами той ещё спайварью стали.
Так что теперь нужно откапывать все эти Symantec Endpoint Protection (и копаться в настройках, пока не закончатся ложные срабатывания), McAfee Endpoint Security (правда, он у меня почему-то полную проверку за 5 минут заканчивал, и писал, что "проверено файлов: 0"), FortiClient (то же самое, вариант для XP), или что там ещё было из "клиентских модулей корпоративных антивирусов, врубающих штатный вечный триал, если их к управляющему серверу не подключать".
Или пвордить комплексное решение безопасности уровня /s/:
AVZ в качестве сканера, переписанный под него ClamSentiel в качестве монитора, плюс ежечасные/дневные/недельные/месячные сканы разного масштаба через штатный планировщик, Defendnot (а лучше - код из него в переписанном ClamSentiel) - чтобы 10+ не выёживалась, а также PeerBlock и Sandboxie. Ах да, и сеть весёлых и находчивых, чтобы нахаляву обновлять PeerBlock или просто иметь возможность обновить вирусные базы, если вместо AVZ юзаешь ClamWin/Symantec/McAffee... И, чуть не забыл, PeerBlock с отконвертированными правилами AB+ как "браузерная защита".
Но это - уже другая история. Но если кому-то идея под спойлером зашла - создавайте тред.
125 Кб, 359x264> То что твой бесплатный антивирус любой кейген вирусом видит не значит что там по факту малварь.
Антивирус в 2026. Ебало лучше не представлять
>Ну впрочем как всегда
Скуфидон с фоновыми майнерами, спок
Запускаешь на родном ядре vs запускаешь через костыль.
>>702138
Шизик, какие такие инженеры? ВСЕ, АБСОЛЮТНО ВСЕ ПРОФЕССИОНАЛЬНЫЕ КАД системы для Mechanical Engineering и Industrial Design есть только на Винде, еще несколько есть на Маке. На линухе нет ни одной.
Да даже топовый и по сути незаменимый софт для инженеров электроники типо Altium Designer есть только для Винды.
>Инженеры без виндового софта создали цивилизацию
Шизик, какие такие инженеры? ВСЕ, АБСОЛЮТНО ВСЕ ПРОФЕССИОНАЛЬНЫЕ КАД системы для Mechanical Engineering и Industrial Design есть только на Винде, еще несколько есть на Маке. На линухе нет ни одной.
Да даже топовый и по сути незаменимый софт для инженеров электроники типо Altium Designer есть только для Винды.
Как вы там, потомки?
Смотрите, что нашёл:
https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-remote-desktop-protocol#supported-resources-and-peripherals
Это же значит, что если я на ноут поставил линукс чисто ради KVM - мне не надо держать в ДЕ индикатор батареи, поскольку она будет спокойно отображаться внутри полноэкранной сессии.
Смотрите, что нашёл:
https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-remote-desktop-protocol#supported-resources-and-peripherals
>Supported resources and peripherals
>Battery (automatic, not configurable)High-level - state reflectionLocal to remote
Это же значит, что если я на ноут поставил линукс чисто ради KVM - мне не надо держать в ДЕ индикатор батареи, поскольку она будет спокойно отображаться внутри полноэкранной сессии.
>>710104
Осталось только уточнить, как это сделать на FreeRD-
https://superuser.com/questions/1252928/is-it-possible-to-show-the-battery-level-of-an-rdp-client-inside-the-host#:~:text=You%20can%20create%20a%20Microsoft%20RDP%20client,should%20work%2C%20but%20it%20hasn't%20been%20tested.
https://github.com/Field-Effect-LLC/RDP-BattMon
Или нет. Ну вот! А я уже хотел из своего хромбука на MT8173C мутить дешёвый аналог ThinkPad X13s/T14s.
Осталось только уточнить, как это сделать на FreeRD-
https://superuser.com/questions/1252928/is-it-possible-to-show-the-battery-level-of-an-rdp-client-inside-the-host#:~:text=You%20can%20create%20a%20Microsoft%20RDP%20client,should%20work%2C%20but%20it%20hasn't%20been%20tested.
https://github.com/Field-Effect-LLC/RDP-BattMon
Или нет. Ну вот! А я уже хотел из своего хромбука на MT8173C мутить дешёвый аналог ThinkPad X13s/T14s.
>>710106
Алсо, малинка и относительно новые планшеты/ультрабуки на MediaTek - реально рабочая тема, чтобы пощупать ARM-виртуализацию. Под малинки - так вообще Варя ESXi есть.
Алсо, малинка и относительно новые планшеты/ультрабуки на MediaTek - реально рабочая тема, чтобы пощупать ARM-виртуализацию. Под малинки - так вообще Варя ESXi есть.
На связи оператор стенда с WHPX. Зашёл, значит, к себе через RDP и AnyConnect, врубил варю 15.5.7, развернул типовую 10, поставил тулзы - у меня сразу начало бесоёбить мышь. Я быстро вспомнил, что, в принципе, у меня на рабочей станции тоже есть локальный Вокрстейшн, поэтому вышел из RDP и зашёл более напрямую.
Не помню, улучшилось ли вообще что-то, но я снова столкнулся с дикой задержкой ввода на консоли - такой же, с которой постоянно сталкивался на ESXi (включая локальный вложенный) и ещё больше - на проёбанном iLO.
Вспомнил, что варя умеет публиковать консоль нормально - по VNC, на котором такие лаги бывают намного реже, полез включать.
Хуяк! Оказалось, у "shared VM" эта опция скрыта - придётся вручную вписать в *.vmx, разрегать и зарегать за-
Хуяк! Варя то ли попыталась зарегать ВМ как локальную и натолкнулась на метаданные, что на момент разрегистрации она была расшарена, то ли она во время разрегистрации блокировки не почистила. Ну и хуй с ним - почистил возможные блокировки, рестартанул службу "VMWare Workstation Server" - не помогло; рестартанул другие службы - не помогло; корректно остановил все службы, нажал Quit в трее, проверил оставшиеся процессы, заново всё запустил - наконец-то ВМ зарегалась, возможность включения VNC в графическом интерфейсе появилась.
Но я ведь тогда VNC хочу включить для всех ВМ, а это надо номера портов указывать. А ESXi, если в конфиг дописать только "RemoteDisplay.vnc.enabled = "TRUE"", не дописывая "RemoteDisplay.vnc.port =", тупо ведёт себя, как Libvirt/QEMU/KVM - берёт первый свободный порт от 5900. Поступит ли так же Вокрстейшн? Не, нихуя, максимум - попытается открыть порт 5900, а если он занят - просто запустится без VNC (впрочем, сделает это, даже если ВМ находится в режиме "shared VM").
Не помню уже, что я тогда гуглил, но нагуглил несколько тредов на Реддите, где было написано, что "Shared VMs" - это вообще хуйня из-под коня, и лучше уж тупо врубать VNC без переключения в режим shared. Но как же... Ладно, а как тогда автозапускать ВМ с vmx.exe, работающим в режиме службы? Даже если забить на второе - видимо, нужно обновляться... но аккуратно, а то где-то в версиях 16-17:
А "New auto-start virtual machine feature" - в 17.0. Тогда решено, придётся обновлять 15.5.2 до 17.0 и надеяться, что, хотя бы, возможность логиниться из Воркстейшна в vCentr оставили.
Алсо, в тот же раз я на Реддите натыкался и на тред, что Воркстейшн скатился и новые версии какие-то пиздец нестабильные. Хм, какая тогда последняя стабильная?
Не помню, улучшилось ли вообще что-то, но я снова столкнулся с дикой задержкой ввода на консоли - такой же, с которой постоянно сталкивался на ESXi (включая локальный вложенный) и ещё больше - на проёбанном iLO.
Вспомнил, что варя умеет публиковать консоль нормально - по VNC, на котором такие лаги бывают намного реже, полез включать.
Хуяк! Оказалось, у "shared VM" эта опция скрыта - придётся вручную вписать в *.vmx, разрегать и зарегать за-
Хуяк! Варя то ли попыталась зарегать ВМ как локальную и натолкнулась на метаданные, что на момент разрегистрации она была расшарена, то ли она во время разрегистрации блокировки не почистила. Ну и хуй с ним - почистил возможные блокировки, рестартанул службу "VMWare Workstation Server" - не помогло; рестартанул другие службы - не помогло; корректно остановил все службы, нажал Quit в трее, проверил оставшиеся процессы, заново всё запустил - наконец-то ВМ зарегалась, возможность включения VNC в графическом интерфейсе появилась.
Но я ведь тогда VNC хочу включить для всех ВМ, а это надо номера портов указывать. А ESXi, если в конфиг дописать только "RemoteDisplay.vnc.enabled = "TRUE"", не дописывая "RemoteDisplay.vnc.port =", тупо ведёт себя, как Libvirt/QEMU/KVM - берёт первый свободный порт от 5900. Поступит ли так же Вокрстейшн? Не, нихуя, максимум - попытается открыть порт 5900, а если он занят - просто запустится без VNC (впрочем, сделает это, даже если ВМ находится в режиме "shared VM").
Не помню уже, что я тогда гуглил, но нагуглил несколько тредов на Реддите, где было написано, что "Shared VMs" - это вообще хуйня из-под коня, и лучше уж тупо врубать VNC без переключения в режим shared. Но как же... Ладно, а как тогда автозапускать ВМ с vmx.exe, работающим в режиме службы? Даже если забить на второе - видимо, нужно обновляться... но аккуратно, а то где-то в версиях 16-17:
>Removed features:
>Legacy operating systems Tools ISOs omitted from program download (still available for separate download)
>Bluetooth hub pass-through
>Physical parallel port pass-through
>Unity mode
>Enhanced keyboard driver
А "New auto-start virtual machine feature" - в 17.0. Тогда решено, придётся обновлять 15.5.2 до 17.0 и надеяться, что, хотя бы, возможность логиниться из Воркстейшна в vCentr оставили.
Алсо, в тот же раз я на Реддите натыкался и на тред, что Воркстейшн скатился и новые версии какие-то пиздец нестабильные. Хм, какая тогда последняя стабильная?
На связи оператор стенда с WHPX. Зашёл, значит, к себе через RDP и AnyConnect, врубил варю 15.5.7, развернул типовую 10, поставил тулзы - у меня сразу начало бесоёбить мышь. Я быстро вспомнил, что, в принципе, у меня на рабочей станции тоже есть локальный Вокрстейшн, поэтому вышел из RDP и зашёл более напрямую.
Не помню, улучшилось ли вообще что-то, но я снова столкнулся с дикой задержкой ввода на консоли - такой же, с которой постоянно сталкивался на ESXi (включая локальный вложенный) и ещё больше - на проёбанном iLO.
Вспомнил, что варя умеет публиковать консоль нормально - по VNC, на котором такие лаги бывают намного реже, полез включать.
Хуяк! Оказалось, у "shared VM" эта опция скрыта - придётся вручную вписать в *.vmx, разрегать и зарегать за-
Хуяк! Варя то ли попыталась зарегать ВМ как локальную и натолкнулась на метаданные, что на момент разрегистрации она была расшарена, то ли она во время разрегистрации блокировки не почистила. Ну и хуй с ним - почистил возможные блокировки, рестартанул службу "VMWare Workstation Server" - не помогло; рестартанул другие службы - не помогло; корректно остановил все службы, нажал Quit в трее, проверил оставшиеся процессы, заново всё запустил - наконец-то ВМ зарегалась, возможность включения VNC в графическом интерфейсе появилась.
Но я ведь тогда VNC хочу включить для всех ВМ, а это надо номера портов указывать. А ESXi, если в конфиг дописать только "RemoteDisplay.vnc.enabled = "TRUE"", не дописывая "RemoteDisplay.vnc.port =", тупо ведёт себя, как Libvirt/QEMU/KVM - берёт первый свободный порт от 5900. Поступит ли так же Вокрстейшн? Не, нихуя, максимум - попытается открыть порт 5900, а если он занят - просто запустится без VNC (впрочем, сделает это, даже если ВМ находится в режиме "shared VM").
Не помню уже, что я тогда гуглил, но нагуглил несколько тредов на Реддите, где было написано, что "Shared VMs" - это вообще хуйня из-под коня, и лучше уж тупо врубать VNC без переключения в режим shared. Но как же... Ладно, а как тогда автозапускать ВМ с vmx.exe, работающим в режиме службы? Даже если забить на второе - видимо, нужно обновляться... но аккуратно, а то где-то в версиях 16-17:
А "New auto-start virtual machine feature" - в 17.0. Тогда решено, придётся обновлять 15.5.2 до 17.0 и надеяться, что, хотя бы, возможность логиниться из Воркстейшна в vCentr оставили.
Алсо, в тот же раз я на Реддите натыкался и на тред, что Воркстейшн скатился и новые версии какие-то пиздец нестабильные. Хм, какая тогда последняя стабильная?
Не помню, улучшилось ли вообще что-то, но я снова столкнулся с дикой задержкой ввода на консоли - такой же, с которой постоянно сталкивался на ESXi (включая локальный вложенный) и ещё больше - на проёбанном iLO.
Вспомнил, что варя умеет публиковать консоль нормально - по VNC, на котором такие лаги бывают намного реже, полез включать.
Хуяк! Оказалось, у "shared VM" эта опция скрыта - придётся вручную вписать в *.vmx, разрегать и зарегать за-
Хуяк! Варя то ли попыталась зарегать ВМ как локальную и натолкнулась на метаданные, что на момент разрегистрации она была расшарена, то ли она во время разрегистрации блокировки не почистила. Ну и хуй с ним - почистил возможные блокировки, рестартанул службу "VMWare Workstation Server" - не помогло; рестартанул другие службы - не помогло; корректно остановил все службы, нажал Quit в трее, проверил оставшиеся процессы, заново всё запустил - наконец-то ВМ зарегалась, возможность включения VNC в графическом интерфейсе появилась.
Но я ведь тогда VNC хочу включить для всех ВМ, а это надо номера портов указывать. А ESXi, если в конфиг дописать только "RemoteDisplay.vnc.enabled = "TRUE"", не дописывая "RemoteDisplay.vnc.port =", тупо ведёт себя, как Libvirt/QEMU/KVM - берёт первый свободный порт от 5900. Поступит ли так же Вокрстейшн? Не, нихуя, максимум - попытается открыть порт 5900, а если он занят - просто запустится без VNC (впрочем, сделает это, даже если ВМ находится в режиме "shared VM").
Не помню уже, что я тогда гуглил, но нагуглил несколько тредов на Реддите, где было написано, что "Shared VMs" - это вообще хуйня из-под коня, и лучше уж тупо врубать VNC без переключения в режим shared. Но как же... Ладно, а как тогда автозапускать ВМ с vmx.exe, работающим в режиме службы? Даже если забить на второе - видимо, нужно обновляться... но аккуратно, а то где-то в версиях 16-17:
>Removed features:
>Legacy operating systems Tools ISOs omitted from program download (still available for separate download)
>Bluetooth hub pass-through
>Physical parallel port pass-through
>Unity mode
>Enhanced keyboard driver
А "New auto-start virtual machine feature" - в 17.0. Тогда решено, придётся обновлять 15.5.2 до 17.0 и надеяться, что, хотя бы, возможность логиниться из Воркстейшна в vCentr оставили.
Алсо, в тот же раз я на Реддите натыкался и на тред, что Воркстейшн скатился и новые версии какие-то пиздец нестабильные. Хм, какая тогда последняя стабильная?
>>714645
Но это было где-то месяц назад, а на этой неделе, когда мне снова понадобилась эта же виртуалка - обнаружилось, что, походу, "shared VMs" ещё и shared flders средствами гипервизора не поддерживают (или, опять же, добавляются через выведение ВМ из статуса shared) - ну хуй с ним, замутил SMB-шару на хосте и сделал в виртуалке обычный net use...
Но не тут кобыла. Виртуалка заснула, а когда я её разбудил - она первым делом пожаловалась, что SMB-шара отъебнула.
С одной стороны, конечно, ничего необычного, с другой - на XP поверх libvirt/QEMU/KVM такого не было.
С другой, там и тег, разрешающий виртуалке спать, не был вписан, я тогда тупо о нём не знал.
С третьей - дык бля, да даже на физике такого не было! Ну да, бывало, что сделал net use, будучи подглюченным к сети с SMB-сервером через вайфай, а потом переключился на Ethernet, и шара сразу отъебнула (хотя через новую сеть был доступен по тому же IP!), да так, что освободить букву можно было только ребутом, но даже так! Ругалась винда при этом - только при попытке открыть эту шару проводником (или размонтировать), а не при каждом пробуждении или этом же переключении сети.
Так что, походу, на целевую виртуалку мне придётся ставить SFU, а со стороны NAS - пвордить Kerberos для NFSv3 и надеяться, что, с учётом принципа NFS, таймингов будет хватать, чтобы после пробуждения ВМ клиент очухался...
А вообще, может, оно и к лучшему - NFSv3, в отличие от SMBv1, вроде, не считается таким древним-несекурным-отменённым, как SMBv1.
Но это было где-то месяц назад, а на этой неделе, когда мне снова понадобилась эта же виртуалка - обнаружилось, что, походу, "shared VMs" ещё и shared flders средствами гипервизора не поддерживают (или, опять же, добавляются через выведение ВМ из статуса shared) - ну хуй с ним, замутил SMB-шару на хосте и сделал в виртуалке обычный net use...
Но не тут кобыла. Виртуалка заснула, а когда я её разбудил - она первым делом пожаловалась, что SMB-шара отъебнула.
С одной стороны, конечно, ничего необычного, с другой - на XP поверх libvirt/QEMU/KVM такого не было.
С другой, там и тег, разрешающий виртуалке спать, не был вписан, я тогда тупо о нём не знал.
С третьей - дык бля, да даже на физике такого не было! Ну да, бывало, что сделал net use, будучи подглюченным к сети с SMB-сервером через вайфай, а потом переключился на Ethernet, и шара сразу отъебнула (хотя через новую сеть был доступен по тому же IP!), да так, что освободить букву можно было только ребутом, но даже так! Ругалась винда при этом - только при попытке открыть эту шару проводником (или размонтировать), а не при каждом пробуждении или этом же переключении сети.
Так что, походу, на целевую виртуалку мне придётся ставить SFU, а со стороны NAS - пвордить Kerberos для NFSv3 и надеяться, что, с учётом принципа NFS, таймингов будет хватать, чтобы после пробуждения ВМ клиент очухался...
А вообще, может, оно и к лучшему - NFSv3, в отличие от SMBv1, вроде, не считается таким древним-несекурным-отменённым, как SMBv1.
О чудо, тред ещё жив! Тогда мне есть, куда накидать инфу по kqemu, нарытую недавно, когда гуглил кое-что про старые ядра.
Итак...
1. https://wiki.qemu.org/Documentation/KQemu
2. https://wiki.qemu.org/Features/KQemu
Если погуглить ещё, то где-то на форуме Арча найдётся тред, где сказано, что после обновления до 2.6.21 эффективность ускорителя существенно упала, а последнее ядро, где она работала нормально - 2.6.20. А в основном пишут, что хорошо работало на 2.6.18 - как раз на нашем любимом, последнем нормальном ядре, так что ещё один повод его попвордить, а потом держаться за него, как за XP. А по дистрам это примерно:
Debian 3.1-5.1
Ubuntu 9.04-10.04
RHEL/CentOS 5.11 если уж на то пошло - может, даже Мобильная Система Вооружённых Сил? :3
Едем дальше...
Прикольно. Получается, он свопит ВСЮ память ВМ, поэтому пытается разместить её там, где предполагает RAM-диск. На это есть причина:
То есть, чтобы наверняка, хорошо бы перед запуском ВМ с этим модулем инициализировать отдельную tmpfs ramfs и переменную среды... Или просто:
- заменить линукс на фряху (гуглим... они это дело тоже дропнули, понадобятся релизы 7.x-9.x). Хотя стоп, выше же по тексту сказано, что на фряхе он тоже свопит, и тоже, видимо, "не от хорошей жизни". Остаётся солярка и... винда?
OU E! Интересно, заведётся ли это дело на WinPE 1.6? Тогда можно ведь будет намутить такого франкенштейна - легковесного, как сам ESXi! Щито ж, будем посмотреть. Экспериментировать, так сказать.
Итак...
1. https://wiki.qemu.org/Documentation/KQemu
2. https://wiki.qemu.org/Features/KQemu
>KQEMU is supported on x86 or x86_64 Linux 2.4 or 2.6 hosts.[1]
Если погуглить ещё, то где-то на форуме Арча найдётся тред, где сказано, что после обновления до 2.6.21 эффективность ускорителя существенно упала, а последнее ядро, где она работала нормально - 2.6.20. А в основном пишут, что хорошо работало на 2.6.18 - как раз на нашем любимом, последнем нормальном ядре, так что ещё один повод его попвордить, а потом держаться за него, как за XP. А по дистрам это примерно:
Debian 3.1-5.1
Ubuntu 9.04-10.04
RHEL/CentOS 5.11 если уж на то пошло - может, даже Мобильная Система Вооружённых Сил? :3
Едем дальше...
>When using KQEMU on a Linux or FreeBSD host, QEMU will create a big hidden file containing the RAM of the virtual machine. For best performance, it is important that this file is kept in RAM and not on the hard disk. QEMU uses the `/dev/shm' directory to create this file because tmpfs is usually mounted on it (check with the shell command df). Otherwise `/tmp' is used as fallback. You can use the QEMU_TMPDIR shell variable to set a new directory for the QEMU RAM file.[1]
Прикольно. Получается, он свопит ВСЮ память ВМ, поэтому пытается разместить её там, где предполагает RAM-диск. На это есть причина:
>On Linux, due to a kernel bug related to memory swapping, the corresponding memory must be mmaped from a file. We plan to remove this restriction in a future implementation.[2]
То есть, чтобы наверняка, хорошо бы перед запуском ВМ с этим модулем инициализировать отдельную tmpfs ramfs и переменную среды... Или просто:
>KQEMU is ported on many host OSes (currently Linux, Windows, FreeBSD, Solaris).[2]
- заменить линукс на фряху (гуглим... они это дело тоже дропнули, понадобятся релизы 7.x-9.x). Хотя стоп, выше же по тексту сказано, что на фряхе он тоже свопит, и тоже, видимо, "не от хорошей жизни". Остаётся солярка и... винда?
>Experimental versions are available for FreeBSD and Windows NT/2000/2003/XP.[1]
OU E! Интересно, заведётся ли это дело на WinPE 1.6? Тогда можно ведь будет намутить такого франкенштейна - легковесного, как сам ESXi! Щито ж, будем посмотреть. Экспериментировать, так сказать.
О чудо, тред ещё жив! Тогда мне есть, куда накидать инфу по kqemu, нарытую недавно, когда гуглил кое-что про старые ядра.
Итак...
1. https://wiki.qemu.org/Documentation/KQemu
2. https://wiki.qemu.org/Features/KQemu
Если погуглить ещё, то где-то на форуме Арча найдётся тред, где сказано, что после обновления до 2.6.21 эффективность ускорителя существенно упала, а последнее ядро, где она работала нормально - 2.6.20. А в основном пишут, что хорошо работало на 2.6.18 - как раз на нашем любимом, последнем нормальном ядре, так что ещё один повод его попвордить, а потом держаться за него, как за XP. А по дистрам это примерно:
Debian 3.1-5.1
Ubuntu 9.04-10.04
RHEL/CentOS 5.11 если уж на то пошло - может, даже Мобильная Система Вооружённых Сил? :3
Едем дальше...
Прикольно. Получается, он свопит ВСЮ память ВМ, поэтому пытается разместить её там, где предполагает RAM-диск. На это есть причина:
То есть, чтобы наверняка, хорошо бы перед запуском ВМ с этим модулем инициализировать отдельную tmpfs ramfs и переменную среды... Или просто:
- заменить линукс на фряху (гуглим... они это дело тоже дропнули, понадобятся релизы 7.x-9.x). Хотя стоп, выше же по тексту сказано, что на фряхе он тоже свопит, и тоже, видимо, "не от хорошей жизни". Остаётся солярка и... винда?
OU E! Интересно, заведётся ли это дело на WinPE 1.6? Тогда можно ведь будет намутить такого франкенштейна - легковесного, как сам ESXi! Щито ж, будем посмотреть. Экспериментировать, так сказать.
Итак...
1. https://wiki.qemu.org/Documentation/KQemu
2. https://wiki.qemu.org/Features/KQemu
>KQEMU is supported on x86 or x86_64 Linux 2.4 or 2.6 hosts.[1]
Если погуглить ещё, то где-то на форуме Арча найдётся тред, где сказано, что после обновления до 2.6.21 эффективность ускорителя существенно упала, а последнее ядро, где она работала нормально - 2.6.20. А в основном пишут, что хорошо работало на 2.6.18 - как раз на нашем любимом, последнем нормальном ядре, так что ещё один повод его попвордить, а потом держаться за него, как за XP. А по дистрам это примерно:
Debian 3.1-5.1
Ubuntu 9.04-10.04
RHEL/CentOS 5.11 если уж на то пошло - может, даже Мобильная Система Вооружённых Сил? :3
Едем дальше...
>When using KQEMU on a Linux or FreeBSD host, QEMU will create a big hidden file containing the RAM of the virtual machine. For best performance, it is important that this file is kept in RAM and not on the hard disk. QEMU uses the `/dev/shm' directory to create this file because tmpfs is usually mounted on it (check with the shell command df). Otherwise `/tmp' is used as fallback. You can use the QEMU_TMPDIR shell variable to set a new directory for the QEMU RAM file.[1]
Прикольно. Получается, он свопит ВСЮ память ВМ, поэтому пытается разместить её там, где предполагает RAM-диск. На это есть причина:
>On Linux, due to a kernel bug related to memory swapping, the corresponding memory must be mmaped from a file. We plan to remove this restriction in a future implementation.[2]
То есть, чтобы наверняка, хорошо бы перед запуском ВМ с этим модулем инициализировать отдельную tmpfs ramfs и переменную среды... Или просто:
>KQEMU is ported on many host OSes (currently Linux, Windows, FreeBSD, Solaris).[2]
- заменить линукс на фряху (гуглим... они это дело тоже дропнули, понадобятся релизы 7.x-9.x). Хотя стоп, выше же по тексту сказано, что на фряхе он тоже свопит, и тоже, видимо, "не от хорошей жизни". Остаётся солярка и... винда?
>Experimental versions are available for FreeBSD and Windows NT/2000/2003/XP.[1]
OU E! Интересно, заведётся ли это дело на WinPE 1.6? Тогда можно ведь будет намутить такого франкенштейна - легковесного, как сам ESXi! Щито ж, будем посмотреть. Экспериментировать, так сказать.
Посмотрим, что ещё там интересного...
То есть, код реального режима будет исполняться таки медленнее, чем в QEMU/TCG?
А вот это круто (если я понял правильно)! Под "CPL" же подразумевается номер кольца защиты?
Понятно. Значит, kqemu у нас на уровне MSVPC, а VMWare/Parallels всё равно будут покруче.
...и выше по тексту исходной статьи перечислены эти самые "assumptions". А вот это уже страшно.
>The main priority when implementing KQEMU was simplicity and security. Unlike other virtualization systems, it does not do any dynamic translation nor code patching.[2]
То есть, код реального режима будет исполняться таки медленнее, чем в QEMU/TCG?
>KQEMU always executes the target code at CPL = 3 on the host processor. It means that KQEMU can use the page protections to ensure that the VM cannot modify the host OS nor the KQEMU monitor. Moreover, it means that KQEMU does not need to modify the segment limits to ensure memory protection.[2]
>The VM code is always run with CPL = 3 on the host, so the VM code has no more priviliedge than regular user code.[2]
А вот это круто (если я понял правильно)! Под "CPL" же подразумевается номер кольца защиты?
>Developments Ideas
>Support of guest SMP.[2]
Понятно. Значит, kqemu у нас на уровне MSVPC, а VMWare/Parallels всё равно будут покруче.
>Dynamic relocation of the monitor code so that a 32 MB hole in the guest address space is found automatically without making assumptions on the guest OS.[2]
...и выше по тексту исходной статьи перечислены эти самые "assumptions". А вот это уже страшно.
>KQEMU has only been tested with Linux 2.4, Linux 2.6 and Windows 2000/XP as guest OSes.
>The full virtualization mode cannot work with all OSes because it makes some assumptions about the x86 instructions that the guest OS uses.
>The requirements for a guest OS to work in full virtualization mode are very simple and most recent OSes (such as Linux or Windows 2000/XP) fulfill them.
>Full virtualization and Linux guests
>Best performances are achieved with Linux 2.4 kernels. Linux 2.6 works but the performance gains are small.
>64 bit guest Linux kernel is experimental.[1]
И ещё:
https://wiki.qemu.org/ChangeLog/KQemu
>version 1.3.0pre6:
> - better null LDT handling (aka Plan9 and ReactOS bug)
> - moved monitor code to another address (aka win2k 256 MB bug)
>version 1.3.0pre5:
> - win32 temporary workaround for CancelIo()
>version 0.7.2:
> - more precise segmentation support (aka Win98 support)
Вроде бы, тут даже упоминаются все относительно основные ОС... но всего один раз, а багов в трансляции, скорее всего, сильно больше, но проект уже заброшен.
Получается, уверенно говорят только про Linux 2.4 и 2k/XP... Но только для Linux, как бы, и Xen есть. А можно, интересно, юзать этот модуль в в составе dom0, чтобы линуксовые машины гонять в PV, но виндовые тоже как-то ускорять?
>Note that KQEMU cannot currently work if the Xen virtualizer is running on your host.[1]
Понятно...
Такк. Бинарники (похоже) ванильного QEMU 0.9.0 были обнаружены в составе виндового QtEmu последней сборки до каких-либо форков. Правда, собран он, походу, без kqemu.
>>718720
<...>
<...>
А, не, есть.
<...>
<...>
Просто при неудачном обращении к драйверу он тупо показывает справку, и непонятно, что ему не нравится - непонятный параметр или ошибка обращения к драйверу.
Впрочем, вроде, эта сборка уже не такая кривая, как с сайта https://qemu.weilnetz.de/, которая такое только в stdout.txt в "C:\Program Files\qemu" (при условии наличия прав) и умеет.
>C:\Program Files (x86)\QtEmu\qemu>qemu -help
<...>
>-kernel-kqemu enable KQEMU full virtualization (default is user mode only)
>-no-kqemu disable KQEMU kernel module usage
<...>
А, не, есть.
>C:\Program Files (x86)\QtEmu\qemu>qemu -kernel-kqemu
<...>
>-kernel-kqemu enable KQEMU full virtualization (default is user mode only)
>-no-kqemu disable KQEMU kernel module usage
<...>
Просто при неудачном обращении к драйверу он тупо показывает справку, и непонятно, что ему не нравится - непонятный параметр или ошибка обращения к драйверу.
Впрочем, вроде, эта сборка уже не такая кривая, как с сайта https://qemu.weilnetz.de/, которая такое только в stdout.txt в "C:\Program Files\qemu" (при условии наличия прав) и умеет.
Сап, Анон. Ищу способ виртуализации файловой системы так как это делает Sandboxie но стандартными средствами Windows. Такое возможно?
>>718978
А тебе для какой платформы?
Если для Linux - как раз смотри в сторону контейнеров.
Вроде, докеру можно прокинуть иксы.
Если хочешь более интегрированные контейнеры (с большим упором в изоляцию приложений, а не окружений) - смотри Flatpak.
Snap тоже может подойти, он из той же оперы, но ИМХО это нинужная блоатварь от создателей Бубунты, из которой её часто приходится выпиливать, и, что важнее, когда в Flatpak можно помимо Flathub прописать свои репозитории - снапоговно анально привязано к фирменному репозиторию КунониКал.
AppImage - тоже из той же оперы, но его больше используют для упаковки портативных приложений (подобно VMWare ThinApp), но основа принципа его работы - (почти) те же контейнеры.
Если тебе нужна именно изоляция окружений - можно ещё посмотреть Libvirt-LXC, LXD и ещё какой-то фронтенд над LXC, встроенный в сустемд - короче, "не одним докером", и вообще, к докеру я тоже отношусь сомнительно, хотя и признаю его ноу-хау.
А тебе для какой платформы?
Если для Linux - как раз смотри в сторону контейнеров.
Вроде, докеру можно прокинуть иксы.
Если хочешь более интегрированные контейнеры (с большим упором в изоляцию приложений, а не окружений) - смотри Flatpak.
Snap тоже может подойти, он из той же оперы, но ИМХО это нинужная блоатварь от создателей Бубунты, из которой её часто приходится выпиливать, и, что важнее, когда в Flatpak можно помимо Flathub прописать свои репозитории - снапоговно анально привязано к фирменному репозиторию КунониКал.
AppImage - тоже из той же оперы, но его больше используют для упаковки портативных приложений (подобно VMWare ThinApp), но основа принципа его работы - (почти) те же контейнеры.
Если тебе нужна именно изоляция окружений - можно ещё посмотреть Libvirt-LXC, LXD и ещё какой-то фронтенд над LXC, встроенный в сустемд - короче, "не одним докером", и вообще, к докеру я тоже отношусь сомнительно, хотя и признаю его ноу-хау.
>>721314
Для винды. Задача максимально собрать все зависимости в отдельный от основной файловой системы контейнер, чтобы в нём накапливались изменения. Чтобы при переносе с одного компа на другой всё работало как родное в пределах Win10/11 и сохранялись все изменения/настройки приложения. Докер не решение так как не даёт работать с GUI, отдельная виртуалка для каждой приложухи тоже как-то жирновато.
На линуксе мне для моих задач нейронка советует использовать podman
>А тебе для какой платформы?
Для винды. Задача максимально собрать все зависимости в отдельный от основной файловой системы контейнер, чтобы в нём накапливались изменения. Чтобы при переносе с одного компа на другой всё работало как родное в пределах Win10/11 и сохранялись все изменения/настройки приложения. Докер не решение так как не даёт работать с GUI, отдельная виртуалка для каждой приложухи тоже как-то жирновато.
На линуксе мне для моих задач нейронка советует использовать podman
>>721612
Хм... Тогда бы, наверное, я рассмотрел Windows Server Containers (насколько я знаю, докер даже умеет с этой штукой интегрироваться) и, если хочется кастрировать окружение контейнера по максимуму - редакцию 2016 винды "Nano Server", и то, что она дропнута давно (сама подсистема контейнеров не дрпонута) - меня бы абсолютно не волновало.
Впрочем, что более важно - в Nano Server даже WOW64 нет, а дотнет - есть, поэтому ИМХО - с дотнетом она нихуя не легковесная, зато без WOW64 - неполноценная.
Тут я снова порекомендую WinPE. Официальную, если требуется - со взломом авто-ребута после 24/72 часов аптайма. Либо 32-разрядную, либо с плагином, добавляющим WOW64. Вот именно в таком виде - и легковесное, и полноценное окружение для виндо-эпплаенсов.
Но, опять же.
Во-первых, я нахожусь в РФ, где винда сейчас не "пиратская", а "трофейная", в том числе - в организациях лично видел - не скажу, где, не надейтесь, товарищ майор, но видел.
А во-вторых, сам я - всего лишь оператор хоумлабы, частник и физик, и таким планирую оставаться, даже если у меня в хоумлабе планируется продакшн-сегмент с сервисами для реальных внешних пользователей. Но даже так - эти сервисы принципиально будут некоммерческими, а пользователи вряд ли вообще будут задумываться, на какой именно винде оно крутится.
И только поэтому я могу так обходиться с WinPE без зазрения совести.
Но если вдруг у тебя не так - "WinPE можно юзать только для задач развёртывания или восстановления ОС, а чтобы не было соблазна - ставим авто-ребут по достижении 72 (раньше 24) часов аптайма".
Тогда я бы на твоём месте просто собирал эпплаенс из портативных,
де-факто портативных (т.е. которые, даже не имея выделенной "портативной редакции", могут быть настроены так, чтобы вести себя или сразу де-факто ведут себя как портативные, под этом определение подходит даже виндовый Nginx)
или условно портативных (которые хоть и срут в систему, но при тупом копировании из Program Files на другом хосте с флешки спокойно запустятся) приложений.
Во втором случае - соответственно, грамотно (если требуется - "с нуля") составлять конфиги, в третьем - колхозить нужную обвязку на bat/vbs/ps1/reg-файлах.
В любом случае, в винде именно с зависимостями часто легче, просто потому что ты в большинстве случаев ты можешь сложить все dll, нужные конкретному exe, в один с ним каталог да и в линуксе, как я понимаю, можно добиться аналогичного эффекта ковырянием переменных среды LD_... чем тот же AppImage, например, и занимается.
Для общего развития могу посоветовать посмотреть тот же PortableApps.com (как я понимаю, в первую очередь - просто каталог непосредственно "портативных редакций", - но для чего-то же его фирменный шелл существует, не только как лаунчер/обновлятор же?), VMWare ThinApp или аналогичное решение от LANDesk.
У тебя-то задачи/приложения какие - десктоп, сервер?
Тогда я бы к предыдущему добавил образ диска. ImDisk, VeraCrypt/LibreCrypt, монтировалка VMDK из состава VMWare Workstation, VHD(X) - что угодно. Лучше всего - VHD(X), поскольку только в них винда корректно обрабатывает образы с несколькими разделами и может подключить их не к junction point без выделения буквы. И битлокер тогда, если захочешь шифровать образ.
У тебя на целевых хостах админские права есть?
Для контейнеров на базе WSL есть иксы и их проброс, для контейнеров на базе виндосервера... вроде, тоже что-то было.
Для микросервиса - да. Для монолита или песочницы - ИМХО легче реализуется и, если важно, более серьёзная изоляция (конечно, ИМХО, если нужна изоляция, то ядро у гостевого окружения тоже должно быть отдельное, а не поделённое на части всякими cgroups/netns/apparmor... да даже Xen PV лучше, чем докер). Оверхед больше, но при использовании VT-x/SVM - не сильно, - у тебя же, надеюсь, эти штуки на целевых хостах есть?
Да, если не хочешь оверхеда даже от VT-x - тогда виндосервероконтейнеры не подходят, они на WHPX работают.
>>721612
Так твои задачи скорее серверные?
>Для винды.
Хм... Тогда бы, наверное, я рассмотрел Windows Server Containers (насколько я знаю, докер даже умеет с этой штукой интегрироваться) и, если хочется кастрировать окружение контейнера по максимуму - редакцию 2016 винды "Nano Server", и то, что она дропнута давно (сама подсистема контейнеров не дрпонута) - меня бы абсолютно не волновало.
Впрочем, что более важно - в Nano Server даже WOW64 нет, а дотнет - есть, поэтому ИМХО - с дотнетом она нихуя не легковесная, зато без WOW64 - неполноценная.
Тут я снова порекомендую WinPE. Официальную, если требуется - со взломом авто-ребута после 24/72 часов аптайма. Либо 32-разрядную, либо с плагином, добавляющим WOW64. Вот именно в таком виде - и легковесное, и полноценное окружение для виндо-эпплаенсов.
Но, опять же.
Во-первых, я нахожусь в РФ, где винда сейчас не "пиратская", а "трофейная", в том числе - в организациях лично видел - не скажу, где, не надейтесь, товарищ майор, но видел.
А во-вторых, сам я - всего лишь оператор хоумлабы, частник и физик, и таким планирую оставаться, даже если у меня в хоумлабе планируется продакшн-сегмент с сервисами для реальных внешних пользователей. Но даже так - эти сервисы принципиально будут некоммерческими, а пользователи вряд ли вообще будут задумываться, на какой именно винде оно крутится.
И только поэтому я могу так обходиться с WinPE без зазрения совести.
Но если вдруг у тебя не так - "WinPE можно юзать только для задач развёртывания или восстановления ОС, а чтобы не было соблазна - ставим авто-ребут по достижении 72 (раньше 24) часов аптайма".
>максимально собрать все зависимости
Тогда я бы на твоём месте просто собирал эпплаенс из портативных,
де-факто портативных (т.е. которые, даже не имея выделенной "портативной редакции", могут быть настроены так, чтобы вести себя или сразу де-факто ведут себя как портативные, под этом определение подходит даже виндовый Nginx)
или условно портативных (которые хоть и срут в систему, но при тупом копировании из Program Files на другом хосте с флешки спокойно запустятся) приложений.
Во втором случае - соответственно, грамотно (если требуется - "с нуля") составлять конфиги, в третьем - колхозить нужную обвязку на bat/vbs/ps1/reg-файлах.
В любом случае, в винде именно с зависимостями часто легче, просто потому что ты в большинстве случаев ты можешь сложить все dll, нужные конкретному exe, в один с ним каталог да и в линуксе, как я понимаю, можно добиться аналогичного эффекта ковырянием переменных среды LD_... чем тот же AppImage, например, и занимается.
Для общего развития могу посоветовать посмотреть тот же PortableApps.com (как я понимаю, в первую очередь - просто каталог непосредственно "портативных редакций", - но для чего-то же его фирменный шелл существует, не только как лаунчер/обновлятор же?), VMWare ThinApp или аналогичное решение от LANDesk.
У тебя-то задачи/приложения какие - десктоп, сервер?
>в отдельный от основной файловой системы контейнер
Тогда я бы к предыдущему добавил образ диска. ImDisk, VeraCrypt/LibreCrypt, монтировалка VMDK из состава VMWare Workstation, VHD(X) - что угодно. Лучше всего - VHD(X), поскольку только в них винда корректно обрабатывает образы с несколькими разделами и может подключить их не к junction point без выделения буквы. И битлокер тогда, если захочешь шифровать образ.
У тебя на целевых хостах админские права есть?
>Докер не решение так как не даёт работать с GUI
Для контейнеров на базе WSL есть иксы и их проброс, для контейнеров на базе виндосервера... вроде, тоже что-то было.
>отдельная виртуалка для каждой приложухи тоже как-то жирновато
Для микросервиса - да. Для монолита или песочницы - ИМХО легче реализуется и, если важно, более серьёзная изоляция (конечно, ИМХО, если нужна изоляция, то ядро у гостевого окружения тоже должно быть отдельное, а не поделённое на части всякими cgroups/netns/apparmor... да даже Xen PV лучше, чем докер). Оверхед больше, но при использовании VT-x/SVM - не сильно, - у тебя же, надеюсь, эти штуки на целевых хостах есть?
Да, если не хочешь оверхеда даже от VT-x - тогда виндосервероконтейнеры не подходят, они на WHPX работают.
>>721612
>На линуксе мне для моих задач нейронка советует использовать podman
Так твои задачи скорее серверные?
>>721612
Хм... Тогда бы, наверное, я рассмотрел Windows Server Containers (насколько я знаю, докер даже умеет с этой штукой интегрироваться) и, если хочется кастрировать окружение контейнера по максимуму - редакцию 2016 винды "Nano Server", и то, что она дропнута давно (сама подсистема контейнеров не дрпонута) - меня бы абсолютно не волновало.
Впрочем, что более важно - в Nano Server даже WOW64 нет, а дотнет - есть, поэтому ИМХО - с дотнетом она нихуя не легковесная, зато без WOW64 - неполноценная.
Тут я снова порекомендую WinPE. Официальную, если требуется - со взломом авто-ребута после 24/72 часов аптайма. Либо 32-разрядную, либо с плагином, добавляющим WOW64. Вот именно в таком виде - и легковесное, и полноценное окружение для виндо-эпплаенсов.
Но, опять же.
Во-первых, я нахожусь в РФ, где винда сейчас не "пиратская", а "трофейная", в том числе - в организациях лично видел - не скажу, где, не надейтесь, товарищ майор, но видел.
А во-вторых, сам я - всего лишь оператор хоумлабы, частник и физик, и таким планирую оставаться, даже если у меня в хоумлабе планируется продакшн-сегмент с сервисами для реальных внешних пользователей. Но даже так - эти сервисы принципиально будут некоммерческими, а пользователи вряд ли вообще будут задумываться, на какой именно винде оно крутится.
И только поэтому я могу так обходиться с WinPE без зазрения совести.
Но если вдруг у тебя не так - "WinPE можно юзать только для задач развёртывания или восстановления ОС, а чтобы не было соблазна - ставим авто-ребут по достижении 72 (раньше 24) часов аптайма".
Тогда я бы на твоём месте просто собирал эпплаенс из портативных,
де-факто портативных (т.е. которые, даже не имея выделенной "портативной редакции", могут быть настроены так, чтобы вести себя или сразу де-факто ведут себя как портативные, под этом определение подходит даже виндовый Nginx)
или условно портативных (которые хоть и срут в систему, но при тупом копировании из Program Files на другом хосте с флешки спокойно запустятся) приложений.
Во втором случае - соответственно, грамотно (если требуется - "с нуля") составлять конфиги, в третьем - колхозить нужную обвязку на bat/vbs/ps1/reg-файлах.
В любом случае, в винде именно с зависимостями часто легче, просто потому что ты в большинстве случаев ты можешь сложить все dll, нужные конкретному exe, в один с ним каталог да и в линуксе, как я понимаю, можно добиться аналогичного эффекта ковырянием переменных среды LD_... чем тот же AppImage, например, и занимается.
Для общего развития могу посоветовать посмотреть тот же PortableApps.com (как я понимаю, в первую очередь - просто каталог непосредственно "портативных редакций", - но для чего-то же его фирменный шелл существует, не только как лаунчер/обновлятор же?), VMWare ThinApp или аналогичное решение от LANDesk.
У тебя-то задачи/приложения какие - десктоп, сервер?
Тогда я бы к предыдущему добавил образ диска. ImDisk, VeraCrypt/LibreCrypt, монтировалка VMDK из состава VMWare Workstation, VHD(X) - что угодно. Лучше всего - VHD(X), поскольку только в них винда корректно обрабатывает образы с несколькими разделами и может подключить их не к junction point без выделения буквы. И битлокер тогда, если захочешь шифровать образ.
У тебя на целевых хостах админские права есть?
Для контейнеров на базе WSL есть иксы и их проброс, для контейнеров на базе виндосервера... вроде, тоже что-то было.
Для микросервиса - да. Для монолита или песочницы - ИМХО легче реализуется и, если важно, более серьёзная изоляция (конечно, ИМХО, если нужна изоляция, то ядро у гостевого окружения тоже должно быть отдельное, а не поделённое на части всякими cgroups/netns/apparmor... да даже Xen PV лучше, чем докер). Оверхед больше, но при использовании VT-x/SVM - не сильно, - у тебя же, надеюсь, эти штуки на целевых хостах есть?
Да, если не хочешь оверхеда даже от VT-x - тогда виндосервероконтейнеры не подходят, они на WHPX работают.
>>721612
Так твои задачи скорее серверные?
>Для винды.
Хм... Тогда бы, наверное, я рассмотрел Windows Server Containers (насколько я знаю, докер даже умеет с этой штукой интегрироваться) и, если хочется кастрировать окружение контейнера по максимуму - редакцию 2016 винды "Nano Server", и то, что она дропнута давно (сама подсистема контейнеров не дрпонута) - меня бы абсолютно не волновало.
Впрочем, что более важно - в Nano Server даже WOW64 нет, а дотнет - есть, поэтому ИМХО - с дотнетом она нихуя не легковесная, зато без WOW64 - неполноценная.
Тут я снова порекомендую WinPE. Официальную, если требуется - со взломом авто-ребута после 24/72 часов аптайма. Либо 32-разрядную, либо с плагином, добавляющим WOW64. Вот именно в таком виде - и легковесное, и полноценное окружение для виндо-эпплаенсов.
Но, опять же.
Во-первых, я нахожусь в РФ, где винда сейчас не "пиратская", а "трофейная", в том числе - в организациях лично видел - не скажу, где, не надейтесь, товарищ майор, но видел.
А во-вторых, сам я - всего лишь оператор хоумлабы, частник и физик, и таким планирую оставаться, даже если у меня в хоумлабе планируется продакшн-сегмент с сервисами для реальных внешних пользователей. Но даже так - эти сервисы принципиально будут некоммерческими, а пользователи вряд ли вообще будут задумываться, на какой именно винде оно крутится.
И только поэтому я могу так обходиться с WinPE без зазрения совести.
Но если вдруг у тебя не так - "WinPE можно юзать только для задач развёртывания или восстановления ОС, а чтобы не было соблазна - ставим авто-ребут по достижении 72 (раньше 24) часов аптайма".
>максимально собрать все зависимости
Тогда я бы на твоём месте просто собирал эпплаенс из портативных,
де-факто портативных (т.е. которые, даже не имея выделенной "портативной редакции", могут быть настроены так, чтобы вести себя или сразу де-факто ведут себя как портативные, под этом определение подходит даже виндовый Nginx)
или условно портативных (которые хоть и срут в систему, но при тупом копировании из Program Files на другом хосте с флешки спокойно запустятся) приложений.
Во втором случае - соответственно, грамотно (если требуется - "с нуля") составлять конфиги, в третьем - колхозить нужную обвязку на bat/vbs/ps1/reg-файлах.
В любом случае, в винде именно с зависимостями часто легче, просто потому что ты в большинстве случаев ты можешь сложить все dll, нужные конкретному exe, в один с ним каталог да и в линуксе, как я понимаю, можно добиться аналогичного эффекта ковырянием переменных среды LD_... чем тот же AppImage, например, и занимается.
Для общего развития могу посоветовать посмотреть тот же PortableApps.com (как я понимаю, в первую очередь - просто каталог непосредственно "портативных редакций", - но для чего-то же его фирменный шелл существует, не только как лаунчер/обновлятор же?), VMWare ThinApp или аналогичное решение от LANDesk.
У тебя-то задачи/приложения какие - десктоп, сервер?
>в отдельный от основной файловой системы контейнер
Тогда я бы к предыдущему добавил образ диска. ImDisk, VeraCrypt/LibreCrypt, монтировалка VMDK из состава VMWare Workstation, VHD(X) - что угодно. Лучше всего - VHD(X), поскольку только в них винда корректно обрабатывает образы с несколькими разделами и может подключить их не к junction point без выделения буквы. И битлокер тогда, если захочешь шифровать образ.
У тебя на целевых хостах админские права есть?
>Докер не решение так как не даёт работать с GUI
Для контейнеров на базе WSL есть иксы и их проброс, для контейнеров на базе виндосервера... вроде, тоже что-то было.
>отдельная виртуалка для каждой приложухи тоже как-то жирновато
Для микросервиса - да. Для монолита или песочницы - ИМХО легче реализуется и, если важно, более серьёзная изоляция (конечно, ИМХО, если нужна изоляция, то ядро у гостевого окружения тоже должно быть отдельное, а не поделённое на части всякими cgroups/netns/apparmor... да даже Xen PV лучше, чем докер). Оверхед больше, но при использовании VT-x/SVM - не сильно, - у тебя же, надеюсь, эти штуки на целевых хостах есть?
Да, если не хочешь оверхеда даже от VT-x - тогда виндосервероконтейнеры не подходят, они на WHPX работают.
>>721612
>На линуксе мне для моих задач нейронка советует использовать podman
Так твои задачи скорее серверные?
Как уже стало понятно:
если кто хочет иметь возможность комфортно работать с образами дисков своих ВМ под виндой - нежелательно создавать несколько разделов, потому что все эти ImDisk и большинство аналогов - смогут одновременно отобразить на хост только один раздел с одного образа.
А если нужно сегментировать ФС у виртуалки - получается, лучше создать несколько образов... помня, что максимальное число дисков, одновременно подключенных к ВМ - ограничено.
Впрочем, с учётом, что глюки начинаются уже в ОС (в том числе, на физике), если на диске уже больше 9 разделов (3 первичных и 6 логических - норм, на 7 логических уже начнутся глюки), а 9 образов - это в рамках ограничений актуальной вари или KVM, хуже - в легаси-конфигурациях (где один контроллер IDE, к которому можно подключить 3 образа винтов плюс один виртуальный привод, например).
И, конечно, речь шла о прозрачном отображении+монтировании образа на хосте, что можно делать только при выключенной ВМ (иначе ФС сразу pizda).
если кто хочет иметь возможность комфортно работать с образами дисков своих ВМ под виндой - нежелательно создавать несколько разделов, потому что все эти ImDisk и большинство аналогов - смогут одновременно отобразить на хост только один раздел с одного образа.
А если нужно сегментировать ФС у виртуалки - получается, лучше создать несколько образов... помня, что максимальное число дисков, одновременно подключенных к ВМ - ограничено.
Впрочем, с учётом, что глюки начинаются уже в ОС (в том числе, на физике), если на диске уже больше 9 разделов (3 первичных и 6 логических - норм, на 7 логических уже начнутся глюки), а 9 образов - это в рамках ограничений актуальной вари или KVM, хуже - в легаси-конфигурациях (где один контроллер IDE, к которому можно подключить 3 образа винтов плюс один виртуальный привод, например).
И, конечно, речь шла о прозрачном отображении+монтировании образа на хосте, что можно делать только при выключенной ВМ (иначе ФС сразу pizda).
>>721636
Я пользуюсь PortableApps но мне бы хотелось условный Фотошоп так же упаковать, но с этим проблемы. Мне вобщем для десктопа нужно.
Ищу способ как сделать руками то, то что эти инструменты делают с приложениями.
Я устанавливаю систему в родительский VHD1, далее загружаюсь в WinPE и создаю разностный дочерний VHD1 и гружусь с него. С этого момента все изменения накапливаются на нем, то есть установив прилагу я могу загрузиться в WinPE, переименовать дочерний диск, создать новый дочерний диск, загрузиться с него и установить уже другую прилагу для изоляции. Но дочерние диски будут накапливать не только изменения приложения, туда же попадут все обновления ОС например.
Означает ли это что я могу создать отдельный от ОС родительский VHD2, и без загрузки в WinPE смонтировать его на диск C: так, что он станет виртуальным прозрачным слоем накапливающим изменения и устанавливать в него приложения? По необходимости монтировать\отмонтировать такие диски и менять набор установленных программ в системе?
Это всё есть. Изоляция ядра достигается сбросом всех изменений после перезагрузки, но как запихать все настройки отдельного приложения и все изменения которые оно вносит в систему в отдельный образ? Если это достигается в WinPE готов пожертвовать удобством и перекатиться туда. Записи реестра физически хранятся в system32\config? Я могу выделить изменения реестра просто скопировав эту папку до/после установки целевого приложения?
>Тогда я бы на твоём месте просто собирал эпплаенс из портативных
>PortableApps.com
Я пользуюсь PortableApps но мне бы хотелось условный Фотошоп так же упаковать, но с этим проблемы. Мне вобщем для десктопа нужно.
>VMWare ThinApp или аналогичное решение от LANDesk
Ищу способ как сделать руками то, то что эти инструменты делают с приложениями.
>VHD(X) - что угодно. Лучше всего - VHD(X)
Я устанавливаю систему в родительский VHD1, далее загружаюсь в WinPE и создаю разностный дочерний VHD1 и гружусь с него. С этого момента все изменения накапливаются на нем, то есть установив прилагу я могу загрузиться в WinPE, переименовать дочерний диск, создать новый дочерний диск, загрузиться с него и установить уже другую прилагу для изоляции. Но дочерние диски будут накапливать не только изменения приложения, туда же попадут все обновления ОС например.
>Лучше всего - VHD(X), поскольку только в них винда корректно обрабатывает образы с несколькими разделами и может подключить их не к junction point без выделения буквы.
Означает ли это что я могу создать отдельный от ОС родительский VHD2, и без загрузки в WinPE смонтировать его на диск C: так, что он станет виртуальным прозрачным слоем накапливающим изменения и устанавливать в него приложения? По необходимости монтировать\отмонтировать такие диски и менять набор установленных программ в системе?
> VT-x/SVM - не сильно, - у тебя же, надеюсь, эти штуки на целевых хостах есть?
>У тебя на целевых хостах админские права есть?
Это всё есть. Изоляция ядра достигается сбросом всех изменений после перезагрузки, но как запихать все настройки отдельного приложения и все изменения которые оно вносит в систему в отдельный образ? Если это достигается в WinPE готов пожертвовать удобством и перекатиться туда. Записи реестра физически хранятся в system32\config? Я могу выделить изменения реестра просто скопировав эту папку до/после установки целевого приложения?
>>722554
GIMP есть в PortableApps, что в нём не хватает? ThinApp тоже не помог?
Это я понял - получается, вопрос в методичках... и я его могу лишь поддвачнуть.
В качестве возможной слабенькой опоры вспоминается только, что ещё в нулевых в UP(grade) Special видел статью или именно про это, или про организацию вечных триалов - возможно, там, помимо готовых рассматривались и какие-то такие решения... Но это предельно неточно.
Ещё один возможный вариант - закопаться в исходники PortableApps...
>>722554
Пока не совсем понял.
У тебя есть возможность подготовить VHD1 в виртуалке?
Или ты грузишься с VHD на физике?
Что именно делаешь в PE? Пока мне кажется, что это легче было бы делать в обычном stateful-окружении с развёрнутым инструментарием для сборки образов.
По поводу обновлений - если в VHD стоит система - да, всё так. Дочерний VHD - это просто дельта блоков. И это значит, что без дочерний VHD превратится в тыкву при потере/повреждении родительского.
В >>721636 я имел в виду обычный плоский VHD, на который просто помещается приложение, его зависимости и данные, как на физическую флешку, а потом временно монтируется по необходимости.
Изоляция, которую обеспечивает именно VHD - что это отдельный том. Т.е. это не та изоляция, которую обеспечивает Sandboxie, а просто, кхм, "организационная" изоляция, т.е. в дополнение к ней ещё нужно подобное решение.
Нет. Вернее, не совсем.
Отдельный от ОС - плоский VHD. Его можно отобразить через "Управление дисками", а потом создать условный C:\mnt\appname и через ту же оснастку смонтировать в него том с VHD. Если потом посмотреть на этот каталог через FAR - он превращается в симлинк на путь вида \\.\Volume... и там UUID, ссылающийся либо на Session Manager, либо куда-то в \System Volume Information\RemoteMountpointDatabase (не помню точный путь, но суть именно такая).
Этим как раз занимается Sandboxie. И, возможно, LANDesk тоже.
В случае Sandboxie - сам каталог песочницы тоже содержит дельту, но уже на файловом уровне.
Тогда, скорее, так:
1. Монтируешь плоский VHDn в C:\mnt\appname.
2. Создаёшь в нём новую песочницу Sandboxie и ставишь туда приложение.
3. По окончании работы разрегистрируешь песочницу перед размонтированием VHD.
4. Для продолжения работы - повторяешь п. 1 и повторно регистрируешь песочницу. Правда, я не уверен, что Sandboxie в принципе так умеет.
Но ThinApp и LANDesk, скорее всего, делают то же самое, только автоматизированно, и там логика работы песочницы встроена в файл контейнера (в случае LANDesk, похоже, меняется сам exe, а ThinApp, вроде, создаёт рядом файл дельты, проприетарного формата).
С ними п. 2 меняется на "формируешь пакет ThinApp", а п. 4 - на "повторяешь п. 1 и запускаешь exe из корня VHD".
А если нужно, чтобы контейнер не имел состояния - тогда да, Windows PE с плагинами, обеспечивающими нужными зависимостями. ИМХО, самое лаконичное решение, но это ИМХО, а майками оно не одобрено.
Поэтому есть ещё некое приложение "Time Travel", которое обеспечивает именно откат при перезагрузке состояния обычной Windows, это состояние имеющей.
Плюс штатные инструменты - один в составе виндосервера (вроде, редакии MultiPoint), другой - видел упоминание в списке компонентов корпоративной 10.
Не Sandboxie, так ThinApp, его аналоги или эквивалентные костыли на скриптах/reg-файлах, но тут вопрос за устоявшимися практиками.
Да, но не всё так просто. Каждый файл содержит по целой ветке первого/второго уровня, рядом лежат бинарные файлы журналов... и, иногда, автоматические бэкапы.
Вряд ли только если, как раз, с помощью WinPE.
Но тебе, скорее всего, эти файлы и не помогут, а больше поможет - консольная утилита reg. В твоём примере - экспорт всего реестра в reg-файл до установки, ещё один - после запуска-закрытия или активации--закрытия, потом - reg-файлы в WinMerge и писать скрипты, которые будут делать импорт перед запуском запуске, экспорт и чистку установленных ключей после закрытия.
Но проблема в том, что реестр - это далеко не единственное место, где приложения хранят своё состояние, даже среди типовых мест. Есть ещё, например, Application Data и Local Settings\Application Data.
>условный Фотошоп
GIMP есть в PortableApps, что в нём не хватает? ThinApp тоже не помог?
>Ищу способ как сделать руками то, то что эти инструменты делают с приложениями.
Это я понял - получается, вопрос в методичках... и я его могу лишь поддвачнуть.
В качестве возможной слабенькой опоры вспоминается только, что ещё в нулевых в UP(grade) Special видел статью или именно про это, или про организацию вечных триалов - возможно, там, помимо готовых рассматривались и какие-то такие решения... Но это предельно неточно.
Ещё один возможный вариант - закопаться в исходники PortableApps...
>>722554
>Я устанавливаю систему в родительский VHD1, далее загружаюсь в WinPE и создаю разностный дочерний VHD1 и гружусь с него. С этого момента все изменения накапливаются на нем, то есть установив прилагу я могу загрузиться в WinPE, переименовать дочерний диск, создать новый дочерний диск, загрузиться с него и установить уже другую прилагу для изоляции. Но дочерние диски будут накапливать не только изменения приложения, туда же попадут все обновления ОС например.
Пока не совсем понял.
У тебя есть возможность подготовить VHD1 в виртуалке?
Или ты грузишься с VHD на физике?
Что именно делаешь в PE? Пока мне кажется, что это легче было бы делать в обычном stateful-окружении с развёрнутым инструментарием для сборки образов.
По поводу обновлений - если в VHD стоит система - да, всё так. Дочерний VHD - это просто дельта блоков. И это значит, что без дочерний VHD превратится в тыкву при потере/повреждении родительского.
В >>721636 я имел в виду обычный плоский VHD, на который просто помещается приложение, его зависимости и данные, как на физическую флешку, а потом временно монтируется по необходимости.
Изоляция, которую обеспечивает именно VHD - что это отдельный том. Т.е. это не та изоляция, которую обеспечивает Sandboxie, а просто, кхм, "организационная" изоляция, т.е. в дополнение к ней ещё нужно подобное решение.
>Означает ли это что я могу создать отдельный от ОС родительский VHD2, и без загрузки в WinPE смонтировать его на диск C: так, что он станет виртуальным прозрачным слоем накапливающим изменения и устанавливать в него приложения? По необходимости монтировать\отмонтировать такие диски и менять набор установленных программ в системе?
Нет. Вернее, не совсем.
Отдельный от ОС - плоский VHD. Его можно отобразить через "Управление дисками", а потом создать условный C:\mnt\appname и через ту же оснастку смонтировать в него том с VHD. Если потом посмотреть на этот каталог через FAR - он превращается в симлинк на путь вида \\.\Volume... и там UUID, ссылающийся либо на Session Manager, либо куда-то в \System Volume Information\RemoteMountpointDatabase (не помню точный путь, но суть именно такая).
>он станет виртуальным прозрачным слоем накапливающим изменения
Этим как раз занимается Sandboxie. И, возможно, LANDesk тоже.
В случае Sandboxie - сам каталог песочницы тоже содержит дельту, но уже на файловом уровне.
Тогда, скорее, так:
1. Монтируешь плоский VHDn в C:\mnt\appname.
2. Создаёшь в нём новую песочницу Sandboxie и ставишь туда приложение.
3. По окончании работы разрегистрируешь песочницу перед размонтированием VHD.
4. Для продолжения работы - повторяешь п. 1 и повторно регистрируешь песочницу. Правда, я не уверен, что Sandboxie в принципе так умеет.
Но ThinApp и LANDesk, скорее всего, делают то же самое, только автоматизированно, и там логика работы песочницы встроена в файл контейнера (в случае LANDesk, похоже, меняется сам exe, а ThinApp, вроде, создаёт рядом файл дельты, проприетарного формата).
С ними п. 2 меняется на "формируешь пакет ThinApp", а п. 4 - на "повторяешь п. 1 и запускаешь exe из корня VHD".
>сбросом всех изменений после перезагрузки
А если нужно, чтобы контейнер не имел состояния - тогда да, Windows PE с плагинами, обеспечивающими нужными зависимостями. ИМХО, самое лаконичное решение, но это ИМХО, а майками оно не одобрено.
Поэтому есть ещё некое приложение "Time Travel", которое обеспечивает именно откат при перезагрузке состояния обычной Windows, это состояние имеющей.
Плюс штатные инструменты - один в составе виндосервера (вроде, редакии MultiPoint), другой - видел упоминание в списке компонентов корпоративной 10.
>как запихать все настройки отдельного приложения и все изменения которые оно вносит в систему в отдельный образ
Не Sandboxie, так ThinApp, его аналоги или эквивалентные костыли на скриптах/reg-файлах, но тут вопрос за устоявшимися практиками.
>Записи реестра физически хранятся в system32\config?
Да, но не всё так просто. Каждый файл содержит по целой ветке первого/второго уровня, рядом лежат бинарные файлы журналов... и, иногда, автоматические бэкапы.
>Я могу выделить изменения реестра просто скопировав эту папку до/после установки целевого приложения?
Вряд ли только если, как раз, с помощью WinPE.
Но тебе, скорее всего, эти файлы и не помогут, а больше поможет - консольная утилита reg. В твоём примере - экспорт всего реестра в reg-файл до установки, ещё один - после запуска-закрытия или активации--закрытия, потом - reg-файлы в WinMerge и писать скрипты, которые будут делать импорт перед запуском запуске, экспорт и чистку установленных ключей после закрытия.
Но проблема в том, что реестр - это далеко не единственное место, где приложения хранят своё состояние, даже среди типовых мест. Есть ещё, например, Application Data и Local Settings\Application Data.
>>722554
GIMP есть в PortableApps, что в нём не хватает? ThinApp тоже не помог?
Это я понял - получается, вопрос в методичках... и я его могу лишь поддвачнуть.
В качестве возможной слабенькой опоры вспоминается только, что ещё в нулевых в UP(grade) Special видел статью или именно про это, или про организацию вечных триалов - возможно, там, помимо готовых рассматривались и какие-то такие решения... Но это предельно неточно.
Ещё один возможный вариант - закопаться в исходники PortableApps...
>>722554
Пока не совсем понял.
У тебя есть возможность подготовить VHD1 в виртуалке?
Или ты грузишься с VHD на физике?
Что именно делаешь в PE? Пока мне кажется, что это легче было бы делать в обычном stateful-окружении с развёрнутым инструментарием для сборки образов.
По поводу обновлений - если в VHD стоит система - да, всё так. Дочерний VHD - это просто дельта блоков. И это значит, что без дочерний VHD превратится в тыкву при потере/повреждении родительского.
В >>721636 я имел в виду обычный плоский VHD, на который просто помещается приложение, его зависимости и данные, как на физическую флешку, а потом временно монтируется по необходимости.
Изоляция, которую обеспечивает именно VHD - что это отдельный том. Т.е. это не та изоляция, которую обеспечивает Sandboxie, а просто, кхм, "организационная" изоляция, т.е. в дополнение к ней ещё нужно подобное решение.
Нет. Вернее, не совсем.
Отдельный от ОС - плоский VHD. Его можно отобразить через "Управление дисками", а потом создать условный C:\mnt\appname и через ту же оснастку смонтировать в него том с VHD. Если потом посмотреть на этот каталог через FAR - он превращается в симлинк на путь вида \\.\Volume... и там UUID, ссылающийся либо на Session Manager, либо куда-то в \System Volume Information\RemoteMountpointDatabase (не помню точный путь, но суть именно такая).
Этим как раз занимается Sandboxie. И, возможно, LANDesk тоже.
В случае Sandboxie - сам каталог песочницы тоже содержит дельту, но уже на файловом уровне.
Тогда, скорее, так:
1. Монтируешь плоский VHDn в C:\mnt\appname.
2. Создаёшь в нём новую песочницу Sandboxie и ставишь туда приложение.
3. По окончании работы разрегистрируешь песочницу перед размонтированием VHD.
4. Для продолжения работы - повторяешь п. 1 и повторно регистрируешь песочницу. Правда, я не уверен, что Sandboxie в принципе так умеет.
Но ThinApp и LANDesk, скорее всего, делают то же самое, только автоматизированно, и там логика работы песочницы встроена в файл контейнера (в случае LANDesk, похоже, меняется сам exe, а ThinApp, вроде, создаёт рядом файл дельты, проприетарного формата).
С ними п. 2 меняется на "формируешь пакет ThinApp", а п. 4 - на "повторяешь п. 1 и запускаешь exe из корня VHD".
А если нужно, чтобы контейнер не имел состояния - тогда да, Windows PE с плагинами, обеспечивающими нужными зависимостями. ИМХО, самое лаконичное решение, но это ИМХО, а майками оно не одобрено.
Поэтому есть ещё некое приложение "Time Travel", которое обеспечивает именно откат при перезагрузке состояния обычной Windows, это состояние имеющей.
Плюс штатные инструменты - один в составе виндосервера (вроде, редакии MultiPoint), другой - видел упоминание в списке компонентов корпоративной 10.
Не Sandboxie, так ThinApp, его аналоги или эквивалентные костыли на скриптах/reg-файлах, но тут вопрос за устоявшимися практиками.
Да, но не всё так просто. Каждый файл содержит по целой ветке первого/второго уровня, рядом лежат бинарные файлы журналов... и, иногда, автоматические бэкапы.
Вряд ли только если, как раз, с помощью WinPE.
Но тебе, скорее всего, эти файлы и не помогут, а больше поможет - консольная утилита reg. В твоём примере - экспорт всего реестра в reg-файл до установки, ещё один - после запуска-закрытия или активации--закрытия, потом - reg-файлы в WinMerge и писать скрипты, которые будут делать импорт перед запуском запуске, экспорт и чистку установленных ключей после закрытия.
Но проблема в том, что реестр - это далеко не единственное место, где приложения хранят своё состояние, даже среди типовых мест. Есть ещё, например, Application Data и Local Settings\Application Data.
>условный Фотошоп
GIMP есть в PortableApps, что в нём не хватает? ThinApp тоже не помог?
>Ищу способ как сделать руками то, то что эти инструменты делают с приложениями.
Это я понял - получается, вопрос в методичках... и я его могу лишь поддвачнуть.
В качестве возможной слабенькой опоры вспоминается только, что ещё в нулевых в UP(grade) Special видел статью или именно про это, или про организацию вечных триалов - возможно, там, помимо готовых рассматривались и какие-то такие решения... Но это предельно неточно.
Ещё один возможный вариант - закопаться в исходники PortableApps...
>>722554
>Я устанавливаю систему в родительский VHD1, далее загружаюсь в WinPE и создаю разностный дочерний VHD1 и гружусь с него. С этого момента все изменения накапливаются на нем, то есть установив прилагу я могу загрузиться в WinPE, переименовать дочерний диск, создать новый дочерний диск, загрузиться с него и установить уже другую прилагу для изоляции. Но дочерние диски будут накапливать не только изменения приложения, туда же попадут все обновления ОС например.
Пока не совсем понял.
У тебя есть возможность подготовить VHD1 в виртуалке?
Или ты грузишься с VHD на физике?
Что именно делаешь в PE? Пока мне кажется, что это легче было бы делать в обычном stateful-окружении с развёрнутым инструментарием для сборки образов.
По поводу обновлений - если в VHD стоит система - да, всё так. Дочерний VHD - это просто дельта блоков. И это значит, что без дочерний VHD превратится в тыкву при потере/повреждении родительского.
В >>721636 я имел в виду обычный плоский VHD, на который просто помещается приложение, его зависимости и данные, как на физическую флешку, а потом временно монтируется по необходимости.
Изоляция, которую обеспечивает именно VHD - что это отдельный том. Т.е. это не та изоляция, которую обеспечивает Sandboxie, а просто, кхм, "организационная" изоляция, т.е. в дополнение к ней ещё нужно подобное решение.
>Означает ли это что я могу создать отдельный от ОС родительский VHD2, и без загрузки в WinPE смонтировать его на диск C: так, что он станет виртуальным прозрачным слоем накапливающим изменения и устанавливать в него приложения? По необходимости монтировать\отмонтировать такие диски и менять набор установленных программ в системе?
Нет. Вернее, не совсем.
Отдельный от ОС - плоский VHD. Его можно отобразить через "Управление дисками", а потом создать условный C:\mnt\appname и через ту же оснастку смонтировать в него том с VHD. Если потом посмотреть на этот каталог через FAR - он превращается в симлинк на путь вида \\.\Volume... и там UUID, ссылающийся либо на Session Manager, либо куда-то в \System Volume Information\RemoteMountpointDatabase (не помню точный путь, но суть именно такая).
>он станет виртуальным прозрачным слоем накапливающим изменения
Этим как раз занимается Sandboxie. И, возможно, LANDesk тоже.
В случае Sandboxie - сам каталог песочницы тоже содержит дельту, но уже на файловом уровне.
Тогда, скорее, так:
1. Монтируешь плоский VHDn в C:\mnt\appname.
2. Создаёшь в нём новую песочницу Sandboxie и ставишь туда приложение.
3. По окончании работы разрегистрируешь песочницу перед размонтированием VHD.
4. Для продолжения работы - повторяешь п. 1 и повторно регистрируешь песочницу. Правда, я не уверен, что Sandboxie в принципе так умеет.
Но ThinApp и LANDesk, скорее всего, делают то же самое, только автоматизированно, и там логика работы песочницы встроена в файл контейнера (в случае LANDesk, похоже, меняется сам exe, а ThinApp, вроде, создаёт рядом файл дельты, проприетарного формата).
С ними п. 2 меняется на "формируешь пакет ThinApp", а п. 4 - на "повторяешь п. 1 и запускаешь exe из корня VHD".
>сбросом всех изменений после перезагрузки
А если нужно, чтобы контейнер не имел состояния - тогда да, Windows PE с плагинами, обеспечивающими нужными зависимостями. ИМХО, самое лаконичное решение, но это ИМХО, а майками оно не одобрено.
Поэтому есть ещё некое приложение "Time Travel", которое обеспечивает именно откат при перезагрузке состояния обычной Windows, это состояние имеющей.
Плюс штатные инструменты - один в составе виндосервера (вроде, редакии MultiPoint), другой - видел упоминание в списке компонентов корпоративной 10.
>как запихать все настройки отдельного приложения и все изменения которые оно вносит в систему в отдельный образ
Не Sandboxie, так ThinApp, его аналоги или эквивалентные костыли на скриптах/reg-файлах, но тут вопрос за устоявшимися практиками.
>Записи реестра физически хранятся в system32\config?
Да, но не всё так просто. Каждый файл содержит по целой ветке первого/второго уровня, рядом лежат бинарные файлы журналов... и, иногда, автоматические бэкапы.
>Я могу выделить изменения реестра просто скопировав эту папку до/после установки целевого приложения?
Вряд ли только если, как раз, с помощью WinPE.
Но тебе, скорее всего, эти файлы и не помогут, а больше поможет - консольная утилита reg. В твоём примере - экспорт всего реестра в reg-файл до установки, ещё один - после запуска-закрытия или активации--закрытия, потом - reg-файлы в WinMerge и писать скрипты, которые будут делать импорт перед запуском запуске, экспорт и чистку установленных ключей после закрытия.
Но проблема в том, что реестр - это далеко не единственное место, где приложения хранят своё состояние, даже среди типовых мест. Есть ещё, например, Application Data и Local Settings\Application Data.
Сорян за опечатки, но тот абзац с "Я устанавливаю систему..." я сам не понял.
Там же речь не про VDI была, а про портативизацию приложений? И проблема Sandboxie - в том, что он сам не портативный и/или предназначен не для портативизации?
Там же речь не про VDI была, а про портативизацию приложений? И проблема Sandboxie - в том, что он сам не портативный и/или предназначен не для портативизации?
>>703783
Аполлон создали без этого говна
Кстати все сервера, кроме совсем маргинальщины, на Unix системах
> ВСЕ, АБСОЛЮТНО ВСЕ ПРОФЕССИОНАЛЬНЫЕ КАД системы для Mechanical Engineering и Industrial Design есть только на Винде
Аполлон создали без этого говна
Кстати все сервера, кроме совсем маргинальщины, на Unix системах
>>722665
Гружусь с VHD на физике Native Boot, есть возможность установить Hyper-V и подготовить VHD1 в вируталке. В PE через Diskpart создаю цепочку родитель.vhd > ребёнок.vhd делаю его бэкап ребёнок.vhd_bak С этого момента появляется возможность скопировать куда-то изменения в WinPE с ребёнок.vhd, удалить его и откатиться к чистой системе переименовав ребёнок.vhd_bak. Проблема только в том как выделить все изменения в образ и ничего не упустить но при этом не насохранять говняка, который пишут системные службы. А потом ловко обмануть систему смонтировав образ с изменениями в голую систему + применить ключи реестра.
Анон, хотелось бы уйти от проприетарного говняка. К сожалению в Sandboxie не все приложения хотят вставать\запускаться.
То есть теоретически можно сделать экспорт в regedit всего реестра Before.reg , потом установить приложение, повторно сделать экспорт реестра After.reg, затем скопировать каждый каталог созданный при установке приложения в отдельный VHD для каждого каталога ApplicationData.vhd и LocalSettingsApplicationData.vhd итд
После чего надо при пом. WinMerge создать reg файл на основе разницы Before.reg и After.reg? Или WinMerge это исключительно сортировка папок с файлами? Является ли сортировка system32\config на предмет было\стало алтернативой работы с reg файлами? Может есть какой-то текстовый редактор который создаст разница.reg из Before.reg и After.reg?
Какие плагины нужны чтобы появился Edge для нетсёрфа в PE?
Могу ли я из WinPE запустить загрузку Win10\11 на отдельном диске?
>У тебя есть возможность подготовить VHD1 в виртуалке?
>Или ты грузишься с VHD на физике?
>Что именно делаешь в PE?
Гружусь с VHD на физике Native Boot, есть возможность установить Hyper-V и подготовить VHD1 в вируталке. В PE через Diskpart создаю цепочку родитель.vhd > ребёнок.vhd делаю его бэкап ребёнок.vhd_bak С этого момента появляется возможность скопировать куда-то изменения в WinPE с ребёнок.vhd, удалить его и откатиться к чистой системе переименовав ребёнок.vhd_bak. Проблема только в том как выделить все изменения в образ и ничего не упустить но при этом не насохранять говняка, который пишут системные службы. А потом ловко обмануть систему смонтировав образ с изменениями в голую систему + применить ключи реестра.
>ThinApp
>LANDesk
Анон, хотелось бы уйти от проприетарного говняка. К сожалению в Sandboxie не все приложения хотят вставать\запускаться.
>C:\mnt\appname и через ту же оснастку смонтировать в него том с VHD. Если потом посмотреть на этот каталог через >FAR - он превращается в симлинк на путь вида \\.\Volume... и там UUID, ссылающийся либо на Session Manager, либо >куда-то в \System Volume Information\RemoteMountpointDatabase (не помню точный путь, но суть именно такая).
То есть теоретически можно сделать экспорт в regedit всего реестра Before.reg , потом установить приложение, повторно сделать экспорт реестра After.reg, затем скопировать каждый каталог созданный при установке приложения в отдельный VHD для каждого каталога ApplicationData.vhd и LocalSettingsApplicationData.vhd итд
После чего надо при пом. WinMerge создать reg файл на основе разницы Before.reg и After.reg? Или WinMerge это исключительно сортировка папок с файлами? Является ли сортировка system32\config на предмет было\стало алтернативой работы с reg файлами? Может есть какой-то текстовый редактор который создаст разница.reg из Before.reg и After.reg?
>Windows PE с плагинами, обеспечивающими нужными зависимостями.
Какие плагины нужны чтобы появился Edge для нетсёрфа в PE?
Могу ли я из WinPE запустить загрузку Win10\11 на отдельном диске?
>>722665
Гружусь с VHD на физике Native Boot, есть возможность установить Hyper-V и подготовить VHD1 в вируталке. В PE через Diskpart создаю цепочку родитель.vhd > ребёнок.vhd делаю его бэкап ребёнок.vhd_bak С этого момента появляется возможность скопировать куда-то изменения в WinPE с ребёнок.vhd, удалить его и откатиться к чистой системе переименовав ребёнок.vhd_bak. Проблема только в том как выделить все изменения в образ и ничего не упустить но при этом не насохранять говняка, который пишут системные службы. А потом ловко обмануть систему смонтировав образ с изменениями в голую систему + применить ключи реестра.
Анон, хотелось бы уйти от проприетарного говняка. К сожалению в Sandboxie не все приложения хотят вставать\запускаться.
То есть теоретически можно сделать экспорт в regedit всего реестра Before.reg , потом установить приложение, повторно сделать экспорт реестра After.reg, затем скопировать каждый каталог созданный при установке приложения в отдельный VHD для каждого каталога ApplicationData.vhd и LocalSettingsApplicationData.vhd итд
После чего надо при пом. WinMerge создать reg файл на основе разницы Before.reg и After.reg? Или WinMerge это исключительно сортировка папок с файлами? Является ли сортировка system32\config на предмет было\стало алтернативой работы с reg файлами? Может есть какой-то текстовый редактор который создаст разница.reg из Before.reg и After.reg?
Какие плагины нужны чтобы появился Edge для нетсёрфа в PE?
Могу ли я из WinPE запустить загрузку Win10\11 на отдельном диске?
>У тебя есть возможность подготовить VHD1 в виртуалке?
>Или ты грузишься с VHD на физике?
>Что именно делаешь в PE?
Гружусь с VHD на физике Native Boot, есть возможность установить Hyper-V и подготовить VHD1 в вируталке. В PE через Diskpart создаю цепочку родитель.vhd > ребёнок.vhd делаю его бэкап ребёнок.vhd_bak С этого момента появляется возможность скопировать куда-то изменения в WinPE с ребёнок.vhd, удалить его и откатиться к чистой системе переименовав ребёнок.vhd_bak. Проблема только в том как выделить все изменения в образ и ничего не упустить но при этом не насохранять говняка, который пишут системные службы. А потом ловко обмануть систему смонтировав образ с изменениями в голую систему + применить ключи реестра.
>ThinApp
>LANDesk
Анон, хотелось бы уйти от проприетарного говняка. К сожалению в Sandboxie не все приложения хотят вставать\запускаться.
>C:\mnt\appname и через ту же оснастку смонтировать в него том с VHD. Если потом посмотреть на этот каталог через >FAR - он превращается в симлинк на путь вида \\.\Volume... и там UUID, ссылающийся либо на Session Manager, либо >куда-то в \System Volume Information\RemoteMountpointDatabase (не помню точный путь, но суть именно такая).
То есть теоретически можно сделать экспорт в regedit всего реестра Before.reg , потом установить приложение, повторно сделать экспорт реестра After.reg, затем скопировать каждый каталог созданный при установке приложения в отдельный VHD для каждого каталога ApplicationData.vhd и LocalSettingsApplicationData.vhd итд
После чего надо при пом. WinMerge создать reg файл на основе разницы Before.reg и After.reg? Или WinMerge это исключительно сортировка папок с файлами? Является ли сортировка system32\config на предмет было\стало алтернативой работы с reg файлами? Может есть какой-то текстовый редактор который создаст разница.reg из Before.reg и After.reg?
>Windows PE с плагинами, обеспечивающими нужными зависимостями.
Какие плагины нужны чтобы появился Edge для нетсёрфа в PE?
Могу ли я из WinPE запустить загрузку Win10\11 на отдельном диске?
Почему у меня VRAM только 4mb (пик 1 и 2), если у меня поставлен 1gb (пик 3)?
Win10
Vmware workstation pro 16
Win10
Vmware workstation pro 16
>>723722
На моих машинах винда также 4 МБ показывает. Работе не мешает. Хз что за прикол, быть может драйвер VMware так реализован
На моих машинах винда также 4 МБ показывает. Работе не мешает. Хз что за прикол, быть может драйвер VMware так реализован
>>723054
Пока всё равно не понял. Связку родительского и дочернего VHD можно сконвертировать в независимый плоский образ, но тогда он будет содержать полное состояние системы. Потом, конечно, можно будет получить файловую дельту, если одновременно смонтировать (только для чтения) родительский VHD и этот вот плоский-произвольный (и да, потом таки можно будет прогнать по корням этих томов WinMerge), но, насколько я понимаю, это всё равно может быть немного не то.
Алсо, зачем бэкапить только что созданный дочерний VHD, если его всегда можно пересоздать (а на родительский, естественно, поставить атрибут R/O)?
Тогда, возможно, имеет смысл упомянуть приложения. Или, если есть такое понимание - что они такого делают несовместимого с Sandboxie.
Что можно сказать сразу - если приложение зависит от каких-то особенных драйверов, с ними и упомянутые мной мокрописьки не помогут.
Да.
В целом - да, только:
- названное мной - лишь примеры, где приложение может хранить своё состояние. Куда именно пишет твоё приложение - тебе нужно будет отследить самому. Sandboxie тебе как раз может в этом помочь: ставишь приложение внутри песочницы, затем (для чистоты) останавливаешь песочницу, открываешь её каталог в проводнике вне песочницы (ЕМНИП, они создаются прямо в корне C: как C:\SandboxName) - в этом случае ты увидишь только файлы дельты.
Вроде того. Это просто очень улучшенный аналог diff (может сравнить файлы и выделить дельту) или vimdiff (может эту дельту визуально показать), только он так же может сравнивать не только файлы, но и файловые деревья (ближайший аналог в никсах - meld, его не рекомендую), а также имеет кучу разных настроек по деталям сравнения (вроде "считать ли разрывы строк \r\n и \n эквивалентными") и плагинов, например, для содержимого архивов (подобно обычным файловым деревьям), даже что-то для сравнения изображений припоминается (как я понял, для сравнения попиксельного, а не тупо бинарного, но я мог понять неправильно). Дальнейший анализ отличий и составление дельты всё равно придётся проводить вручную (хотя какие-то операции он и может минимально автоматизировать, но это в смысле, что, например, он может сам из каталога в левой панели скопировать файл в правую панель, чтобы устранить отличие - если об этом его явно попросить через контекстное меню).
Нет. Реестр - это такая специальная СУБД, а файлы в каталоге config - это файлы некоего внутреннего бинарного формата, одной этой СУБД понятного, со всеми вытекающими.
А reg-файл - это текстовый файл ini-подобной структуры, содержащий только "полезные" данные, и его уже можно прогонять через любой diff/gvimdiff/WinMerge или другие подобные инструменты.
Как бы, если берём ту же MariaDB - в каталоге, в котором хранится рабочая копия базы, ты увидишь кучу бинарных файлов - в зависимости от драйвера это будет по файлу на таблицу или один большой файл, могут быть отдельные файлы журнала - тоже бинарные. И когда условному DBA просто нужно полностью забрать всё, что лежит в таблице - он снимает дамп (файл с состоянием .sql), который только это и содержит (в случае SQL - он тупо содержит команды для создания таблицы с нужным параметром и последовательного добавления в неё каждой строчки, которая на момент создания дампа не была помечена как удалённая, поверх любых одноимённых объектов, существующих в любой базе, на которую этот дамп потом применят.
И для СУБД классической является ситуация, что удалённые строчки из таблицы не удаляются, а только помечаются как удалённые, пока не будет выполнена операция purge (которая в русскоязычном UI почему-то всегда некорректно называется "сжатием") - например, в PostgreSQL для этого есть нестандартная команда VACUUM (а в MySQL для такого приходится дампить и пересоздавать таблицу из дампа - серьёзно, куча тредов на StackOverflow есть с вопросами вида: "памагити-тити, мы уже 20 таблиц удалили, но файл базы только вырос, у нас скоро место в корне кончится!1" - и ответами вида: "да, InnoDB так и работает, и таки да, нужно прямо сейчас остановить сервис, сделать дамп и пересоздать базу из дампа (пока сервис не встал от переполнения корня), а вообще, подкрутите вчера такой-то параметр, чтобы каждая таблица хранилась в отдельном файле, тогда хотя бы можно будет пересоздавать по таблице за раз, и вообще, используйте другой драйвер"). И "рабочие" файлы базы до и после VACUUM будут отличаться, а файл дампа - нет.
В принципе, даже с реестром есть подобная ерундистика - его, оказывается, например, нужно дефрагментировать, для чего существуют отдельные мокрописьки.
Боюсь, что нет. В смысле, инструменты вроде WinMerge, конечно и существует для того, чтобы помочь - визуально выделить, какие строки совпадают, какие - отличаются, и чем именно. Но итоговый файл дельты всё равно придётся создавать самостоятельно.
>>723818
Вполне возможно, что именно так и есть. Вообще, этот драйвер - он работает не очень прозрачно для гостевой ОС. Т.е. не так, что, например, гипервизор принимает вызовы графических API от видеодрайвера и исполняет их в рамках отрисовки консоли ВМ - нет, как раз наоборот, видеодрайвер тупо форвардит эти вызовы в канал взаимодействия (называемый "бэкдором" в терминологии вари), используемый всякими shared folders. И перестаёт работать, если начать прописывать в *.vmx всякие параметры для изоляции ВМ, этот видеодрайвер перестаёт работать. Вроде, перестаёт, даже если просто запретить гипервизору и гостевой ОС обмениваться данными об используемой версии VMWare Tools.
>Гружусь с VHD на физике Native Boot, есть возможность установить Hyper-V и подготовить VHD1 в вируталке. В PE через Diskpart создаю цепочку родитель.vhd > ребёнок.vhd делаю его бэкап ребёнок.vhd_bak С этого момента появляется возможность скопировать куда-то изменения в WinPE с ребёнок.vhd, удалить его и откатиться к чистой системе переименовав ребёнок.vhd_bak. Проблема только в том как выделить все изменения в образ и ничего не упустить но при этом не насохранять говняка, который пишут системные службы. А потом ловко обмануть систему смонтировав образ с изменениями в голую систему + применить ключи реестра.
Пока всё равно не понял. Связку родительского и дочернего VHD можно сконвертировать в независимый плоский образ, но тогда он будет содержать полное состояние системы. Потом, конечно, можно будет получить файловую дельту, если одновременно смонтировать (только для чтения) родительский VHD и этот вот плоский-произвольный (и да, потом таки можно будет прогнать по корням этих томов WinMerge), но, насколько я понимаю, это всё равно может быть немного не то.
Алсо, зачем бэкапить только что созданный дочерний VHD, если его всегда можно пересоздать (а на родительский, естественно, поставить атрибут R/O)?
>К сожалению в Sandboxie не все приложения хотят вставать\запускаться.
Тогда, возможно, имеет смысл упомянуть приложения. Или, если есть такое понимание - что они такого делают несовместимого с Sandboxie.
Что можно сказать сразу - если приложение зависит от каких-то особенных драйверов, с ними и упомянутые мной мокрописьки не помогут.
>То есть теоретически можно сделать экспорт в regedit всего реестра Before.reg , потом установить приложение, повторно сделать экспорт реестра After.reg
Да.
>затем скопировать каждый каталог созданный при установке приложения в отдельный VHD для каждого каталога ApplicationData.vhd и LocalSettingsApplicationData.vhd итд
В целом - да, только:
- названное мной - лишь примеры, где приложение может хранить своё состояние. Куда именно пишет твоё приложение - тебе нужно будет отследить самому. Sandboxie тебе как раз может в этом помочь: ставишь приложение внутри песочницы, затем (для чистоты) останавливаешь песочницу, открываешь её каталог в проводнике вне песочницы (ЕМНИП, они создаются прямо в корне C: как C:\SandboxName) - в этом случае ты увидишь только файлы дельты.
>Или WinMerge это исключительно сортировка папок с файлами?
Вроде того. Это просто очень улучшенный аналог diff (может сравнить файлы и выделить дельту) или vimdiff (может эту дельту визуально показать), только он так же может сравнивать не только файлы, но и файловые деревья (ближайший аналог в никсах - meld, его не рекомендую), а также имеет кучу разных настроек по деталям сравнения (вроде "считать ли разрывы строк \r\n и \n эквивалентными") и плагинов, например, для содержимого архивов (подобно обычным файловым деревьям), даже что-то для сравнения изображений припоминается (как я понял, для сравнения попиксельного, а не тупо бинарного, но я мог понять неправильно). Дальнейший анализ отличий и составление дельты всё равно придётся проводить вручную (хотя какие-то операции он и может минимально автоматизировать, но это в смысле, что, например, он может сам из каталога в левой панели скопировать файл в правую панель, чтобы устранить отличие - если об этом его явно попросить через контекстное меню).
>Является ли сортировка system32\config на предмет было\стало алтернативой работы с reg файлами?
Нет. Реестр - это такая специальная СУБД, а файлы в каталоге config - это файлы некоего внутреннего бинарного формата, одной этой СУБД понятного, со всеми вытекающими.
А reg-файл - это текстовый файл ini-подобной структуры, содержащий только "полезные" данные, и его уже можно прогонять через любой diff/gvimdiff/WinMerge или другие подобные инструменты.
Как бы, если берём ту же MariaDB - в каталоге, в котором хранится рабочая копия базы, ты увидишь кучу бинарных файлов - в зависимости от драйвера это будет по файлу на таблицу или один большой файл, могут быть отдельные файлы журнала - тоже бинарные. И когда условному DBA просто нужно полностью забрать всё, что лежит в таблице - он снимает дамп (файл с состоянием .sql), который только это и содержит (в случае SQL - он тупо содержит команды для создания таблицы с нужным параметром и последовательного добавления в неё каждой строчки, которая на момент создания дампа не была помечена как удалённая, поверх любых одноимённых объектов, существующих в любой базе, на которую этот дамп потом применят.
И для СУБД классической является ситуация, что удалённые строчки из таблицы не удаляются, а только помечаются как удалённые, пока не будет выполнена операция purge (которая в русскоязычном UI почему-то всегда некорректно называется "сжатием") - например, в PostgreSQL для этого есть нестандартная команда VACUUM (а в MySQL для такого приходится дампить и пересоздавать таблицу из дампа - серьёзно, куча тредов на StackOverflow есть с вопросами вида: "памагити-тити, мы уже 20 таблиц удалили, но файл базы только вырос, у нас скоро место в корне кончится!1" - и ответами вида: "да, InnoDB так и работает, и таки да, нужно прямо сейчас остановить сервис, сделать дамп и пересоздать базу из дампа (пока сервис не встал от переполнения корня), а вообще, подкрутите вчера такой-то параметр, чтобы каждая таблица хранилась в отдельном файле, тогда хотя бы можно будет пересоздавать по таблице за раз, и вообще, используйте другой драйвер"). И "рабочие" файлы базы до и после VACUUM будут отличаться, а файл дампа - нет.
В принципе, даже с реестром есть подобная ерундистика - его, оказывается, например, нужно дефрагментировать, для чего существуют отдельные мокрописьки.
>Может есть какой-то текстовый редактор который создаст разница.reg из Before.reg и After.reg?
Боюсь, что нет. В смысле, инструменты вроде WinMerge, конечно и существует для того, чтобы помочь - визуально выделить, какие строки совпадают, какие - отличаются, и чем именно. Но итоговый файл дельты всё равно придётся создавать самостоятельно.
>>723818
>драйвер VMware так реализован
Вполне возможно, что именно так и есть. Вообще, этот драйвер - он работает не очень прозрачно для гостевой ОС. Т.е. не так, что, например, гипервизор принимает вызовы графических API от видеодрайвера и исполняет их в рамках отрисовки консоли ВМ - нет, как раз наоборот, видеодрайвер тупо форвардит эти вызовы в канал взаимодействия (называемый "бэкдором" в терминологии вари), используемый всякими shared folders. И перестаёт работать, если начать прописывать в *.vmx всякие параметры для изоляции ВМ, этот видеодрайвер перестаёт работать. Вроде, перестаёт, даже если просто запретить гипервизору и гостевой ОС обмениваться данными об используемой версии VMWare Tools.
>>723054
Пока всё равно не понял. Связку родительского и дочернего VHD можно сконвертировать в независимый плоский образ, но тогда он будет содержать полное состояние системы. Потом, конечно, можно будет получить файловую дельту, если одновременно смонтировать (только для чтения) родительский VHD и этот вот плоский-произвольный (и да, потом таки можно будет прогнать по корням этих томов WinMerge), но, насколько я понимаю, это всё равно может быть немного не то.
Алсо, зачем бэкапить только что созданный дочерний VHD, если его всегда можно пересоздать (а на родительский, естественно, поставить атрибут R/O)?
Тогда, возможно, имеет смысл упомянуть приложения. Или, если есть такое понимание - что они такого делают несовместимого с Sandboxie.
Что можно сказать сразу - если приложение зависит от каких-то особенных драйверов, с ними и упомянутые мной мокрописьки не помогут.
Да.
В целом - да, только:
- названное мной - лишь примеры, где приложение может хранить своё состояние. Куда именно пишет твоё приложение - тебе нужно будет отследить самому. Sandboxie тебе как раз может в этом помочь: ставишь приложение внутри песочницы, затем (для чистоты) останавливаешь песочницу, открываешь её каталог в проводнике вне песочницы (ЕМНИП, они создаются прямо в корне C: как C:\SandboxName) - в этом случае ты увидишь только файлы дельты.
Вроде того. Это просто очень улучшенный аналог diff (может сравнить файлы и выделить дельту) или vimdiff (может эту дельту визуально показать), только он так же может сравнивать не только файлы, но и файловые деревья (ближайший аналог в никсах - meld, его не рекомендую), а также имеет кучу разных настроек по деталям сравнения (вроде "считать ли разрывы строк \r\n и \n эквивалентными") и плагинов, например, для содержимого архивов (подобно обычным файловым деревьям), даже что-то для сравнения изображений припоминается (как я понял, для сравнения попиксельного, а не тупо бинарного, но я мог понять неправильно). Дальнейший анализ отличий и составление дельты всё равно придётся проводить вручную (хотя какие-то операции он и может минимально автоматизировать, но это в смысле, что, например, он может сам из каталога в левой панели скопировать файл в правую панель, чтобы устранить отличие - если об этом его явно попросить через контекстное меню).
Нет. Реестр - это такая специальная СУБД, а файлы в каталоге config - это файлы некоего внутреннего бинарного формата, одной этой СУБД понятного, со всеми вытекающими.
А reg-файл - это текстовый файл ini-подобной структуры, содержащий только "полезные" данные, и его уже можно прогонять через любой diff/gvimdiff/WinMerge или другие подобные инструменты.
Как бы, если берём ту же MariaDB - в каталоге, в котором хранится рабочая копия базы, ты увидишь кучу бинарных файлов - в зависимости от драйвера это будет по файлу на таблицу или один большой файл, могут быть отдельные файлы журнала - тоже бинарные. И когда условному DBA просто нужно полностью забрать всё, что лежит в таблице - он снимает дамп (файл с состоянием .sql), который только это и содержит (в случае SQL - он тупо содержит команды для создания таблицы с нужным параметром и последовательного добавления в неё каждой строчки, которая на момент создания дампа не была помечена как удалённая, поверх любых одноимённых объектов, существующих в любой базе, на которую этот дамп потом применят.
И для СУБД классической является ситуация, что удалённые строчки из таблицы не удаляются, а только помечаются как удалённые, пока не будет выполнена операция purge (которая в русскоязычном UI почему-то всегда некорректно называется "сжатием") - например, в PostgreSQL для этого есть нестандартная команда VACUUM (а в MySQL для такого приходится дампить и пересоздавать таблицу из дампа - серьёзно, куча тредов на StackOverflow есть с вопросами вида: "памагити-тити, мы уже 20 таблиц удалили, но файл базы только вырос, у нас скоро место в корне кончится!1" - и ответами вида: "да, InnoDB так и работает, и таки да, нужно прямо сейчас остановить сервис, сделать дамп и пересоздать базу из дампа (пока сервис не встал от переполнения корня), а вообще, подкрутите вчера такой-то параметр, чтобы каждая таблица хранилась в отдельном файле, тогда хотя бы можно будет пересоздавать по таблице за раз, и вообще, используйте другой драйвер"). И "рабочие" файлы базы до и после VACUUM будут отличаться, а файл дампа - нет.
В принципе, даже с реестром есть подобная ерундистика - его, оказывается, например, нужно дефрагментировать, для чего существуют отдельные мокрописьки.
Боюсь, что нет. В смысле, инструменты вроде WinMerge, конечно и существует для того, чтобы помочь - визуально выделить, какие строки совпадают, какие - отличаются, и чем именно. Но итоговый файл дельты всё равно придётся создавать самостоятельно.
>>723818
Вполне возможно, что именно так и есть. Вообще, этот драйвер - он работает не очень прозрачно для гостевой ОС. Т.е. не так, что, например, гипервизор принимает вызовы графических API от видеодрайвера и исполняет их в рамках отрисовки консоли ВМ - нет, как раз наоборот, видеодрайвер тупо форвардит эти вызовы в канал взаимодействия (называемый "бэкдором" в терминологии вари), используемый всякими shared folders. И перестаёт работать, если начать прописывать в *.vmx всякие параметры для изоляции ВМ, этот видеодрайвер перестаёт работать. Вроде, перестаёт, даже если просто запретить гипервизору и гостевой ОС обмениваться данными об используемой версии VMWare Tools.
>Гружусь с VHD на физике Native Boot, есть возможность установить Hyper-V и подготовить VHD1 в вируталке. В PE через Diskpart создаю цепочку родитель.vhd > ребёнок.vhd делаю его бэкап ребёнок.vhd_bak С этого момента появляется возможность скопировать куда-то изменения в WinPE с ребёнок.vhd, удалить его и откатиться к чистой системе переименовав ребёнок.vhd_bak. Проблема только в том как выделить все изменения в образ и ничего не упустить но при этом не насохранять говняка, который пишут системные службы. А потом ловко обмануть систему смонтировав образ с изменениями в голую систему + применить ключи реестра.
Пока всё равно не понял. Связку родительского и дочернего VHD можно сконвертировать в независимый плоский образ, но тогда он будет содержать полное состояние системы. Потом, конечно, можно будет получить файловую дельту, если одновременно смонтировать (только для чтения) родительский VHD и этот вот плоский-произвольный (и да, потом таки можно будет прогнать по корням этих томов WinMerge), но, насколько я понимаю, это всё равно может быть немного не то.
Алсо, зачем бэкапить только что созданный дочерний VHD, если его всегда можно пересоздать (а на родительский, естественно, поставить атрибут R/O)?
>К сожалению в Sandboxie не все приложения хотят вставать\запускаться.
Тогда, возможно, имеет смысл упомянуть приложения. Или, если есть такое понимание - что они такого делают несовместимого с Sandboxie.
Что можно сказать сразу - если приложение зависит от каких-то особенных драйверов, с ними и упомянутые мной мокрописьки не помогут.
>То есть теоретически можно сделать экспорт в regedit всего реестра Before.reg , потом установить приложение, повторно сделать экспорт реестра After.reg
Да.
>затем скопировать каждый каталог созданный при установке приложения в отдельный VHD для каждого каталога ApplicationData.vhd и LocalSettingsApplicationData.vhd итд
В целом - да, только:
- названное мной - лишь примеры, где приложение может хранить своё состояние. Куда именно пишет твоё приложение - тебе нужно будет отследить самому. Sandboxie тебе как раз может в этом помочь: ставишь приложение внутри песочницы, затем (для чистоты) останавливаешь песочницу, открываешь её каталог в проводнике вне песочницы (ЕМНИП, они создаются прямо в корне C: как C:\SandboxName) - в этом случае ты увидишь только файлы дельты.
>Или WinMerge это исключительно сортировка папок с файлами?
Вроде того. Это просто очень улучшенный аналог diff (может сравнить файлы и выделить дельту) или vimdiff (может эту дельту визуально показать), только он так же может сравнивать не только файлы, но и файловые деревья (ближайший аналог в никсах - meld, его не рекомендую), а также имеет кучу разных настроек по деталям сравнения (вроде "считать ли разрывы строк \r\n и \n эквивалентными") и плагинов, например, для содержимого архивов (подобно обычным файловым деревьям), даже что-то для сравнения изображений припоминается (как я понял, для сравнения попиксельного, а не тупо бинарного, но я мог понять неправильно). Дальнейший анализ отличий и составление дельты всё равно придётся проводить вручную (хотя какие-то операции он и может минимально автоматизировать, но это в смысле, что, например, он может сам из каталога в левой панели скопировать файл в правую панель, чтобы устранить отличие - если об этом его явно попросить через контекстное меню).
>Является ли сортировка system32\config на предмет было\стало алтернативой работы с reg файлами?
Нет. Реестр - это такая специальная СУБД, а файлы в каталоге config - это файлы некоего внутреннего бинарного формата, одной этой СУБД понятного, со всеми вытекающими.
А reg-файл - это текстовый файл ini-подобной структуры, содержащий только "полезные" данные, и его уже можно прогонять через любой diff/gvimdiff/WinMerge или другие подобные инструменты.
Как бы, если берём ту же MariaDB - в каталоге, в котором хранится рабочая копия базы, ты увидишь кучу бинарных файлов - в зависимости от драйвера это будет по файлу на таблицу или один большой файл, могут быть отдельные файлы журнала - тоже бинарные. И когда условному DBA просто нужно полностью забрать всё, что лежит в таблице - он снимает дамп (файл с состоянием .sql), который только это и содержит (в случае SQL - он тупо содержит команды для создания таблицы с нужным параметром и последовательного добавления в неё каждой строчки, которая на момент создания дампа не была помечена как удалённая, поверх любых одноимённых объектов, существующих в любой базе, на которую этот дамп потом применят.
И для СУБД классической является ситуация, что удалённые строчки из таблицы не удаляются, а только помечаются как удалённые, пока не будет выполнена операция purge (которая в русскоязычном UI почему-то всегда некорректно называется "сжатием") - например, в PostgreSQL для этого есть нестандартная команда VACUUM (а в MySQL для такого приходится дампить и пересоздавать таблицу из дампа - серьёзно, куча тредов на StackOverflow есть с вопросами вида: "памагити-тити, мы уже 20 таблиц удалили, но файл базы только вырос, у нас скоро место в корне кончится!1" - и ответами вида: "да, InnoDB так и работает, и таки да, нужно прямо сейчас остановить сервис, сделать дамп и пересоздать базу из дампа (пока сервис не встал от переполнения корня), а вообще, подкрутите вчера такой-то параметр, чтобы каждая таблица хранилась в отдельном файле, тогда хотя бы можно будет пересоздавать по таблице за раз, и вообще, используйте другой драйвер"). И "рабочие" файлы базы до и после VACUUM будут отличаться, а файл дампа - нет.
В принципе, даже с реестром есть подобная ерундистика - его, оказывается, например, нужно дефрагментировать, для чего существуют отдельные мокрописьки.
>Может есть какой-то текстовый редактор который создаст разница.reg из Before.reg и After.reg?
Боюсь, что нет. В смысле, инструменты вроде WinMerge, конечно и существует для того, чтобы помочь - визуально выделить, какие строки совпадают, какие - отличаются, и чем именно. Но итоговый файл дельты всё равно придётся создавать самостоятельно.
>>723818
>драйвер VMware так реализован
Вполне возможно, что именно так и есть. Вообще, этот драйвер - он работает не очень прозрачно для гостевой ОС. Т.е. не так, что, например, гипервизор принимает вызовы графических API от видеодрайвера и исполняет их в рамках отрисовки консоли ВМ - нет, как раз наоборот, видеодрайвер тупо форвардит эти вызовы в канал взаимодействия (называемый "бэкдором" в терминологии вари), используемый всякими shared folders. И перестаёт работать, если начать прописывать в *.vmx всякие параметры для изоляции ВМ, этот видеодрайвер перестаёт работать. Вроде, перестаёт, даже если просто запретить гипервизору и гостевой ОС обмениваться данными об используемой версии VMWare Tools.
>>723818
>>723892
Вывод: если от приложения гостевой ОС нужно скрыть, что она в виртуалке - она не может использовать драйвера VMWare VGA/SVGA, и именно в этом случае проблема не только в том. что драйвер может быть знаком детектилке, но и что это драйвер использует слишком палевный метод взаимоедйствия с гипервизором - и перестаёт работать, если палево попытаться отключить со стороны хоста.
Соответственно, если нужно, чтобы виртуалка видела какую-то нормальную видеокарту, но не знала, что является виртуалкой - во-первых, это только к KVM, Xen или, может быть, ESXi, во-вторых - без IOMMU и запасной карточки никак.
Либо - всякие PCem/Bochs... или qemu-3dfx. И, скорее всего, очень мощный хост, который может потянуть PCem, эмулирующий Celeron-533.
>>723892
>Вообще, этот драйвер - он работает не очень прозрачно для гостевой ОС.
Вывод: если от приложения гостевой ОС нужно скрыть, что она в виртуалке - она не может использовать драйвера VMWare VGA/SVGA, и именно в этом случае проблема не только в том. что драйвер может быть знаком детектилке, но и что это драйвер использует слишком палевный метод взаимоедйствия с гипервизором - и перестаёт работать, если палево попытаться отключить со стороны хоста.
Соответственно, если нужно, чтобы виртуалка видела какую-то нормальную видеокарту, но не знала, что является виртуалкой - во-первых, это только к KVM, Xen или, может быть, ESXi, во-вторых - без IOMMU и запасной карточки никак.
Либо - всякие PCem/Bochs... или qemu-3dfx. И, скорее всего, очень мощный хост, который может потянуть PCem, эмулирующий Celeron-533.
>>682874
Надо отдельный компьютер, отдельный провайдер и отделный роутер
Надо отдельный компьютер, отдельный провайдер и отделный роутер
>>723892
Почему не то? Мне как раз файловая дельта + дельта реестра и нужна. Но при моём подходе ИМХО меньше телодвижений. В PE монтируешь дочерний образ с установленной приложухой, монтируешь сохранённый бэкап этого дочернего образа без приложухи. Копируешь дельту в этот бэкап. Потом грузишься с этого бэкапа куда скопировал дельту. Правда пока у меня слетает триальный период винды и отваливается MSStore. Видимо во время установки приложухи в дельту пишется какой-то системный говняк. Ну это эмпирически можно отсеять руками я думаю.
Можно, но зачем? ИМХО CTRL+C CTRL+V проще.
На данный момент экспериментирую с докером. В Sandboxie его не установить. Попробовал руками отсеять всякий системный говняк, оставив только файлы докера, он начинает ругаться что не видит WSL хотя оно появляется в пуске, но запускается с ошибкой. Зато нет проблем с MSStore.
Да, это отлично работает и для выделения дельты идеальный инструмент, но вот докер не встаёт в песочнице.
Что же тогда мне выплюнет WinMerge после сопоставления Before.reg и After.reg ? Текстовый файл ini-подобной структуры, который надо будет руками допиливать?
Главная моя задача иметь образ содержащий данные каждой отдельной приложухи, который я мог бы смонтировать в WinPE, а затем скопировать\пробросить симлинки в чистую основную систему перед загрузкой. Алсо есть ли способ инициализировать загрузку основной системы из PE? И что в PE с интернетом? Могу ли я прикрутить сеть и интернет в PE?
>Пока всё равно не понял. Связку родительского и дочернего VHD можно сконвертировать в независимый плоский образ, но тогда он будет содержать полное состояние системы. Потом, конечно, можно будет получить файловую дельту, если одновременно смонтировать (только для чтения) родительский VHD и этот вот плоский-произвольный (и да, потом таки можно будет прогнать по корням этих томов WinMerge), но, насколько я понимаю, это всё равно может быть немного не то.
Почему не то? Мне как раз файловая дельта + дельта реестра и нужна. Но при моём подходе ИМХО меньше телодвижений. В PE монтируешь дочерний образ с установленной приложухой, монтируешь сохранённый бэкап этого дочернего образа без приложухи. Копируешь дельту в этот бэкап. Потом грузишься с этого бэкапа куда скопировал дельту. Правда пока у меня слетает триальный период винды и отваливается MSStore. Видимо во время установки приложухи в дельту пишется какой-то системный говняк. Ну это эмпирически можно отсеять руками я думаю.
>Алсо, зачем бэкапить только что созданный дочерний VHD, если его всегда можно пересоздать (а на родительский, естественно, поставить атрибут R/O)?
Можно, но зачем? ИМХО CTRL+C CTRL+V проще.
>Тогда, возможно, имеет смысл упомянуть приложения.
На данный момент экспериментирую с докером. В Sandboxie его не установить. Попробовал руками отсеять всякий системный говняк, оставив только файлы докера, он начинает ругаться что не видит WSL хотя оно появляется в пуске, но запускается с ошибкой. Зато нет проблем с MSStore.
> останавливаешь песочницу, открываешь её каталог в проводнике вне песочницы
Да, это отлично работает и для выделения дельты идеальный инструмент, но вот докер не встаёт в песочнице.
>Но итоговый файл дельты всё равно придётся создавать самостоятельно.
Что же тогда мне выплюнет WinMerge после сопоставления Before.reg и After.reg ? Текстовый файл ini-подобной структуры, который надо будет руками допиливать?
Главная моя задача иметь образ содержащий данные каждой отдельной приложухи, который я мог бы смонтировать в WinPE, а затем скопировать\пробросить симлинки в чистую основную систему перед загрузкой. Алсо есть ли способ инициализировать загрузку основной системы из PE? И что в PE с интернетом? Могу ли я прикрутить сеть и интернет в PE?
>>723892
Почему не то? Мне как раз файловая дельта + дельта реестра и нужна. Но при моём подходе ИМХО меньше телодвижений. В PE монтируешь дочерний образ с установленной приложухой, монтируешь сохранённый бэкап этого дочернего образа без приложухи. Копируешь дельту в этот бэкап. Потом грузишься с этого бэкапа куда скопировал дельту. Правда пока у меня слетает триальный период винды и отваливается MSStore. Видимо во время установки приложухи в дельту пишется какой-то системный говняк. Ну это эмпирически можно отсеять руками я думаю.
Можно, но зачем? ИМХО CTRL+C CTRL+V проще.
На данный момент экспериментирую с докером. В Sandboxie его не установить. Попробовал руками отсеять всякий системный говняк, оставив только файлы докера, он начинает ругаться что не видит WSL хотя оно появляется в пуске, но запускается с ошибкой. Зато нет проблем с MSStore.
Да, это отлично работает и для выделения дельты идеальный инструмент, но вот докер не встаёт в песочнице.
Что же тогда мне выплюнет WinMerge после сопоставления Before.reg и After.reg ? Текстовый файл ini-подобной структуры, который надо будет руками допиливать?
Главная моя задача иметь образ содержащий данные каждой отдельной приложухи, который я мог бы смонтировать в WinPE, а затем скопировать\пробросить симлинки в чистую основную систему перед загрузкой. Алсо есть ли способ инициализировать загрузку основной системы из PE? И что в PE с интернетом? Могу ли я прикрутить сеть и интернет в PE?
>Пока всё равно не понял. Связку родительского и дочернего VHD можно сконвертировать в независимый плоский образ, но тогда он будет содержать полное состояние системы. Потом, конечно, можно будет получить файловую дельту, если одновременно смонтировать (только для чтения) родительский VHD и этот вот плоский-произвольный (и да, потом таки можно будет прогнать по корням этих томов WinMerge), но, насколько я понимаю, это всё равно может быть немного не то.
Почему не то? Мне как раз файловая дельта + дельта реестра и нужна. Но при моём подходе ИМХО меньше телодвижений. В PE монтируешь дочерний образ с установленной приложухой, монтируешь сохранённый бэкап этого дочернего образа без приложухи. Копируешь дельту в этот бэкап. Потом грузишься с этого бэкапа куда скопировал дельту. Правда пока у меня слетает триальный период винды и отваливается MSStore. Видимо во время установки приложухи в дельту пишется какой-то системный говняк. Ну это эмпирически можно отсеять руками я думаю.
>Алсо, зачем бэкапить только что созданный дочерний VHD, если его всегда можно пересоздать (а на родительский, естественно, поставить атрибут R/O)?
Можно, но зачем? ИМХО CTRL+C CTRL+V проще.
>Тогда, возможно, имеет смысл упомянуть приложения.
На данный момент экспериментирую с докером. В Sandboxie его не установить. Попробовал руками отсеять всякий системный говняк, оставив только файлы докера, он начинает ругаться что не видит WSL хотя оно появляется в пуске, но запускается с ошибкой. Зато нет проблем с MSStore.
> останавливаешь песочницу, открываешь её каталог в проводнике вне песочницы
Да, это отлично работает и для выделения дельты идеальный инструмент, но вот докер не встаёт в песочнице.
>Но итоговый файл дельты всё равно придётся создавать самостоятельно.
Что же тогда мне выплюнет WinMerge после сопоставления Before.reg и After.reg ? Текстовый файл ini-подобной структуры, который надо будет руками допиливать?
Главная моя задача иметь образ содержащий данные каждой отдельной приложухи, который я мог бы смонтировать в WinPE, а затем скопировать\пробросить симлинки в чистую основную систему перед загрузкой. Алсо есть ли способ инициализировать загрузку основной системы из PE? И что в PE с интернетом? Могу ли я прикрутить сеть и интернет в PE?
>>724560
По идее можно запилить образ базоваяОС.vhd и наклепать ему детей приложение01.vhd приложение02.vhd приложение03.vhd ... Добавить их в загрузчик и получится почти как хочу. Но тогда придётся отказаться от обновлений ОС и я не смогу в процессе на лету монтировать образы с прилагами. Я кстати упаковал так uTorrent Battle.net ElectronicArts Steam Очень получилось удобно, запускаешся на чистой системе не терпишь лаги всего говняка который пролез в автозапуск. Как только потребовалась конкретная прилага, игрулька из Steam Монтируешь образ стима, поверх монтируешь образ только с игрой, далее сверху монтируешь васянский мод из отдельного образа. Отмонтировав образ можно всегда откатиться на ступень ниже и в системе не будет лишнего говняка. Но со специфическими прилагами типа докера пока проблемы. Подозреваю что он при установке тянет опциональный системный компонент WSL и при простом копировании его файлов в голую ОС что-то ломается.
>Главная моя задача иметь образ содержащий данные каждой отдельной приложухи
По идее можно запилить образ базоваяОС.vhd и наклепать ему детей приложение01.vhd приложение02.vhd приложение03.vhd ... Добавить их в загрузчик и получится почти как хочу. Но тогда придётся отказаться от обновлений ОС и я не смогу в процессе на лету монтировать образы с прилагами. Я кстати упаковал так uTorrent Battle.net ElectronicArts Steam Очень получилось удобно, запускаешся на чистой системе не терпишь лаги всего говняка который пролез в автозапуск. Как только потребовалась конкретная прилага, игрулька из Steam Монтируешь образ стима, поверх монтируешь образ только с игрой, далее сверху монтируешь васянский мод из отдельного образа. Отмонтировав образ можно всегда откатиться на ступень ниже и в системе не будет лишнего говняка. Но со специфическими прилагами типа докера пока проблемы. Подозреваю что он при установке тянет опциональный системный компонент WSL и при простом копировании его файлов в голую ОС что-то ломается.
Сегодня понял, что для DOS-приложух и 3.11 ничего лучше досбокса нет. Ведь у него ж паравиртуальные XMM/EMM! В том самом смысле, что в штатное окружение досбокса торчит только ABI XMS/EMS/UMB, а реализующий их код - является частью эмулятора, а не "настоящими" резидентами, запускаемыми в эмулируемом окружении и юзающими те же костыли, за счёт которых работают на реальном железе. Поэтому получается быстрее, чем в условном QEMU/TCG. Правда, это - только если не пользоваться командой Z:\BOOT.COM: в этом случае разница сразу исчезает.
Плюс, паравиртуальный EMM досбокса - поддерживает GEMMIS, чего до сих пор не умеет ни один опенсорсный "настоящий" EMM, и, вроде, именно поэтому фридос до сих пор не умает в нормальную 3.1(1).
И, раз такое дело, получается, что, когда у меня есть фридос на физике, ставить на него досбокс поверх HX DOS Extender чисто ради запуска 3.11 без MS-DOS/MS-EMM386 - уже не кажется таким иррациональным.
К DOSBox-X это тоже относится. Фич у него сильно больше, и большая их часть может использоваться даже/только в штатном окружении. А для 95+ и прочего, требующего команды BOOT, конечно, получается, лучше PCem.
Плюс, паравиртуальный EMM досбокса - поддерживает GEMMIS, чего до сих пор не умеет ни один опенсорсный "настоящий" EMM, и, вроде, именно поэтому фридос до сих пор не умает в нормальную 3.1(1).
И, раз такое дело, получается, что, когда у меня есть фридос на физике, ставить на него досбокс поверх HX DOS Extender чисто ради запуска 3.11 без MS-DOS/MS-EMM386 - уже не кажется таким иррациональным.
К DOSBox-X это тоже относится. Фич у него сильно больше, и большая их часть может использоваться даже/только в штатном окружении. А для 95+ и прочего, требующего команды BOOT, конечно, получается, лучше PCem.
>>727183
Поясни туристу, что даёт этот оставшийся (1) именно в той части где фридос обсирается
> до сих пор не умает в нормальную 3.1(1).
Поясни туристу, что даёт этот оставшийся (1) именно в той части где фридос обсирается
>>727184
Если ты про отличия 3.11 от 3.1 - это штатные сетевые компоненты:
- стек NDIS3, к которому прикручивается драйвер NDIS2 (которые, в отличие от пакетных или ODI-драйверов, я видел почти для каждой сетевухи, которую встречал, а не только для самых типовых, которые можно по пальцам руки пересчитать если не учитывать ISA и/или не тянущие хотя бы 100 мегабит), Microsoft TCP/IP и штатный WinSock, после чего у тебя появляется возможность взаимодействия с более новыми системами, как минимум, через SMBv1;
- через этот SMBv1 уже может работать штатный почтовик мейнфреймно-локалочного типа (который цепляется не к нешифрованному POP/SMTP, а именно к каталогу на SMB-шаре);
- если твой гипервизор/эмулятор не эмулирует сетевуху (как ванильный досбокс), но эмулирует COM-порты, и где-то рядом работает виртуалка, поддерживающая NetBEUI - можешь пробросить на неё COM-порт виртуалки с 3.11 и коннектиться к ней через RAS;
- либо можешь поставить IE5, который поставит свою звонилку, но уже умеющую TCP/IP (и, возможно, тот же MS WinSock в комплекте).
И не надо никаких "Super TCP" (который умеет выпускать в сеть только приложухи, идущие с ним в комплекте), ни стороннюю реализацию WinSock (которая хоть и работает в чистой 3.1 без NDIS-дровишек, но до сих пор продаётся, и кряка я как-то не нашёл).
Но дело даже не в этом. 3.1 без нерабочих трупп во фридосе тоже в 386 Enhanced Mode не погоняешь, и тогда не будет работать одна из её главных функций - параллельное исполнение DOS-сеансов с помощью аппаратной виртуализации (V86). И даже DesqView/386, у которого это является главной фишкой не погоняешь.
То есть, максимум, на что способен фридос в плане многозадачности - это переключалки задач - когда можешь альт-табнуться между ними ("PC-/MS-DOS Shell" именно это сочетание клавиш и использует, и, скорее всего, оттуда оно и пошло), но тогда неактивная задача реально встанет на паузу и ничего не сможет делать в фоне. А у меня и простые "переключатели задач" приводили к крашам. ЕМНИП - не выдерживал JEMM (хотя есть мнение, что DesqView с ним нормально работает... возможно, конечно, имелось в виду, что у JEMM есть плагин, эмлирующий API QEMM, но, учитывая, что в документации модуля указано, что реализация API неполная, а написан он был конкретно для VSB/TEMU/ADLiPT/SBEMU... сомневаюсь, что этого плагина хватит для DesqView/386).
Поэтому получается, что тот самый FreeDOS, который живее всех живых, умеет в FAT32 и относительно новое железо, и поэтому пригоден для установки непосредственно на пекарни 2015+ года выпуска - не способен держать фидонетовскую IP-ноду. Вот, что об этом пишут в SU.CHAINIK:
А если параллельные V86-сессии реализовать - это не только решит вопрос одновременной работы binkd с тоссером, но можно будет даже добавить к ним BBS, а также файлопомойку и хомяк средствами mTCP, и, может, даже что-то для удалённого управления. И это всё:
- на физике (как минимум, сам FreeDOS);
- с минимумом проприетарных компонентов (только сама 3.1, а DesqView/386 - так вообще опенсорснули вроде... а вот реактось, боюсь, не в счёт, см. предыдущий пункт);
- без космического оверхеда NT или никсов;
- с штатной для Фидонета кодировке в качестве родной, без пвординга с постоянной конвертацией UTF8/CP866 в никсах.
Если ты про отличия 3.11 от 3.1 - это штатные сетевые компоненты:
- стек NDIS3, к которому прикручивается драйвер NDIS2 (которые, в отличие от пакетных или ODI-драйверов, я видел почти для каждой сетевухи, которую встречал, а не только для самых типовых, которые можно по пальцам руки пересчитать если не учитывать ISA и/или не тянущие хотя бы 100 мегабит), Microsoft TCP/IP и штатный WinSock, после чего у тебя появляется возможность взаимодействия с более новыми системами, как минимум, через SMBv1;
- через этот SMBv1 уже может работать штатный почтовик мейнфреймно-локалочного типа (который цепляется не к нешифрованному POP/SMTP, а именно к каталогу на SMB-шаре);
- если твой гипервизор/эмулятор не эмулирует сетевуху (как ванильный досбокс), но эмулирует COM-порты, и где-то рядом работает виртуалка, поддерживающая NetBEUI - можешь пробросить на неё COM-порт виртуалки с 3.11 и коннектиться к ней через RAS;
- либо можешь поставить IE5, который поставит свою звонилку, но уже умеющую TCP/IP (и, возможно, тот же MS WinSock в комплекте).
И не надо никаких "Super TCP" (который умеет выпускать в сеть только приложухи, идущие с ним в комплекте), ни стороннюю реализацию WinSock (которая хоть и работает в чистой 3.1 без NDIS-дровишек, но до сих пор продаётся, и кряка я как-то не нашёл).
Но дело даже не в этом. 3.1 без нерабочих трупп во фридосе тоже в 386 Enhanced Mode не погоняешь, и тогда не будет работать одна из её главных функций - параллельное исполнение DOS-сеансов с помощью аппаратной виртуализации (V86). И даже DesqView/386, у которого это является главной фишкой не погоняешь.
То есть, максимум, на что способен фридос в плане многозадачности - это переключалки задач - когда можешь альт-табнуться между ними ("PC-/MS-DOS Shell" именно это сочетание клавиш и использует, и, скорее всего, оттуда оно и пошло), но тогда неактивная задача реально встанет на паузу и ничего не сможет делать в фоне. А у меня и простые "переключатели задач" приводили к крашам. ЕМНИП - не выдерживал JEMM (хотя есть мнение, что DesqView с ним нормально работает... возможно, конечно, имелось в виду, что у JEMM есть плагин, эмлирующий API QEMM, но, учитывая, что в документации модуля указано, что реализация API неполная, а написан он был конкретно для VSB/TEMU/ADLiPT/SBEMU... сомневаюсь, что этого плагина хватит для DesqView/386).
Поэтому получается, что тот самый FreeDOS, который живее всех живых, умеет в FAT32 и относительно новое железо, и поэтому пригоден для установки непосредственно на пекарни 2015+ года выпуска - не способен держать фидонетовскую IP-ноду. Вот, что об этом пишут в SU.CHAINIK:
> Поскольку пока pаботает БинкДа, не действует тоссеp (ДОС однозадачна)
> Из-за этого для действия тоссеpа необходимо останавливать БинкДу
> Пока тоссеp тоссит и БинкДа не pаботает, входящие сессии не устанавливаются
> Вывод:
> под ДОС нельзя сооpудить ноду, ноpмально пpинимающую входящие сессии
А если параллельные V86-сессии реализовать - это не только решит вопрос одновременной работы binkd с тоссером, но можно будет даже добавить к ним BBS, а также файлопомойку и хомяк средствами mTCP, и, может, даже что-то для удалённого управления. И это всё:
- на физике (как минимум, сам FreeDOS);
- с минимумом проприетарных компонентов (только сама 3.1, а DesqView/386 - так вообще опенсорснули вроде... а вот реактось, боюсь, не в счёт, см. предыдущий пункт);
- без космического оверхеда NT или никсов;
- с штатной для Фидонета кодировке в качестве родной, без пвординга с постоянной конвертацией UTF8/CP866 в никсах.
>>727184
Если ты про отличия 3.11 от 3.1 - это штатные сетевые компоненты:
- стек NDIS3, к которому прикручивается драйвер NDIS2 (которые, в отличие от пакетных или ODI-драйверов, я видел почти для каждой сетевухи, которую встречал, а не только для самых типовых, которые можно по пальцам руки пересчитать если не учитывать ISA и/или не тянущие хотя бы 100 мегабит), Microsoft TCP/IP и штатный WinSock, после чего у тебя появляется возможность взаимодействия с более новыми системами, как минимум, через SMBv1;
- через этот SMBv1 уже может работать штатный почтовик мейнфреймно-локалочного типа (который цепляется не к нешифрованному POP/SMTP, а именно к каталогу на SMB-шаре);
- если твой гипервизор/эмулятор не эмулирует сетевуху (как ванильный досбокс), но эмулирует COM-порты, и где-то рядом работает виртуалка, поддерживающая NetBEUI - можешь пробросить на неё COM-порт виртуалки с 3.11 и коннектиться к ней через RAS;
- либо можешь поставить IE5, который поставит свою звонилку, но уже умеющую TCP/IP (и, возможно, тот же MS WinSock в комплекте).
И не надо никаких "Super TCP" (который умеет выпускать в сеть только приложухи, идущие с ним в комплекте), ни стороннюю реализацию WinSock (которая хоть и работает в чистой 3.1 без NDIS-дровишек, но до сих пор продаётся, и кряка я как-то не нашёл).
Но дело даже не в этом. 3.1 без нерабочих трупп во фридосе тоже в 386 Enhanced Mode не погоняешь, и тогда не будет работать одна из её главных функций - параллельное исполнение DOS-сеансов с помощью аппаратной виртуализации (V86). И даже DesqView/386, у которого это является главной фишкой не погоняешь.
То есть, максимум, на что способен фридос в плане многозадачности - это переключалки задач - когда можешь альт-табнуться между ними ("PC-/MS-DOS Shell" именно это сочетание клавиш и использует, и, скорее всего, оттуда оно и пошло), но тогда неактивная задача реально встанет на паузу и ничего не сможет делать в фоне. А у меня и простые "переключатели задач" приводили к крашам. ЕМНИП - не выдерживал JEMM (хотя есть мнение, что DesqView с ним нормально работает... возможно, конечно, имелось в виду, что у JEMM есть плагин, эмлирующий API QEMM, но, учитывая, что в документации модуля указано, что реализация API неполная, а написан он был конкретно для VSB/TEMU/ADLiPT/SBEMU... сомневаюсь, что этого плагина хватит для DesqView/386).
Поэтому получается, что тот самый FreeDOS, который живее всех живых, умеет в FAT32 и относительно новое железо, и поэтому пригоден для установки непосредственно на пекарни 2015+ года выпуска - не способен держать фидонетовскую IP-ноду. Вот, что об этом пишут в SU.CHAINIK:
А если параллельные V86-сессии реализовать - это не только решит вопрос одновременной работы binkd с тоссером, но можно будет даже добавить к ним BBS, а также файлопомойку и хомяк средствами mTCP, и, может, даже что-то для удалённого управления. И это всё:
- на физике (как минимум, сам FreeDOS);
- с минимумом проприетарных компонентов (только сама 3.1, а DesqView/386 - так вообще опенсорснули вроде... а вот реактось, боюсь, не в счёт, см. предыдущий пункт);
- без космического оверхеда NT или никсов;
- с штатной для Фидонета кодировке в качестве родной, без пвординга с постоянной конвертацией UTF8/CP866 в никсах.
Если ты про отличия 3.11 от 3.1 - это штатные сетевые компоненты:
- стек NDIS3, к которому прикручивается драйвер NDIS2 (которые, в отличие от пакетных или ODI-драйверов, я видел почти для каждой сетевухи, которую встречал, а не только для самых типовых, которые можно по пальцам руки пересчитать если не учитывать ISA и/или не тянущие хотя бы 100 мегабит), Microsoft TCP/IP и штатный WinSock, после чего у тебя появляется возможность взаимодействия с более новыми системами, как минимум, через SMBv1;
- через этот SMBv1 уже может работать штатный почтовик мейнфреймно-локалочного типа (который цепляется не к нешифрованному POP/SMTP, а именно к каталогу на SMB-шаре);
- если твой гипервизор/эмулятор не эмулирует сетевуху (как ванильный досбокс), но эмулирует COM-порты, и где-то рядом работает виртуалка, поддерживающая NetBEUI - можешь пробросить на неё COM-порт виртуалки с 3.11 и коннектиться к ней через RAS;
- либо можешь поставить IE5, который поставит свою звонилку, но уже умеющую TCP/IP (и, возможно, тот же MS WinSock в комплекте).
И не надо никаких "Super TCP" (который умеет выпускать в сеть только приложухи, идущие с ним в комплекте), ни стороннюю реализацию WinSock (которая хоть и работает в чистой 3.1 без NDIS-дровишек, но до сих пор продаётся, и кряка я как-то не нашёл).
Но дело даже не в этом. 3.1 без нерабочих трупп во фридосе тоже в 386 Enhanced Mode не погоняешь, и тогда не будет работать одна из её главных функций - параллельное исполнение DOS-сеансов с помощью аппаратной виртуализации (V86). И даже DesqView/386, у которого это является главной фишкой не погоняешь.
То есть, максимум, на что способен фридос в плане многозадачности - это переключалки задач - когда можешь альт-табнуться между ними ("PC-/MS-DOS Shell" именно это сочетание клавиш и использует, и, скорее всего, оттуда оно и пошло), но тогда неактивная задача реально встанет на паузу и ничего не сможет делать в фоне. А у меня и простые "переключатели задач" приводили к крашам. ЕМНИП - не выдерживал JEMM (хотя есть мнение, что DesqView с ним нормально работает... возможно, конечно, имелось в виду, что у JEMM есть плагин, эмлирующий API QEMM, но, учитывая, что в документации модуля указано, что реализация API неполная, а написан он был конкретно для VSB/TEMU/ADLiPT/SBEMU... сомневаюсь, что этого плагина хватит для DesqView/386).
Поэтому получается, что тот самый FreeDOS, который живее всех живых, умеет в FAT32 и относительно новое железо, и поэтому пригоден для установки непосредственно на пекарни 2015+ года выпуска - не способен держать фидонетовскую IP-ноду. Вот, что об этом пишут в SU.CHAINIK:
> Поскольку пока pаботает БинкДа, не действует тоссеp (ДОС однозадачна)
> Из-за этого для действия тоссеpа необходимо останавливать БинкДу
> Пока тоссеp тоссит и БинкДа не pаботает, входящие сессии не устанавливаются
> Вывод:
> под ДОС нельзя сооpудить ноду, ноpмально пpинимающую входящие сессии
А если параллельные V86-сессии реализовать - это не только решит вопрос одновременной работы binkd с тоссером, но можно будет даже добавить к ним BBS, а также файлопомойку и хомяк средствами mTCP, и, может, даже что-то для удалённого управления. И это всё:
- на физике (как минимум, сам FreeDOS);
- с минимумом проприетарных компонентов (только сама 3.1, а DesqView/386 - так вообще опенсорснули вроде... а вот реактось, боюсь, не в счёт, см. предыдущий пункт);
- без космического оверхеда NT или никсов;
- с штатной для Фидонета кодировке в качестве родной, без пвординга с постоянной конвертацией UTF8/CP866 в никсах.
>>727236
P.S.
Про звонилки пишу, потому что она позволяет не держаться за DOSBox-X (и другие форки, реализующие эмуляцию сетевухи), и, как следствие, спокойно рассматривать легковесные хост-ОС, на которые досбокс портирован, но либо только ванильный, либо ванильный может быть лучше.
Например, RISC OS (которую можно встретить на малинках кроме 5). Там DOSBox-X есть, но из него полностью вырезана эмуляция звука, да и сетевой карты - тоже. Но что там оставлено - эмулятор модема, позволяющий на соседнем хосте поднять slirp/pppd, стартующий из-под nc/inetd, затем из досбокса вызвать этот самый соседний хост - серьёзно, тупо используя айпишник или домен в качестве аргумента к ATDT (там, где в случае настоящего модема должен быть номер телефона).
Или, в теории (если бы там во время портирования досбокса из него не вырезали даже это, поскольку портировали его, ещё когда в этой ОС нормальной сети не было) - KolibriOS.
Так что, если порт досбокса в KolibriOS обновят, и там появится хотя бы эмулятор модема - из KolibriOS уже получится достойная наследница "лучшей DOS, чем DOS и лучшей Windows, чем Windows [3.1]" OS/2.
P.S.
>либо можешь поставить IE5, который поставит свою звонилку, но уже умеющую TCP/IP
Про звонилки пишу, потому что она позволяет не держаться за DOSBox-X (и другие форки, реализующие эмуляцию сетевухи), и, как следствие, спокойно рассматривать легковесные хост-ОС, на которые досбокс портирован, но либо только ванильный, либо ванильный может быть лучше.
Например, RISC OS (которую можно встретить на малинках кроме 5). Там DOSBox-X есть, но из него полностью вырезана эмуляция звука, да и сетевой карты - тоже. Но что там оставлено - эмулятор модема, позволяющий на соседнем хосте поднять slirp/pppd, стартующий из-под nc/inetd, затем из досбокса вызвать этот самый соседний хост - серьёзно, тупо используя айпишник или домен в качестве аргумента к ATDT (там, где в случае настоящего модема должен быть номер телефона).
Или, в теории (если бы там во время портирования досбокса из него не вырезали даже это, поскольку портировали его, ещё когда в этой ОС нормальной сети не было) - KolibriOS.
Так что, если порт досбокса в KolibriOS обновят, и там появится хотя бы эмулятор модема - из KolibriOS уже получится достойная наследница "лучшей DOS, чем DOS и лучшей Windows, чем Windows [3.1]" OS/2.
По медицинским показаниям ограничил время за компом до самого минимума (практически не включаю больше чем на пару минут, подробнее ниже). Но все равно дико скучно, поэтому навайбкодил через Termux вот это https://pastebin.com/AgeABcJh
Начиналось все как ОС с нуля (Gemini), Doom запустить не получилось (Qwen и Deepseek), поэтому решил начать с самого простого, со змейки (Deepseek).
Тестировать пришлось на реальном железе (на x79 тестировались только ранние версии с uefi на базе концептов Qwen, потом все уперлось в тупик и стал тестировать на нетбуке Asus Eee PC в legacy-режиме). Ventoy видит и грузит образ, змейка работает, пусть и со своими приколами. Каждый раз после сборки приходиться копировать на флешку через otg-кабель.
В Termux не запускает через bochs, qemu, dosbox-x.
Какой эмулятор, ВМ или прочие подобные тузлы способны запустить это? Исходники и iso не знаю, куда выложить, чтобы хранились долго, весят они вроде немного, я вообще сильно удивился, что можно собрать такой легковесный iso и он будет грузиться через Ventoy в legacy режиме.
Сейчас достиг относительно стабильной версии, но постоянная возня с otg кабелем является сдерживающим фактором.
Ну и ещё одна рофляночка https://pastebin.com/ihxTg9Pu
Там dotnet-сервер с x86-бинарником exe запускается через mono (ARM), который запускается через proot-distro в Termux. И на Android-хосте в браузере сервер доступен.
Плюс ко всему до кучи нашёл разные программы, которые запускают старые или новые версии Android на Android-хосте. Эмуляторы или ВМ, особо не вникал, решал практические вопросы. Затестил, большая часть из них нестабильные. Но все равно было интересно пощупать.
Я помню старые треды, одно время дико угорал по этой теме, особенно мне нравилось запускать киберпанк через Hyper-V с паравиртуализацией RTX-видеокарты и софт с аппартаным ускорением. Сейчас дикое выгорание оттого, что душат айтишечку со всех сторон. С другой стороны полностью отказаться и потерять интерес к подобным темам не получается.
Эмуляторы консолек на Android, запуск игр на ARM через ExaGear подобные программы и анонс arm-пека от кожанки тоже вносят дополнительное разнообразие в этот зоопарк.
Есть ещё мертвый эмуль SP/AT. Он позволил мне сэмулировать процессор, который не поддерживает SSE2 (Qemu и другие провалились), но при этом намного быстрее, чем 86box и прочие аналоги. Странно, что автор окуклил свой проект, только через снапшоты wayback machine можно скачать.
Ну и, оказывается, не все бинарники, собранные под одну архитектуру, могут без ошибок запускаться на разных версиях Android. В одном устройстве, на Android 7.0, бинарник запустился корректно, а на другом с 12 версией выплевывал ошибку, поэтому пришлось городить костыль в виде proot-distro. С учётом все более жёстких анальных ограничений, тренд на изоляцию, контейнеры и прочие абстракции на мобилках будет усиливаться.
Также мне очень нравится go, его сборки всеядны, даже для старого говна мамонта можно навайбкодить и собрать годноту. Ну это уже немного другая тематика. Просто тренд идет на то, что скоро проще будет с нуля навайбкодить совместимый аналог или порт, особенно если софтина простая, чем эмулировать все легаси. Но с другой стороны, на тех же заводах настолько черепашьи телодвижения, плюс ещё отдел ИБ все тормозит, что проще все оставить как есть и завернуть в очередной слой абстракции. Прогресс туда дойдёт в другом тысячелетии. Ну или когда железо, которое способно запускать это легаси, перестанут выпускать. Во всякие Альт Линуксы, Иртыши и Байкалы я не верю, слишком все сыро и попильно.
Начиналось все как ОС с нуля (Gemini), Doom запустить не получилось (Qwen и Deepseek), поэтому решил начать с самого простого, со змейки (Deepseek).
Тестировать пришлось на реальном железе (на x79 тестировались только ранние версии с uefi на базе концептов Qwen, потом все уперлось в тупик и стал тестировать на нетбуке Asus Eee PC в legacy-режиме). Ventoy видит и грузит образ, змейка работает, пусть и со своими приколами. Каждый раз после сборки приходиться копировать на флешку через otg-кабель.
В Termux не запускает через bochs, qemu, dosbox-x.
Какой эмулятор, ВМ или прочие подобные тузлы способны запустить это? Исходники и iso не знаю, куда выложить, чтобы хранились долго, весят они вроде немного, я вообще сильно удивился, что можно собрать такой легковесный iso и он будет грузиться через Ventoy в legacy режиме.
Сейчас достиг относительно стабильной версии, но постоянная возня с otg кабелем является сдерживающим фактором.
Ну и ещё одна рофляночка https://pastebin.com/ihxTg9Pu
Там dotnet-сервер с x86-бинарником exe запускается через mono (ARM), который запускается через proot-distro в Termux. И на Android-хосте в браузере сервер доступен.
Плюс ко всему до кучи нашёл разные программы, которые запускают старые или новые версии Android на Android-хосте. Эмуляторы или ВМ, особо не вникал, решал практические вопросы. Затестил, большая часть из них нестабильные. Но все равно было интересно пощупать.
Я помню старые треды, одно время дико угорал по этой теме, особенно мне нравилось запускать киберпанк через Hyper-V с паравиртуализацией RTX-видеокарты и софт с аппартаным ускорением. Сейчас дикое выгорание оттого, что душат айтишечку со всех сторон. С другой стороны полностью отказаться и потерять интерес к подобным темам не получается.
Эмуляторы консолек на Android, запуск игр на ARM через ExaGear подобные программы и анонс arm-пека от кожанки тоже вносят дополнительное разнообразие в этот зоопарк.
Есть ещё мертвый эмуль SP/AT. Он позволил мне сэмулировать процессор, который не поддерживает SSE2 (Qemu и другие провалились), но при этом намного быстрее, чем 86box и прочие аналоги. Странно, что автор окуклил свой проект, только через снапшоты wayback machine можно скачать.
Ну и, оказывается, не все бинарники, собранные под одну архитектуру, могут без ошибок запускаться на разных версиях Android. В одном устройстве, на Android 7.0, бинарник запустился корректно, а на другом с 12 версией выплевывал ошибку, поэтому пришлось городить костыль в виде proot-distro. С учётом все более жёстких анальных ограничений, тренд на изоляцию, контейнеры и прочие абстракции на мобилках будет усиливаться.
Также мне очень нравится go, его сборки всеядны, даже для старого говна мамонта можно навайбкодить и собрать годноту. Ну это уже немного другая тематика. Просто тренд идет на то, что скоро проще будет с нуля навайбкодить совместимый аналог или порт, особенно если софтина простая, чем эмулировать все легаси. Но с другой стороны, на тех же заводах настолько черепашьи телодвижения, плюс ещё отдел ИБ все тормозит, что проще все оставить как есть и завернуть в очередной слой абстракции. Прогресс туда дойдёт в другом тысячелетии. Ну или когда железо, которое способно запускать это легаси, перестанут выпускать. Во всякие Альт Линуксы, Иртыши и Байкалы я не верю, слишком все сыро и попильно.
По медицинским показаниям ограничил время за компом до самого минимума (практически не включаю больше чем на пару минут, подробнее ниже). Но все равно дико скучно, поэтому навайбкодил через Termux вот это https://pastebin.com/AgeABcJh
Начиналось все как ОС с нуля (Gemini), Doom запустить не получилось (Qwen и Deepseek), поэтому решил начать с самого простого, со змейки (Deepseek).
Тестировать пришлось на реальном железе (на x79 тестировались только ранние версии с uefi на базе концептов Qwen, потом все уперлось в тупик и стал тестировать на нетбуке Asus Eee PC в legacy-режиме). Ventoy видит и грузит образ, змейка работает, пусть и со своими приколами. Каждый раз после сборки приходиться копировать на флешку через otg-кабель.
В Termux не запускает через bochs, qemu, dosbox-x.
Какой эмулятор, ВМ или прочие подобные тузлы способны запустить это? Исходники и iso не знаю, куда выложить, чтобы хранились долго, весят они вроде немного, я вообще сильно удивился, что можно собрать такой легковесный iso и он будет грузиться через Ventoy в legacy режиме.
Сейчас достиг относительно стабильной версии, но постоянная возня с otg кабелем является сдерживающим фактором.
Ну и ещё одна рофляночка https://pastebin.com/ihxTg9Pu
Там dotnet-сервер с x86-бинарником exe запускается через mono (ARM), который запускается через proot-distro в Termux. И на Android-хосте в браузере сервер доступен.
Плюс ко всему до кучи нашёл разные программы, которые запускают старые или новые версии Android на Android-хосте. Эмуляторы или ВМ, особо не вникал, решал практические вопросы. Затестил, большая часть из них нестабильные. Но все равно было интересно пощупать.
Я помню старые треды, одно время дико угорал по этой теме, особенно мне нравилось запускать киберпанк через Hyper-V с паравиртуализацией RTX-видеокарты и софт с аппартаным ускорением. Сейчас дикое выгорание оттого, что душат айтишечку со всех сторон. С другой стороны полностью отказаться и потерять интерес к подобным темам не получается.
Эмуляторы консолек на Android, запуск игр на ARM через ExaGear подобные программы и анонс arm-пека от кожанки тоже вносят дополнительное разнообразие в этот зоопарк.
Есть ещё мертвый эмуль SP/AT. Он позволил мне сэмулировать процессор, который не поддерживает SSE2 (Qemu и другие провалились), но при этом намного быстрее, чем 86box и прочие аналоги. Странно, что автор окуклил свой проект, только через снапшоты wayback machine можно скачать.
Ну и, оказывается, не все бинарники, собранные под одну архитектуру, могут без ошибок запускаться на разных версиях Android. В одном устройстве, на Android 7.0, бинарник запустился корректно, а на другом с 12 версией выплевывал ошибку, поэтому пришлось городить костыль в виде proot-distro. С учётом все более жёстких анальных ограничений, тренд на изоляцию, контейнеры и прочие абстракции на мобилках будет усиливаться.
Также мне очень нравится go, его сборки всеядны, даже для старого говна мамонта можно навайбкодить и собрать годноту. Ну это уже немного другая тематика. Просто тренд идет на то, что скоро проще будет с нуля навайбкодить совместимый аналог или порт, особенно если софтина простая, чем эмулировать все легаси. Но с другой стороны, на тех же заводах настолько черепашьи телодвижения, плюс ещё отдел ИБ все тормозит, что проще все оставить как есть и завернуть в очередной слой абстракции. Прогресс туда дойдёт в другом тысячелетии. Ну или когда железо, которое способно запускать это легаси, перестанут выпускать. Во всякие Альт Линуксы, Иртыши и Байкалы я не верю, слишком все сыро и попильно.
Начиналось все как ОС с нуля (Gemini), Doom запустить не получилось (Qwen и Deepseek), поэтому решил начать с самого простого, со змейки (Deepseek).
Тестировать пришлось на реальном железе (на x79 тестировались только ранние версии с uefi на базе концептов Qwen, потом все уперлось в тупик и стал тестировать на нетбуке Asus Eee PC в legacy-режиме). Ventoy видит и грузит образ, змейка работает, пусть и со своими приколами. Каждый раз после сборки приходиться копировать на флешку через otg-кабель.
В Termux не запускает через bochs, qemu, dosbox-x.
Какой эмулятор, ВМ или прочие подобные тузлы способны запустить это? Исходники и iso не знаю, куда выложить, чтобы хранились долго, весят они вроде немного, я вообще сильно удивился, что можно собрать такой легковесный iso и он будет грузиться через Ventoy в legacy режиме.
Сейчас достиг относительно стабильной версии, но постоянная возня с otg кабелем является сдерживающим фактором.
Ну и ещё одна рофляночка https://pastebin.com/ihxTg9Pu
Там dotnet-сервер с x86-бинарником exe запускается через mono (ARM), который запускается через proot-distro в Termux. И на Android-хосте в браузере сервер доступен.
Плюс ко всему до кучи нашёл разные программы, которые запускают старые или новые версии Android на Android-хосте. Эмуляторы или ВМ, особо не вникал, решал практические вопросы. Затестил, большая часть из них нестабильные. Но все равно было интересно пощупать.
Я помню старые треды, одно время дико угорал по этой теме, особенно мне нравилось запускать киберпанк через Hyper-V с паравиртуализацией RTX-видеокарты и софт с аппартаным ускорением. Сейчас дикое выгорание оттого, что душат айтишечку со всех сторон. С другой стороны полностью отказаться и потерять интерес к подобным темам не получается.
Эмуляторы консолек на Android, запуск игр на ARM через ExaGear подобные программы и анонс arm-пека от кожанки тоже вносят дополнительное разнообразие в этот зоопарк.
Есть ещё мертвый эмуль SP/AT. Он позволил мне сэмулировать процессор, который не поддерживает SSE2 (Qemu и другие провалились), но при этом намного быстрее, чем 86box и прочие аналоги. Странно, что автор окуклил свой проект, только через снапшоты wayback machine можно скачать.
Ну и, оказывается, не все бинарники, собранные под одну архитектуру, могут без ошибок запускаться на разных версиях Android. В одном устройстве, на Android 7.0, бинарник запустился корректно, а на другом с 12 версией выплевывал ошибку, поэтому пришлось городить костыль в виде proot-distro. С учётом все более жёстких анальных ограничений, тренд на изоляцию, контейнеры и прочие абстракции на мобилках будет усиливаться.
Также мне очень нравится go, его сборки всеядны, даже для старого говна мамонта можно навайбкодить и собрать годноту. Ну это уже немного другая тематика. Просто тренд идет на то, что скоро проще будет с нуля навайбкодить совместимый аналог или порт, особенно если софтина простая, чем эмулировать все легаси. Но с другой стороны, на тех же заводах настолько черепашьи телодвижения, плюс ещё отдел ИБ все тормозит, что проще все оставить как есть и завернуть в очередной слой абстракции. Прогресс туда дойдёт в другом тысячелетии. Ну или когда железо, которое способно запускать это легаси, перестанут выпускать. Во всякие Альт Линуксы, Иртыши и Байкалы я не верю, слишком все сыро и попильно.
>>728281
Проблема решилась. Нужно было написать отдельный загрузчик для образа дискеты и собрать floppy.img. Заработало на эмуляторах Limbo x86 и SPC/AT. Если установить экранную клавиатуру со стрелками, то змейкой можно управлять.
Проблема решилась. Нужно было написать отдельный загрузчик для образа дискеты и собрать floppy.img. Заработало на эмуляторах Limbo x86 и SPC/AT. Если установить экранную клавиатуру со стрелками, то змейкой можно управлять.
>>723894
Как-то читал статью о том, что для guest OS нельзя скрыть факт виртуализации существующими гипервизорами. Я сам в деталях не разбирался, но запомнил, что детект работает то ли через просчет времени, требуемого на чтение участка памяти, то ли на какую-то другую операцию, также связанную с памятью. Позже понял, что техник детекта великое множество, и они свободно лежат на гитхабе (https://github.com/kernelwernel/VMAware).
Вижу, что ты хорошо разобрался с тонкостями виртуализации. Скажи, действительно ли нет панацеи общедоступной?
Как-то читал статью о том, что для guest OS нельзя скрыть факт виртуализации существующими гипервизорами. Я сам в деталях не разбирался, но запомнил, что детект работает то ли через просчет времени, требуемого на чтение участка памяти, то ли на какую-то другую операцию, также связанную с памятью. Позже понял, что техник детекта великое множество, и они свободно лежат на гитхабе (https://github.com/kernelwernel/VMAware).
Вижу, что ты хорошо разобрался с тонкостями виртуализации. Скажи, действительно ли нет панацеи общедоступной?
>>728281
Ищи их нативные версии, работающие вне Termux (которые ставятся именно как APK). На 4пда, например.
QEMU - либо тут https://virtualmachinery.weebly.com/ (нужен прокси), либо на 4пда есть "безымянная" сборка версии где-то 0.13.
DOSBOx-X прямо под андроид нет, там свои форки с другими названиями (aDosBox, AnDosBox, DosBox Turbo, Magic DosBox и т.п.).
Или можешь попробовать запустить ARM-версию DOSBox-X в Android-версии Wine.
>bochs, qemu, dosbox-x.
Ищи их нативные версии, работающие вне Termux (которые ставятся именно как APK). На 4пда, например.
QEMU - либо тут https://virtualmachinery.weebly.com/ (нужен прокси), либо на 4пда есть "безымянная" сборка версии где-то 0.13.
DOSBOx-X прямо под андроид нет, там свои форки с другими названиями (aDosBox, AnDosBox, DosBox Turbo, Magic DosBox и т.п.).
Или можешь попробовать запустить ARM-версию DOSBox-X в Android-версии Wine.
>>728970
И через чисто тайминговые инструкции.
Я и до более тупых методов допёр. Например, у современной физической машины - либо НОД нету, либо, если есть, то в 95% случаев - пишущий.
Вот за это благодарю, ознакомлюсь.
Боюсь, что нет.
KVM или Xen, применяешь к ним максимум этих твиков, готовишь IOMMU с запасной видеокартой, избегаешь зашквара гостевой ОС паравиртуальными драйверами, ставишь объём ОЗУ обязательно кратным гигабайту и т.д. Особо старая винда иногда даёт false positive принципиально.
Где-то на Хабре писали, что лучше всего в этом плане твикается вмварь, но так же имеет особенности, обнуляющие пользу от твиков (вроде намеренно палевных структур SMBIOS).
Возможно, статья не очень новая, и впереди планеты всей сейчас - KVM.
\У коробокса тоже что-то в этом плане есть, но я не уверен, что оно даже на уровне вмвари.
Хм, а тебе зачем? Не прокторов наёбывать часом?
>детект работает то ли через просчет времени, требуемого на чтение участка памяти, то ли на какую-то другую операцию, также связанную с памятью
И через чисто тайминговые инструкции.
Я и до более тупых методов допёр. Например, у современной физической машины - либо НОД нету, либо, если есть, то в 95% случаев - пишущий.
Вот за это благодарю, ознакомлюсь.
>панацеи общедоступной
Боюсь, что нет.
KVM или Xen, применяешь к ним максимум этих твиков, готовишь IOMMU с запасной видеокартой, избегаешь зашквара гостевой ОС паравиртуальными драйверами, ставишь объём ОЗУ обязательно кратным гигабайту и т.д. Особо старая винда иногда даёт false positive принципиально.
Где-то на Хабре писали, что лучше всего в этом плане твикается вмварь, но так же имеет особенности, обнуляющие пользу от твиков (вроде намеренно палевных структур SMBIOS).
Возможно, статья не очень новая, и впереди планеты всей сейчас - KVM.
\У коробокса тоже что-то в этом плане есть, но я не уверен, что оно даже на уровне вмвари.
Хм, а тебе зачем? Не прокторов наёбывать часом?
>>730154
Думаю, для реалистичности конфига к этому ещё стоит добавить:
- тип машины Q35 (потому что физические чипсеты 440 серии не умели столько, сколько они умеют в QEMU);
- чтобы соответствовать чипсету - тип процессора core2duo или Penryn, плюс явно дописать feature flags для аппаратной виртуализации (у c2d/c2q это VT-x, иногда VT-d, а EPT у них нет) и, естественно, обнулить hypervisor bit.
- чтобы соответствовать типу процессора - топологию 1x2x1 или 1x4x1;
- в связи с показаниями тестилки Pafish - переключиться на UEFI.
Это - уже не говоря про кучу параметров, расписанных вот тут: https://libvirt.org/formatdomain.html#hypervisor-features, кастомные (или проброшенные с хоста) атрибуты SMBIOS и, если применимо к хосту, проброс SLIC (либо дампа SLIC с другого хоста)...
По версиям ОС - некоторые детектилки, обнаружив XP, предположат виртуалку без дальнейших проверок, но вообще, софту, которому это может быть критично, бывает важно, чтобы это была минимум 64-разрядная 10, притом активированная (и хорошо, если LTSC сойдёт).
>KVM или Xen, применяешь к ним максимум этих твиков, готовишь IOMMU с запасной видеокартой, избегаешь зашквара гостевой ОС паравиртуальными драйверами, ставишь объём ОЗУ обязательно кратным гигабайту и т.д. Особо старая винда иногда даёт false positive принципиально.
Думаю, для реалистичности конфига к этому ещё стоит добавить:
- тип машины Q35 (потому что физические чипсеты 440 серии не умели столько, сколько они умеют в QEMU);
- чтобы соответствовать чипсету - тип процессора core2duo или Penryn, плюс явно дописать feature flags для аппаратной виртуализации (у c2d/c2q это VT-x, иногда VT-d, а EPT у них нет) и, естественно, обнулить hypervisor bit.
- чтобы соответствовать типу процессора - топологию 1x2x1 или 1x4x1;
- в связи с показаниями тестилки Pafish - переключиться на UEFI.
Это - уже не говоря про кучу параметров, расписанных вот тут: https://libvirt.org/formatdomain.html#hypervisor-features, кастомные (или проброшенные с хоста) атрибуты SMBIOS и, если применимо к хосту, проброс SLIC (либо дампа SLIC с другого хоста)...
По версиям ОС - некоторые детектилки, обнаружив XP, предположат виртуалку без дальнейших проверок, но вообще, софту, которому это может быть критично, бывает важно, чтобы это была минимум 64-разрядная 10, притом активированная (и хорошо, если LTSC сойдёт).