Guest isolation vmware что это

Обновлено: 10.01.2025

High Availability – технология кластеризации, созданная для повышения доступности системы, и позволяющая, в случае выхода из строя одного из узлов ESXi, перезапустить его виртуальные машины на других узлах ESXi автоматически, без участия администратора.

Общие сведения High Availability

В прошлый раз шла речь о технологиях, используемых в VMware для обеспечения отказоустойчивой системы, в этой же статье подробнее остановимся на VMware HA – VMware High Availability (механизме высокой доступности).

Для того чтобы создать HA кластер, нам необходимо, чтобы все виртуальные машины этого кластера хранились на общем хранилище данных*. При этом если у нас выходит из строя один из узлов ESXi, все виртуальные машины с этого узла будут запущены на свободных слотах (мощностях) других ESXi узлов кластера.

*Общее хранилище данных может представлять собой не только «железную» СХД, но и быть программным. У VMware для этой цели есть продукт vSAN (virtual storage area network). У RedHat есть GlusterFS и т.д.

Список терминов

High Availability (HA) – технология высокой доступности узлов ESXi;
Isolation response (IR) – параметр, определяющий действие ESXi-хоста при прекращении им получения сигналов доступности кластера. При создании кластера на каждый ESXi-хост устанавливается HA Agent, который будет обмениваться сигналами доступности (Heartbeat);
Reservation – параметр, рассчитывающийся на основе максимальных отдельных характеристик всех ВМ в кластере и в дальнейшем использующийся для расчета Failover Capacity;
Failover Capacity (FCap) – параметр, определяющий реальную отказоустойчивость. Измеряется в целых числах и обозначает, какое максимальное количество серверов в кластере может выйти из строя, после чего сам кластер всё еще будет продолжать функционировать;
Number of host failures allowed (NHF) – параметр задается администратором. Определяет целевой уровень отказоустойчивости. Такое количество узлов ESXi может одновременно выйти из строя;
Состояние Admission Control (состояние ADC) – автоматически рассчитывается как отношение Failover Capacity к Number of host failures allowed;
Параметр Admission Control (параметр ADC) – назначается администратором. Определяет поведение виртуальных машин при недостаточности слотов для их запуска;
Restart Priority (RP) – приоритет запуска машин после падения одного из узлов ESXi, входящих в кластер.

Последовательность создания VMware HA кластера

Определяем количество и размер слотов на узлах ESXi (Reservation); Устанавливаем значение Number of host failures allowed (NHF); Сравниваем NHF и FCap. Если NHF больше FCap, нам необходимо: Либо установить параметр ADC в Allow virtual machine to be started even if they violate availability constraints; Устанавливаем параметр Admission Control в одно из состояний; Определяем поведение хоста при прекращении получения сигналов доступности от остальных узлов (Isolation Response);

Isolation Response

Действия при прекращении получения сигналов доступности в кластере HA определяются значением Isolation Response, определяющим действие узла ESXi при прекращении им получения сигналов доступности кластера (Heartbeat). Прекращение получения сигналов доступности происходит из-за «изоляции» ESXi, например, в случае отказа сетевой карты.

Существует несколько предполагаемых сценариев развития событий:

Сбой отправки/получения сигналов доступности, но сама сеть продолжает функционировать; Перестала работать сеть между узлом ESXi и остальными узлами кластера, но ESXi продолжает функционировать;

В первом случае, стоит выбрать значение параметра Isolation Response - Leave powered on, тогда все машины, продолжат свою работу, невзирая на то, что прекратят получать сигналы доступности.

Во втором случае следует выбрать Isolation Response – Power off либо Shutdown (установлен по умолчанию), если ESXi-хост перестал получать сигналы доступности, HA перенесет с общего хранилища ВМ, хранившиеся на этом хосте ESXi, на свободные ESXi-хосты. ESXi-хост должен автоматически выключаться, чтобы не возникало конфликтов двух одинаковых хостов.

По умолчанию Isolation Response установлен в режиме Power off. Мы не знаем как будут развиваться события в момент гипотетического отказа, поэтому мы рекомендуем оставлять значение IR в состоянии Power off, чтобы избежать риска появления в сети конфликтующих машин с одинаковыми сетевыми настройками.

Резервация ресурсов (Reservation)

