Virtualization engine vmware настройки

Обновлено: 07.07.2024

Как виртуализировать хост-систему Windows – установленную на компьютере операционную систему – и преобразовать её в виртуальную машину VMware? Эта операция может стать решением, когда, к примеру, с наработанной системой необходимо провести какие-то рисковые действия, потенциально угрожающие её жизнеспособности. И результат этих действий прежде неплохо было бы протестировать в виртуальной среде.

Другой пример – банальная экономия времени и сил на создание новой машины, установку и настройку гостевой Windows таким же образом, как и хостовой. Для таких случаев у VMware есть специальный инструмент для виртуализации физического компьютера. Рассмотрим этот инструмент.

1. Очистка Windows перед виртуализацией

Но, прежде чем приступить непосредственно к процессу виртуализации хостовой Windows, её неплохо было бы почистить. Чтобы не нести в виртуальную среду ненужный системный хлам. Средств для очистки Windows от временных и ненужных данных полно, эти средства каждый может выбирать, так сказать, по своему вкусу - хоть штатные инструменты, хоть сторонние программы. В нашем случае прибегнем к очистке системы бесплатной программой Dism++, в её составе имеется реально эффективный чистящий инструмент, способный высвободить значительное место на диске С.

В разделе «Очистка» жмём кнопку «Анализ», далее подтверждаем очистку данных.

Дожидаемся завершения операции. Ну и оцениваем высвобожденное место на диске.

Теперь «заметно похудевшую» систему можно и преобразовывать в виртуальную машину.

2. Скачивание и установка конвертера VMware

Гипервизор VMware Workstation в числе своего функционала предусматривает функцию виртуализации компьютера, это пункт «Виртуализация физической машины» в меню «Файл». Но это не запуск функции в составе программы, это лишь ссылка на веб-ресурс загрузки отдельного инструмента, предназначенного для этих целей – конвертера VMware vCenter Converter Standalone.

Это узкопрофильная программа от VMware для перенесения физических компьютеров и серверов в виртуальные среды продуктов самой же компании-разработчика. Программа бесплатная, но, пройдя по ссылке из VMware Workstation, мы так просто инсталлятор конвертера не скачаем. Нам, во-первых, надо будет авторизоваться на сайте компании с помощью профиля VMware. Во-вторых, после нажатия кнопки загрузки конвертера придётся ждать какое-то время, пока не получим разрешение на право загрузки.

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

Установка конвертера VMware стандартная. На этапе выбора типа установки программы выбираем «Local installation».

3. Виртуализация хост-системы Windows

Запускаем конвертер VMware от имени администратора. Жмём «Convert machine».

Далее на этапе «Source System» в выпадающем перечне выбираем «This local machine».

На этапе «Destination System» указываем тип будущей виртуальной машины, в которую будет преобразована хостовая Windows – тип VMware Workstation . В выпадающем перечне «Select VMware product» указываем версию гипервизора. Последняя версия, доступная для указания в настройках конвертера – 12.х, её указываем для любой версии VMware Workstation позднее. В самом низу с помощью кнопки обзора задаём путь сохранения виртуальной машины. При желании меняем имя машины, по умолчанию оно будет автоматически сформировано из имени компьютера.

На этапе «Options» кликаем ссылку «Edit».

Снимаем галочки со всех ненужных для виртуализации разделов и дисков. В нашем примере мы будем виртуализировать только системные разделы – загрузочный EFI и диск С. Конвертер позволяет нам виртуализировать физические разделы диска с корректировкой их объёма. Мы воспользуемся этой возможностью и в выпадающем списке выберем для загрузочного EFI -раздела меньший, нежели есть по факту, объём в 100 Мб.

Диск С ужмём до 60 Гб.

На этапе «Options» также можем изменить прочее эмулируемое оборудование виртуальной машины, которое будет унаследовано от физического компьютера. Но это не обязательно, поскольку всё это можно будет откорректировать позднее, в настройках машины уже внутри VMware Workstation. Во-первых, настройки этой программы – более привычный для работающих с ней формат в любом случае. Во-вторых, если, как в нашем случае, не поддерживающая официально русский язык VMware Workstation используется с кустарным русификатором, то конфигурацию машины можно будет настроить, соответственно, в русскоязычном интерфейсе. Тогда как русификатора для конвертера VMware не существует.

На этапе «Summary» жмём «Finish».

Далее запустится процесс виртуализации Windows, его прогресс будем наблюдать в графе «Status».

И когда в этой графе появится отметка «Completed», это будет означать полное завершение операции виртуализации.