При расчете параметра Failover Capacity кластер HA сначала создает слоты, определяемые параметром Reservation. Этот параметр рассчитывается по размеру максимальной из виртуальных машин, работающих на узлах кластера.

Параметр Failover Capacity

После расчета слотов определяется сам параметр Failover Capacity. Он измеряется в целых числах и обозначает, какое максимальное количество узлов в кластере одновременно может выйти из строя. При этом все машины должны продолжать функционировать.

Иллюстрируем параметр Failover Capacity. Возьмем два случая (по вертикали: 1-й случай - отказ одного узла ESXi, 2-й случай - отказ 2-х узлов ESXi).

Первый случай: 3 узла ESXi, по 4 слота на каждом, 6 виртуальных машин.
В этом случае при выходе из строя одного узла (например, №3), ВМ 4,5,6 будут запущены на других узлах (в нашем случае №2, показаны стрелками), однако, при выходе из строя еще одного узла, свободных слотов под запуск ВМ не останется.

Второй случай: 3 узла ESXi, по 4 слота на каждом, 4 виртуальные машины.
В этом случае, свободных слотов хватит, даже если упадет сразу 2 узла ESXi(в нашем случае, ВМ перенесутся на хост №1).

Технически параметр Failover Capacity рассчитывается следующим образом: из количества всех узлов в кластере мы вычитаем отношение количества виртуальных машин в кластере к количеству слотов на одном узле ESXi. Если получается не целое число, округляем вниз.

Для первого случая: 3-6/4=1.5 Округляем до 1;
Для второго случая: 3-4/4=2 Так и остается 2;

Admission Control

Admission Control мы условно разделили на состояние Admission Control (состояние ADC) и параметр Admission Control (параметр ADC).

Состояние ADC определяется соотношением реального уровня отказоустойчивости (FCap) и установленного администратором (NHF). Если FCap больше NHF, то кластер настроен корректно и проблем ожидать не следует. Если наоборот, то мы должны устанавливать параметр ADC.

Параметр ADC определяется администратором и может иметь два состояния:

Do not power on virtual machines if they violate availability constraints – не включать виртуальные машины, если не достаточно слотов для обеспечения целевого уровня отказоустойчивости; Allow virtual machine to be started even if they violate availability constraints – разрешить запуск виртуальных машин, несмотря на возможную нехватку ресурсов для их запуска;

При выборе параметра ADC следует заранее понять, как будет устроен кластер и для каких целей он необходим:

Если наша основная задача – это надежность самого кластера, несмотря на то, какие ВМ будут включены, нам следует установить Admission Control в состояние Do not power on….; Если же нам важно работа всех ВМ в кластере, нам придется установить Admission Control в состояние Allow VM to be started….;

Во втором случае, поведение кластера может стать непредсказуемым (в худшем случае может дойти до такого, что ВМ опустят значение ADC до нулевого значения, тем самым сделав бесполезным технологию HA)

esxi cluster

Backup для виртуальных машин

Arcserve для VMware

Работая с нами Вы, получите:

Развернутую консультацию по составу и лицензированию продуктов;

Наши цены ниже по целому ряду причин:
V-GRADE - является Официальным Партнером VMware уровня Advanced;
Работаем без посредников , напрямую с VMware, Veeam, Arcserve для VMware.

Наши эксперты:

У нас есть конфигуратор VMware, лучшие цены, актуальные статьи. лучшие эксперты.

Одной из функций высокодоступного кластера VMware является механизм проверки изоляции, который запускается, если сервер в течение некоторого времени (по умолчанию 12 секунд) не получает heartbeat сигналов от других членов кластера.

Изоляция возникает из-за ошибок конфигурирования оборудования или сбоя в работе сегмента сети, и может повлечь недоступность виртуальных машин.

Для определения изоляции узел посылает echo-запрос на специальные IP-адреса (isolation address).

Если на запросы никто не ответил, узел считает себя изолированным от остальной сети и завершает работу всех ВМ, с тем, чтобы остальные работающие узлы кластера могли их запустить.

По умолчанию в качестве адреса для проверки изоляции используется маршрутизатор по умолчанию.

Использование маршрутизатора по умолчанию в качестве адреса для проверки изоляции является хорошей идеей, поскольку в крупных инфраструктурах управляющие интерфейсы серверов ESXi, как правило, вынесены в отдельную сеть. В этом случае, "ближайшим" адресом, который можно использовать для проверки, является адрес маршрутизатора.

С другой стороны, использование маршрутизатора по умолчанию в качестве адреса для проверки изоляции не является хорошей идеей, поскольку в небольших компаниях в качестве маршрутизатора может использоваться, например, ISA Server, развернутый в виртуальной машине. Это может привести к ситуации, когда сервер ESXi будет успешно пересылать пакеты любой из запущенных на нем ВМ (в пределах одного виртуального коммутатора), хотя в действительности окажется изолированным от физической сети.

Наконец, в ряде случаев, возможно и ложное срабатывание, когда все узлы кластера, подключенные к одному коммутатору, из-за кратковременной недоступности сети посчитают себя изолированными и остановят свои виртуальные машины.

Для предотвращения этой ситуации следует, во-первых, дублировать сетевое оборудование, во вторых, добавить проверку дополнительных адресов, прописав в Advanced Options настройках HA кластера параметры das.isolationaddress и/или das.isolationaddressn>.

Первый параметр позволяет задать один дополнительный адрес для проверки изоляции, второй, точнее остальные - до десяти дополнительных адресов (в различных документах описывается, что параметры должны иметь значение das.isolationaddress1, das.isolationaddress2, . das.isolationaddress10, хотя на практике мне удавалось задать и das.isolationaddress0; номер в названии параметра влияет на очередность при проверке).

Теоретически, у вас может быть до 11 дополнительных адресов для проверки изоляции. Только это вовсе не означает, что вам нужно задавать их все, поскольку проверка узлом каждого дополнительного адреса занимает 1 секунду, следовательно, реакция узла на изоляцию последует позже, что в свою очередь увеличит время, необходимое на перезапуск ВМ на других узлах.

Также для предотвращения ложного срабатывания можно задать параметр das.failuredetectiontime (по умолчанию используется значение 15000 миллисекунд), влияющий на время, в течение которого узлы будут пытаться отправлять друг-другу heartbeat'ы, до того как начать проверку на изоляцию.

Важно отметить, что использование параметров das.isolationaddress не отменяет маршрутизатор по умолчанию в качестве адреса для проверки изоляции. Чтобы не использовать маршрутизатор для проверки вам потребуется добавить параметр "das.usedefaultisolationaddress = false".

Учтите, что для изменения настроек уже существующего кластера, то вам потребуется отключить, а затем снова включить HA кластер, что приведет к повторной установке HA агентов на всех узлах.

Для проверки изоляции не обязательно использовать адреса в той же подсети, в которой расположены VMKernel интерфейсы, однако это будет крайне разумным решением. И вот почему.

Если для хранения виртуальных машин вы используете iSCSI или NFS хранилище, то в качестве адреса для проверки изоляции рекомендуется указывать один из интерфейсов хранилища. Это позволит избежать ситуации, когда из-за сетевой изоляции у ВМ пропадает доступ к виртуальным дискам, и сервер виртуализации держит их включенными, вместо того, чтобы остановить.

Проблема заключается в том, что echo-запрос отправляется с любого "ближайшего" VMKernel интерфейса (например, с интерфейса из той же подсети, где находится адрес для проверки изоляции), а не с того, который настроен для передачи управляющего трафика (Management traffic).

Наглядно эту ситуацию демонстрирует следующая картинка.

В данном примере IP адрес 10.0.0.4 соответствует VMKernel интерфейсу, на котором включен management traffic, а 10.0.1.4 - интерфейсу VMKernel, который используется только для передачи iSCSI трафика (адрес 10.0.0.254 соответствует маршрутизатору по умолчанию, 10.0.1.1 - хранилищу iSCSI). В момент проверки узла на изоляцию наблюдается следующее.

Один последний момент, который я хотел рассмотреть - обеспечение избыточности для управляющих интерфейсов (Management Network) серверов ESXi. Управляющие интерфейсы используются узлами HA кластера для отправки heartbeat пакетов, согласования изменений в конфигурации и проверки изоляции.

По умолчанию, если вы создаете HA кластер, используя всего один управляющий интерфейс и один сетевой адаптер, то увидите следующее предупреждение.