4. Настройка виртуальной машины

Как упоминалось, конвертер преобразовывает физический компьютер в виртуальную машину с эмуляцией её оборудования в соответствии с реальным аппаратным обеспечением. Т.е. если у вас на компьютере, к примеру, нет привода, но есть десять сетевых карт, то такой вот дисбаланс унаследует и созданная конвертером виртуальная машина. И если вы не корректировали эмуляцию оборудования перед виртуализацией, то машина унаследует всю оперативную память и все ядра процессора физического компьютера. Благо, всё это легко правится в настройках виртуальной машины. Запускаем в VMware Workstation опцию открытия машины.

В проводнике указываем путь к файлу WMX созданной конвертером машины.

И корректируем настройки машины.

Если вы используете VMware Workstation версии выше 12, желательно обновить машину для лучшей совместимости с используемой версией гипервизора.

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

VMware Technology Network
:
Global
:
Russian
:
Russian Discussions
:
как включить аппаратную виртуализацию в vmware?

Hamalik

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Ребят при запуске системы в биосе нету вообще ни чего =(( Как её можно запустить?

Akopylov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Вам телепат нужен, а не форум.

Hamalik

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

А Вы знаете что такое виртуализация??

Не могу запустить NOX ( андроид ) потому что виртуализация не пашет

Akopylov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

А Вы знаете что такое виртуализация??

Не понял вопроса.

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

Я не знаю что такое nox, если это предполагает вложенную виртуализацию и вы собираетесь крутить такую vm в esxi, то в свойствах vm в веб клиенте нужно поставить флаг "expose hardware assisted virtualization to the guest os" если, конечно, ваш cpu умеет такое (vt-x ept). Или, например, попробовать добавить в vmx:

Мне это помогло и без vCenter при развертывании UnetLAB (где nested virtualization имела место).

Если вложенная виртуализация не предполагается, то обычно этот флаг не нужен.

Вообще гугл выдает достаточно результатов во запросу "run android into esxi".

Hamalik

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

в виртуальной системе устоновить виртуальную систему Nox

иша эмуляторов ОС Android на Windows и других уже полностью занята Bluestacks, но некоторые разработчики хотят предоставить пользователям альтернативу в виде программы Nox App Player. Новый эмулятор обладает несколькими функциями, которых нет в популярном Bluestacks.

Эмулятор Nox App Player пока работает на версии Android 4.4.2 KitKat. Приложение эмулирует поведение и , а также внутри Nox App Player предустановлен каталог Google Play, который упрощает установку программ, игр и прочего контента. Помимо этого, Nox App Player поддерживает ввод не только с клавиатуры или мыши, но и с геймпадов и других игровых контроллеров, поэтому новый эмулятор отлично подойдет для геймеров. Также в Nox App Player реализована продвинутая система мультизадачности, например: можно запустить две одинаковые игры в одном эмуляторе и соединить их локальным мультиплеером. И все это — на одном .

Среди прочих особенностей Nox App Player стоит отметить поддержку всех современных процессоров AMD, корректную работу на Windows 10 и удобное изменение настроек эмулятора.

Практика показывает, что любой процесс, в определенной степени, всегда можно оптимизировать. Это вполне можно отнести и к виртуализации. Возможностей оптимизации тут достаточно много, и задача эта многогогранна.

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

Для начала хотелось бы рассказать о двух технологиях, основным образом влияющих на производительность vSphere. Это технология NUMA и технология работы шедулера гипервизора ESXi.

Про NUMA существует достаточно много подробных статей, пересказывать эту информацию не вижу смысла, ограничусь лишь базовым описанием для целостности материала. Итак, NUMA – Non Uniform Memory Access. На русский язык это можно перевести как Неравноценный Доступ к Памяти.

Современные многосокетные сервера, по сути, представляют собой несколько изолированных односокетных компьютеров, объединенных на одной материнской плате. Каждый процессор монопольно владеет своими слотами оперативной памяти, и только он имеет к ней доступ. Аналогично, каждый процессор имеет свои персональные PCI-E шины, к которым подключены различные устройства материнской платы, а так же слоты расширения PCI-E. Процессоры соединены между собой высокоскоростной шиной обмена данными, по которой они получают доступ к «чужим» устройствам, делая запрос на это соответствующему процессору-хозяину. По понятным причинам, доступ процессора к «своей» памяти происходит гораздо с меньшими накладными расходами, чем к «чужой». Пока это все, что необходимо знать о данной технологии.

vSphere прекрасно знает про NUMA и старается размещать виртуальные ядра машин на тех физических процессорах, в чьей памяти сейчас находится оперативная память виртуальной машины. Но тут возникают подводные камни. Производители серверов любят включать в BIOS по умолчанию эмуляцию NUMA. То есть сервер представляется операционной системе как НЕ NUMA устройство, и vSphere не может использовать свою оптимизацию для управления данной технологией. В документации по vSphere рекомендуется отключать (Disable) данную опцию в BIOS, это позволяет vSphere самостоятельно разбираться с вопросом.

Рассмотрим потенциальные проблемы, которые могу возникнуть с NUMA. Предполагаем, что vSphere его видит и корректно с ним работает. Для примера будем рассматривать 2-процессорную систему, как самый простой вариант NUMA. Предположим, что на физическом сервере 64 GB оперативной памяти, по 32 на каждом сокете.

Хотелось бы отметить, что vSphere имеет свою четкую логику при работе с NUMA и Hyperthreading.

Если у ВМ всего 1 виртуальный сокет, то при увеличении vCPU, исполнение машины будет производиться на одном физическом процессоре исключительно на его физических ядрах без использования технологии Hyperthreading. При превышении количества vCPU над количеством физических ядер процессора, ВМ продолжит исполняться в пределах этого физического процессора, но уже с использование Hyperthreading. Если количество vCPU превысило количество ядер процессора с учетом Hyperthreading, то начнут использоваться ядра соседних NUMA нод (других физических процессоров), что приведет к потере производительности (если указать неверное количество виртуальных сокетов). В случае, когда физический процессор сильно нагружен, и свободных физических ядер не осталось, то в любом случае будет использоваться технология Hyperthreading (если иное не указано в конфигурации виртуальной машины). Если посмотреть на цифры, то в среднем ВМ теряет порядка 30-40% производительности, если она работает на чистом Hyperthreading по сравнению с чистыми физическими ядрами. Но сам физический процессор имеет общую производительность примерно на 30% больше с технологией Hyperthreading, чем без нее (используя только физические ядра). Данный показатель очень зависит от типа нагрузки и оптимизации приложений ВМ к многопоточной работе.

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

По понятным причинам, ситуация с нагрузкой физического сервера постоянно меняется. Зачастую, возникает неравномерность нагрузки на физических процессорах сервера. vSphere следит за этим. Шедулер анализирует положение дел, вычисляет накладные расходы на перемещение ВМ или её части на другую NUMA ноду (перемещение памяти, ядер). Сравнивает эти расходы с потенциальной выгодой от перемещения и принимает решение — оставлять все как есть или же перемещать. Иными словами, при любой ситуации vSphere старается оптимизировать работу виртуальных машин. Наша задача состоит в том, чтобы упростить vSphere эту задачу и не ставить её в безвыходное положение.

О каких потерях может идти речь при неправильной конфигурации машин с NUMA нодами? Руководствуясь собственным опытом, могу сказать, что потери могут доходить до 30% общей производительности физического сервера. Много это или мало – решать вам.

Теперь, когда мы немного разобрались с NUMA и Hyperthreading, мне хотелось бы чуть подробнее рассказать о работе шедулера с ядрами виртуальных машин, vCPU.

Я не буду вдаваться в совсем уж глубины, это мало кому интересно, но постараюсь рассказать про принципы и методику работы данного механизма. Итак, основной механизм гипервизора работает следующим образом. В оперативной памяти постоянно работает процесс, обслуживающий работу виртуальных машин. Этот процесс можно представить как конвейер состояния READY и хранилище состояния WAIT. Опустим другие, менее значимые состояния виртуальных машин, они сейчас не принципиальны.

Для легкости восприятия, предлагаю воспринимать все vCPU виртуальных машин как цепочку. Каждое звено цепи – это ядро vCPU (world, в терминах vSphere). Таких world у машины столько, сколько у нее vCPU. Есть еще 2 невидимых, служебных world, сопутствующих каждой виртуальной машине. Один отвечает за обслуживание машины в целом, второй за её ввод-вывод. Реальное потребление вычислительной мощности этими служебными мирами совершенно незначительное, а потребление ими оперативной памяти можно оценить по показателю overhead у каждой виртуальной машины. Стоит отметить, что при создании ВМ размером в весь физический хост, с равным количеством виртуальных и физических ядер, могут возникнуть некоторые потери производительности. Этого момента я коснусь чуть ниже.

Конвейер READY, это «труба», в которую по очереди сброшены все такие цепочки. Таймслот – это время, в течение которого виртуальные машины исполняются физическим процессором (исполняются их vCPU). На это время виртуальная машина практически без потерь, аналогично физическому серверу, использует физические процессоры аппаратного сервера (pCPU). Максимальная величина таймслота искусственно ограничена величиной порядка 1 миллисекунды. После окончания таймслота, vCPU ВМ принудительно помещаются шедулером в очередь конвейера READY. Шедулер имеет возможность менять очередность виртуальных машин в конвейере READY, приоритет каждой машины вычисляется исходя из её текущей фактической нагрузки, её прав на ресурсы (Shares), как давно машина была на физическом процессоре и еще нескольких менее значимых параметров. Логично предположить, что если ВМ на хосте одна, то она всегда будет проходить конвейер очереди READY без задержек т.к. у нее нет конкурентов на ресурсы со стороны других ВМ.

Каким образом шедулер располагает миры виртуальных машин на физических ядрах? Представим себе таблицу, которая имеет по ширине столько столбцов, сколько ядер у нашего физического сервера (с учетом Hyperthreading). По высоте каждая строка будет соответствовать очередному такту процессора(ов) сервера. Давайте представим себе 2-процессорный сервер, по 6 физических ядер на процессор, + Hyperthreading. Всего получим 24 ядра на сервер. Предположим, что у сервера высокая нагрузка, и vSphere вынуждена использовать Hyperthreading, так будет проще считать. Допустим, у нас есть несколько виртуальных машин:

• 4 штуки по 1 ядру
• 4 штуки по 2 ядра
• 2 штуки по 8 ядер
• 1 штука по 16 ядер

Итак, наступает первый таймслот, шедулер выбирает претендентов. Пусть первой будет машина на 16 ядер. Первые 16 физических ядер (pCPU) заняты, осталось 8. Туда поместились, допустим, 4 машины по 2 ядра (причем машина на 16 ядер должна иметь 2 виртуальных сокета, чтобы корректно работать с NUMA). Всё, таймслот заполнен полностью, это идеальный вариант. Мы не теряем производительность, pCPU не простаивают. Остальные виртуальные машины в это время не работают и находятся в очереди ожидания READY. Предположим, что «счастливые» виртуальные машины получили одинаковый по величине таймслот (хотя в реальности у всех ВМ таймслот разный и зависит от множества факторов). Итак, наступает второй таймслот, и шедулеру надо его заполнить.

Остались не обслуженными машины:

• 4 штуки по 1 ядру
• 2 штуки по 8 ядер

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

Аналогичным образом шедулер будет и далее наполнять таймслоты мирами виртуальных машин, стараясь сделать это максимально эффективно, чтобы уменьшить «дыры» в заполнении и повысить КПД виртуальной среды.

Ниже представлен негативный вариант расположения виртуальных машин на хосте. Одна большая машина размером в хост, и одна малая, с 1 vCPU. При равных правах на ресурсы и равных потребностях к производительности эти машины получат одинаковое количество таймслотов, то есть поделят между собой процессорное время. Т.к. обе машины не смогут работать одновременно (не умещаются в один таймслот), то работать они будут по очереди, причем малая машина будет работать в пустом таймслоте, где кроме нее больше никого не будет (таймслот израсходуется практически впустую). Большая машина при всем желании не сможет получить процессорное время, даже если оно этой машине необходимо. Например, при частоте центрального процессора 3 ГГц, обе эти машины смогут максимум получить по 1.5 ГГц.

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

Сейчас хотелось бы вернуться к созданию виртуальной машины величиной в весь хост. Хорошо, пусть такая ВМ заняла собой целиком первый таймслот и отработала его. Теперь вспоминаем про системные миры, сопутствующие этой машине. Их тоже надо исполнять, как надо исполнять сам гипервизор и его собственные системные процессы. То есть надо и им выдавать таймслоты и занимать в них некоторое количество pCPU. А что в это время делать нашей большой ВМ? Правильно, ожидать освобождения ВСЕХ pCPU, чтобы иметь возможность там уместиться. То есть мы гарантированно теряем производительность на служебных задачах гипервизора (таймслотах), а это плохо (вспоминаем пример выше с большой и малой машинами). Для примера, программный iSCSI инициатор под высокой нагрузкой потребляет до 6 ГГц процессорной мощности. Это было бы не так заметно в случае с малыми ВМ т.к. они работали бы параллельно служебным процессам (в этих же таймслотах). А для большой ВМ так не получится т.к. она занимает весь таймслот целиком, все его pCPU, и не может уместиться в таймслот, если хоть один его pCPU уже кем-то занят, пусть и системным процессом.
О каких потерях может идти речь при неправильном конфигурировании виртуальной инфраструктуры и размещении машин по нодам? От нуля до бесконечности (в теории). Все зависит от конкретной ситуации.

Отдельно хотелось бы озвучить главное правило при сайзинге виртуальных машин: давайте виртуальной машине МИНИМАЛЬНО возможные ресурсы, при которых она сможет выполнять свои задачи. Не нужно давать ВМ 2 ядра, если хватает одного. Не нужно давать 4, если хватает 2-х (лишние ядра занимают место в таймслоте). Аналогично с памятью, не стоит выдавать машине лишнего. Возможно, другой машине может не хватить, не говоря уже о возникающих проблемах с живой миграцией (по сути копированием объема памяти ВМ) и NUMA.

Теперь, разобравшись с механизмом размещения vCPU виртуальных машин на pCPU таймслота, давайте вспомним про NUMA и его правила размещения. Для шедулера гипервизора все эти правила имеют значение при заполнении таймслота т.к. pCPU таймслота могут относиться к разным NUMA нодам. Теперь, помимо сложностей учета NUMA при конфигурировании виртуальных машин на хосте, мы получили и ограничения, накладываемые методикой работы шедулера гипервизора с таймслотами. Если мы хотим получить хорошую производительность ВМ, нужно обращать внимание на все подводные камни и руководствоваться следующими правилами:

• Стараться не создавать машины-гиганты (по сравнению с размером хоста)
• Для больших машин надо учитывать ограничения, накладываемые технологией NUMA
• Не стоит злоупотреблять с количеством vCPU по отношению к pCPU хоста
• Несколько мелких или средних машин всегда будут иметь преимущество в гибкости и общей производительности перед огромными машинами

Напоследок хотелось бы сказать о работе шедулера гипервизора с вводом-выводом. При обращении виртуальной машины к своему виртуальному аппаратному обеспечению, гипервизор приостанавливает работу ВМ, снимает её с pCPU и ставит в хранилище WAIT. В таком состоянии машина не работает, она просто ждет. В это время гипервизор трансформирует («подделывает») команды виртуального устройства гостевой машины в реальные команды, соответствующие командам гипервизора, после чего гипервизор возвращает виртуальную машину в конвейер READY. Аналогичная «заморозка» виртуальной машины происходит и при ответе виртуального устройства машине (гипервизору необходимо снова трансформировать ответ, но уже в обратную сторону ). Чем больше команд ввода-вывода производит виртуальная машина, тем чаще она находится в «заморозке» WAIT, и тем меньше её производительность. Чем более «старые» виртуальные устройства ввода-вывода использует виртуальная машина, тем сложнее гипервизору трансформировать команды, и тем дольше ВМ находится в состоянии WAIT.

VMWare прямо и официально не рекомендует виртуализовывать приложения с гиперактивным вводом-выводом. Уменьшить негативное влияние от состояния WAIT можно с помощью использования паравиртуальных устройств для виртуальной машины. Это 10-гигабитная сетевая карта VMXNET3 и паравиртуальный SCSI контроллер жесткого диска PVSCSI. Так же уменьшению влияния WAIT и общему повышению производительности способствует применение в физических серверах аппаратных устройств, предназначенных для ускорения работы виртуальных машин. Это различные сетевые и HBA адаптеры с поддержкой аппаратного iSCSI offload, прямого доступа к памяти, сетевые карты с поддержкой виртуализации и т.д.

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

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

Включение вложенной виртуализации в VMware ESXi

Вложенная виртуализация представляет собой функционал, который позволяет запустить виртуальные машины на гипервизоре, который сам установлен внутри виртуальной машины. Задача по включению заключается в добавлении дополнительной конфигурации в конфиг /etc/vmware/config гипервизора. Вложенная виртуализация не должна использоваться в продуктивной среде, так вы автоматически лишаетесь поддержки от вендора.

Первым шагом будет включение SSH сервиса на хосте виртуализации. В случае если ESXi хост подключен к vCenter заходим в конфигурацию сервисов и выполняем запуск службы:

Включение SSH на гипервизоре ESXi на vCenter

Если же в распоряжении отдельно стоящий гипервизор, выполняем действия непосредственно на нем:

Включение SSH в самом гипервизоре ESXi

Далее, используем WinSCP для подключения и редактирования конфига на гипервизоре ESXi. Для этого вводим учетные данные:

Подключение к ESXi c помощью WinSCP

И заказываем действие редактирвоания конфига:

Редактирование config файла гипервизора ESXi

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