Подключение дополнительных сетевых адаптеров к управляющему интерфейсу.
Создание дополнительных VMKernel интерфейсов и назначение на них функции передачи управляющего трафика (Management traffic).

Данный вариант обеспечит защиту от сбоев оборудования: сгоревшего порта, сетевой карты, коммутатора (если они дублированы) или отключенного кабеля, однако не поможет в случае ошибок в конфигурации VLAN'ов, неправильным назначением сетевых настроек, ARP или IP spoofing'е и т.п.

Создание дополнительных управляющих VMKernel интерфейсов в отдельных VLAN'ах, а еще лучше - подключенных через отдельные сетевые адаптеры, повысит доступность, но в то же время приведет к усложнению конфигурации кластера и потребует дополнительных настроек на сетевом оборудовании.

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

VMware Technology Network
:
Global
:
Russian
:
Russian Discussions
:
изолировать группу ВМ от внешней сети

alex777

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Несколько ВМ на одном хосте ESX. На ESX несколько сетвых карточек. Одной картой хост подключен к общему коммутатору (ядро сети). Нужно одной ВМ дать доступ в общую сеть, а все остальные изолировать от общей сети, но при этом что бы все ВМ на этом хосте были доступны друг для друга по сети.

То есть из внешней сети (за пределом ESX) должна быть доступна только одна ВМ. Нопри этом все ВМ могут "общаться друг с другом".

Возможно ли такое сделать ?

adm738

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

создать коммутатор 2

в вм1 к котрая смотрит в сеть добавить еще 1 net adapter

соединить его с коммутатором 2

все остальные вм вм2. соединить с коммутарором 2

evgenyk

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

То что вам нужно называется Private VLANs.

Evgeny Kovalskiy CCNP, VCP, EMCSA IT Infrastructure Architect adm738

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

страница 119 книги "администритрование VMware vSphere " Михаила Михеева

alex777

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Это нужно реализовать без добавления второй сетевой карты (и соответственно без включения маршрутизации) на "смотрящую" во вне ВМ.

И наверно без VLAN - клиенты для которых должна быть доступна ВМ не умеют работать с VLAN. Хотя может я чего то и не понял.

AntonVZhbankov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Создается второй vSwitch без физических аплинков, на нем портгруппа InternalLAN.

Все машины подключаются в InternalLAN, а одна из них вторым сетевым интерфейсом в ExternalLAN, имеющую доступ наружу - т.е. расположенную на vSwitch0.

MCSA, MCTS Hyper-V, VCP 3/4, VMware vExpert

alex777

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Но ведь для этого нужно будет на машине имеющей доступ во внешнюю сеть создавать две сетевых карты. Нужно будет настраивать маршрутизацию и делать сегментацию сети.

VTsukanov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Но ведь для этого нужно будет .

Вам шашечки или ехать?

Да будет нужно создать второй свич и отдельную сеть. Про роутинг не понимаю, вы ж собирались их ограничить с доступом в основную сеть? Если так то роутинг вам не нужен. Просто все остальные варианты (маски гайтвеи отдельное адресное пространство на той же физике) не гарантирует реального отсечения сети.

AntonVZhbankov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

>Но ведь для этого нужно будет на машине имеющей доступ во внешнюю сеть создавать две сетевых карты.

Да, именно об этом я и написал.

>Нужно будет настраивать маршрутизацию и делать сегментацию сети.

Это Вам виднее, нужно ли будет это делать.

MCSA, MCTS Hyper-V, VCP 3/4, VMware vExpert

alex777

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Изначально задача ставилась реализовать это средствами ESX без сегментации сети и маршрутизации между ВМ.

Тот вариант, что Вы предлогаете (если я правильно Вас понял) требует включения маршрутизации на ВМ и сегментации сети (изолированные ВМ в отдельную ip сеть). Увы, это не подходит.

Я надеялся, что у ESX например есть механизм который просто может блокировать доступ заданных ВМ к указанным vmnic (как один из вариантов).

Но все равно большое спасибо за помощь !

AntonVZhbankov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Тогда вообще непонятно что вы хотите в конечном итоге.

>Я надеялся, что у ESX например есть механизм который просто может блокировать доступ заданных ВМ к указанным vmnic

Разумеется есть. Называется NIC Teaming Policy, выставляется на уровне портгруппы. Но для машины с доступом к Интернет в любом случае придется делать тогда две виртуальные сетевые карты, правда роутинг тогда не требуется.

MCSA, MCTS Hyper-V, VCP 3/4, VMware vExpert

alex777

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

ОК. Попытаюсь описать конечную задачу.

Есть сетка, допустим 192.168.1.0/24. В этой сети несколько серверов и много рабочих станций. Так же в этой сети есть ESX сервер.

На этом ESX в виде группы ВМ реализован некоторый сервис для пользователей. Пользователям для работы достаточно иметь доступ по сети только к одной ВМ . Сейчас все ВМ с ESX имеют доступ в сеть и из сети они так же все доступны. Нужно сделать так что бы доступ из сети/в сеть был только у одной ВМ, а остальные ВМ имели доступ только к этой ВМ. Вот как то так..

AntonVZhbankov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Как я уже и говорил.

1) vSwitch0 + VM Network 0 - есть физический аплинк

2) vSwitch1 + VM Network 1 - без аплинков

Машина с сервисом подключается двумя сетевыми картами в VM Network 0 и VM Network 1. Все остальные машины в VM Network 1.

MCSA, MCTS Hyper-V, VCP 3/4, VMware vExpert

Umlyaut

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

ОК. Попытаюсь описать конечную задачу.

Есть сетка, допустим 192.168.1.0/24. В этой сети несколько серверов и много рабочих станций. Так же в этой сети есть ESX сервер.
На этом ESX в виде группы ВМ реализован некоторый сервис для пользователей.

> Пользователям для работы достаточно иметь доступ по сети только к одной ВМ .

>Сейчас все ВМ с ESX имеют доступ в сеть и из сети они так же все доступны .

Нужно сделать так что бы доступ из сети/в сеть был только у одной ВМ, а остальные ВМ имели доступ только к этой ВМ . Вот как то так..

Я бы хотел напомнить Вам, что т.н. "доступ" не бывает абстрактным (сферическим в вакууме) и всеобъемлющим.

В Вашем примере (коль скоро Вы не хотите разрулить ситуацию на level 2 с помощью VLANов) можно попробовать поиграть на level 3 (IP):

- сделать сетевым интерфейсам ВСЕХ ВМок свою адресацию - скажем, 192.168.2.0/24 - понятно, что у "видимой снаружи ВМки" адрес из сети 192.168.2.0 будет комплементарным к основному из сети 192.168.1.0 на её виртуальном NICе.

- на локальном файерволе этой "видимой снаружи" ВМки разрешить входящие соединения из обеих (.1. и .2) сетей

- на локальных файерволах остальных ВМок разрешить входящие только из сети .2 (если требуются входящие соединения от этой "публичной" ВМки - если не нужны и соединения идут тоько от них на "публичную" ВМку, то вообще запретить все входящие на "внутренних ВМках"

- уместным будет не просто разрешение входящих соединений, но ещё и указание конкретных портов только реально необходимых сервисов

Дисклаймер: для подобного решения важно наличие на клиентах "снаружи" ограничения возможности смены IP-адреса (чтобы никто не мог поставить адрес из сети .2 - впрочем, обычно такие ограничения на клиентских машинах есть норма жизни). Хотя предыдущие комментаторы-коллеги правы - лучше давить на level 2 (причём тут есть выбор между port based VLANs и tagged VLANs).

Разработчики вирусного ПО и просто разработчики, не желающие, чтобы их программу пытались реверсить, на этапе запуска или установки проводят проверки на виртуальную машину, и в случае её обнаружения отказываются работать, а то и вовсе самоликвидируются. Под катом описан способ, как можно попробовать решить эту проблему.

Я использовал VMWare Fusion для Mac, однако с тем же успехом способ работает и в Workstation для Win.

1) Для работы необходима заново установленная система, как внести изменения в уже существующую — не нашёл.

Готовите виртуальный диск, указываете систему, как это обычно делаете, и в настройках к устанавливаемой машине, у меня этот пункт назван Isolation, выключаете любой обмен данными с хостовой ОС.

2) Далее надо найти конфигурационный VMX файл, создаваемый на этапе создания машины в VMWare, и в конец добавить строки:

isolation.tools.getPtrLocation.disable = «TRUE»
isolation.tools.setPtrLocation.disable = «TRUE»
isolation.tools.setVersion.disable = «TRUE»
isolation.tools.getVersion.disable = «TRUE»
monitor_control.disable_directexec = «TRUE»
monitor_control.disable_chksimd = «TRUE»
monitor_control.disable_ntreloc = «TRUE»
monitor_control.disable_selfmod = «TRUE»
monitor_control.disable_reloc = «TRUE»
monitor_control.disable_btinout = «TRUE»
monitor_control.disable_btmemspace = «TRUE»
monitor_control.disable_btpriv = «TRUE»
monitor_control.disable_btseg = «TRUE»

Эти опции предотвращают детектирование программами виртуального окружения через такие сложные проверки, как отслеживание адресного пространства памяти, счётчиков.

Важно! Если на этапе настройки установки будет опция вроде «Express install», «Быстрая установка» — выключайте их. Также не стоит устанавливать VMWare Tools в установленную систему, т.к. некоторое ПО в проверку включает и наличие этого пакета.

3) Сохраняем файл, указываем для загрузки ISO с установщиком системы, устанавливаем ОС как обычно.

4) Несмотря на то, что подавляющее большинство программ, не любящих виртуальной среды, не заходят дальше проверок, которые мы отсекли на 2 шаге, некоторые особо упорные всё же идут дальше и пытаются искать, к примеру, всё, что похоже на название контроллеров виртуальных дисков.

Чтобы победить и их в Windows, идём в редактор реестра в ветку HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum. Как видите, там есть вполне явная отсылка к тому, что диск — виртуальный.

Нам нужно изменить его, убрав из параметра VMware, Virtual, Ven, итп, и сохранить её так.

Также имеет смысл заменить в реестре поиском по VMware/Virtual на какой-нибудь Intel или IBM всё, что меняется, а не только дисковые переменные.

После пробуйте запускать ваш упрямый объект экспериментов — в процентах 70 случаев описанные шаги помогут пройти проверки на виртуальное окружение.

Важно! Значение в HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum перезаписывается после каждой перезагрузки, так что его нужно менять после каждого нового запуска системы.

Естественно, это не исчерпывающее руководство, некоторое ПО также может пытаться определять виртуальную систему следующими методами:

1) Проверками диапазона MAC адресов (просто подменяется в настройках виртуального сетевого адаптера до запускa виртуальной машины)
2) Через WinAPI опросом конфигурации ОС и прочей системной информации (FirmwareTable)
3) Низкоуровневыми трюками.

Проверить, насколько вы обезопасили себя от обнаружения, а также ознакомиться с другими популярными у разработчиков средствами обнаружения песочниц и виртуалок можно средством Pafish.

Несмотря на то, что остались места, где можно себя выдать, предложенный метод заставляет обхитрить большинство ПО, которое не желает работать в виртуальной среде, в данном случае, в VMWare.

Как видно, улучшить скрытность можно также выделив виртульной машине больше системных ресурсов. Что касается памяти, выбирать стоит значения, кратные 1024.

Спасибо всем, кто осилил статью и помог в дополнении её толковыми комментариями!

1) Для работы необходима заново установленная система, как внести изменения в уже существующую — не нашёл.

isolation.tools.getPtrLocation.disable = «TRUE»
isolation.tools.setPtrLocation.disable = «TRUE»
isolation.tools.setVersion.disable = «TRUE»
isolation.tools.getVersion.disable = «TRUE»
monitor_control.disable_directexec = «TRUE»
monitor_control.disable_chksimd = «TRUE»
monitor_control.disable_ntreloc = «TRUE»
monitor_control.disable_selfmod = «TRUE»
monitor_control.disable_reloc = «TRUE»
monitor_control.disable_btinout = «TRUE»
monitor_control.disable_btmemspace = «TRUE»
monitor_control.disable_btpriv = «TRUE»
monitor_control.disable_btseg = «TRUE»

3) Сохраняем файл, указываем для загрузки ISO с установщиком системы, устанавливаем ОС как обычно.

Нам нужно изменить его, убрав из параметра VMware, Virtual, Ven, итп, и сохранить её так.

Спасибо всем, кто осилил статью и помог в дополнении её толковыми комментариями!

Читайте также: