5 какой фирмы bios используется в vmware

Обновлено: 04.07.2024

Среди программ-гипервизоров для Windows, реализующих возможность работы на физическом компьютере с виртуальными машинами (далее по тексту - ВМ) и их операционными системами (далее по тексту – ОС) , средства компании-разработчика VMware являются одними из лучших. Основной продукт VMware Workstation во многом превосходит и гипервизор от Microsoft Hyper-V , и стороннюю программу VirtualBox .

Как создать ВМ в среде программы VMware Workstation и установить на неё Windows?

1. Аппаратные требования к хосту

Какой бы гипервизор ни использовался для работы с ВМ, реальный компьютер с хост-системой должен соответствовать минимальным требованиям:

• Как минимум двухъядерный процессор;
• Как минимум 4 Гб RAM;
• Поддержка процессором аппаратной виртуализации – технологий Intel VT (Intel Virtualization Technology) или AMD-V (AMD Virtualization, она же Secure Virtual Machine (SVM)).

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

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

2. Гипервизоры от VMware

Workstation Pro в актуальной версии программы 15 состоит из нескольких компонентов – редактора сетевых параметров Virtual Network Editor, самой программы Workstation Pro и урезанной её версии Workstation Player.

Workstation Player – это так называемый проигрыватель ВМ. С его помощью можно создавать, настраивать ВМ, работать с ними. Это более легковесная и шустрая программа, чем Workstation Pro. И стоит лицензия на проигрыватель дешевле – порядка 12 тыс. руб. Но проигрыватель лишён отдельных возможностей полноценного гипервизора, в частности, работы с функцией снапшотов. Workstation Player – это и входящий в состав Workstation Pro компонент, и отдельная программа. Она может быть скачана с сайта VMware и установлена отдельно от Workstation Pro. Триал-срок в проигрывателе активен по умолчанию.

При запуске же Workstation Pro факт использования триал-срока необходимо указать.

Продукты VMware, увы, не поддерживают русский язык. Но в Интернете можно найти и скачать бесплатный русификатор программы Workstation Pro.

3. Создание виртуальной машины в VMware Workstation 15 Pro

Итак, на момент написания этой статьи актуальной версией VMware Workstation является версия 15. Собственно, с её участием и будем демонстрировать процесс создания ВМ. На домашней страничке программы жмём функцию создания новой ВМ.

Нам предлагается два типа создания ВМ:

• Обычный - упрощённый вариант с большей частью заданных самой программой параметров;
• Выборочный – пошаговый мастер с возможностью выбора многих значимых параметров.

Рассмотрим выборочный тип.

Просто жмём «Далее».

С помощью кнопки обзора указываем путь к установочному образу Windows. В нашем случае это будет Windows 10. После указания файла ISO VMware Workstation вынесет вердикт в плане возможности задействования функции быстрой установки.

Последняя являет собой упрощённый тип установки Windows с автоматическим выбором места установки, созданием пользовательского профиля и постинсталляцией VMware Tools – ПО для гостевой Windows, отвечающее за её взаимодействие с хост-системой. Функция быстрой установки может быть недоступна при использовании кастомных дистрибутивов Windows или вышедших позднее обновлений Workstation Pro версий Windows 10. В таком случае нужно будет пройти полностью процесс установки Windows, как это делается на физическом компьютере. Если эта функция доступна, на следующем этапе создания ВМ необходимо указать редакцию Windows, если их в дистрибутиве несколько, указать имя учётной записи и при необходимости пароль. Гостевую Windows при желании можно сразу же и активировать, введя ключ её лицензии. Но это не обязательно.

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

Далее выбираем тип эмуляции BIOS . Это может быть либо обычная BIOS (Legacy) , либо UEFI . Тип UEFI можно выбирать для 64-разрядных Windows 7, 8.1 и 10.

Если у процессора компьютера 4 ядра, но программа сама не выбрала для ВМ 2 ядра, делаем это вручную.

Указываем выделяемый ВМ объём оперативной памяти. Минимум – 2 Гб. Больше – лучше, но только не в ущерб оставляемой хост-системе памяти. Ей для фоновой работы также необходимо не менее 2 Гб.

Тип сети оставляем выбранный по умолчанию.

Также по умолчанию оставляем выбранный тип контроллера виртуального диска.

Тип диска, опять же, оставляем указанный по умолчанию - SCSI.

Создаём новый виртуальный диск.

По умолчанию нам предлагается виртуальный диск на 60 Гб, но поскольку мы создаём диск динамического типа, а таковой предполагается изначально, можем увеличить размер, к примеру, до 100 Гб. Если выставить галочку выделения всего места на диске, VMware Workstation создаст виртуальный диск фиксированного типа. Ставим галочку сохранения диска в одном файле.

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

И вот, собственно, всё. На последнем этапе должна стоять галочка включения ВМ сразу же после её создания. Оставляем эту галочку. И жмём «Готово».

Пару секунд VMware Workstation будет создавать виртуальный диск. Потом ВМ запустится, и в окне программы увидим установочный процесс Windows.

4. Установка Windows

Даже если используется функция быстрой установки Windows, всё равно необходимо отслеживать этот процесс. Не все его этапы могут быть автоматизированы, возможно, где-то потребуется наш, пользовательский выбор. Это зависит от дистрибутива ОС. Если функция быстрой установки недоступна, нам просто необходимо в окне VMware Workstation пройти обычный процесс установки Windows, как мы это делаем на физическом компьютере. Но с той лишь разницей, что местом установки ОС нужно указать незанятое пространство на диске – т.е. всё место на новом виртуальном диске ВМ. Загрузочный и системный разделы будут созданы автоматически в процессе установки Windows.

5. Установка VMware Tools

Если не использовалась функция быстрой установки Windows, после обычной её установки в среде ВМ необходимо установить упомянутое ПО VMware Tools. Оно адаптирует окно ВМ под разрешение физического экрана, делает возможным пропорциональное отображение гостевой ОС в свёрнутом окне VMware Workstation, реализует общий буфер обмена между системами и обеспечивает возможность включения общих папок. Для установки VMware Tools в меню «Виртуальная машина» кликаем «Установить VMware Tools. ».

Далее в среде гостевой ОС открываем DVD -привод и запускаем файл установки VMware Tools.

После инсталляции VMware Tools гостевую Windows необходимо перезагрузить.

Основное

Если вы используете VMware Workstation для создания виртуальной машины и хотите получить доступ к настройкам BIOS, то этот пост покажет вам, как это сделать. С помощью этих шагов вы сможете получить доступ к BIOS на VMware Workstation , чтобы внести различные изменения.

Откройте и используйте BIOS в VMware Workstation

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

1: использовать сочетание клавиш

Однако этот экран проходит очень быстро, и поэтому довольно сложно нажать клавишу F2 в нужное время.

Если это так, вы можете увеличить время загрузки VMware. Для этого перейдите на этот путь

Вам необходимо ввести правильное имя пользователя и правильное имя виртуальной машины.

Также вы можете перейти в папку «Документы»> «Виртуальные машины»> «Имя вашей виртуальной машины».

В этой папке вы найдете файл конфигурации виртуальной машины VMware с расширением .vmx. Это должен быть your-virtual-machine-name.vmx . Вам нужно открыть этот файл с помощью Блокнота или любого другого текстового редактора и ввести следующую строку сразу после .encoding = «windows-1252» :

Здесь X представляет время в миллисекундах. Это означает, что если вы введете 5000, это будет отложено на 5 секунд.

Теперь перезагрузите вашу виртуальную машину. Вы должны найти этот экран в течение 5 секунд.

2: использовать встроенные параметры

Есть опция, которая позволяет вам загружать вашу виртуальную машину в настройках BIOS. Для этого щелкните правой кнопкой мыши имя вашей виртуальной машины> Питание> Включение встроенного ПО .

Выберите эту опцию, и вы увидите экран вашего BIOS.

Оттуда это можно сделать различные изменения. Например, вы можете установить пароль администратора; защитить паролем всю установку и т. д.

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

Как правило, это требуется для того, чтобы указать приоритет загрузки, чтобы Вы могли в виртуальной машине загрузиться с какого-то устройства. Для того, чтобы попасть в BIOS виртуальной машины, необходимо при загрузке нажать кнопку F2. На обычных компьютерах в BIOS выполняется вход через клавишу «Del»

И в чём непосредственную проблема входа в BIOS? Как раз в том, что в виртуальной машине этот этап проходит настолько быстро, что вы просто не успеваете нажать на кнопку F2. Можно долго мучиться в попытках поймать этот момент, а можно просто увеличить время, требуемое для нажатия на кнопку входа в BIOS.

А всё делается довольно легко и просто.

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

Здесь у нас есть папка «Рабочий каталог»

Копируем данный путь и вставляем в проводник Windows, чтобы попасть в папку с файлами, относящимися к данной виртуальной машине.

Здесь нам требуется файл конфигурации, который имеет расширение vmx. Далее нам необходимо открыть его в обычном текстовом блокноте.

Если по умолчанию у вас нет возможности открытия файла в текстовом блокноте, то выбираем выбрать «Другое приложение \ Ещё приложение \ Выбираем наш текстовый редактор».

Но, не забываем о том, что галочка всегда использовать это приложение для открытия vmx файлов не должна стоять. То есть открываться они должны VMWare Workstation, так как нам это нужно исключительно как разовая операция.

В результате чего, у нас открывается файл с различными параметрами виртуальной машины. Куда необходимо добавить строчку:

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

Сохраняем данный файл и пробуем запустить нашу виртуальную машину. Как увидите всё отлично теперь у нас время для того чтобы успеть нажать на кнопку F2 намного больше, и мы это в любом случае успеем сделать.

А по нажатию на кнопки в F2 мы выполняем вход в долгожданный BIOS виртуальной машины и меняем приоритет загрузки устройств, если перед вами стаяла именно эта задача.

Проштудировав документы Perfomance Best Practices for vSphere 5.5 и Perfomance Best Practices for vSphere 6.0, не выявил особых расхождений в настройке, как и чего-то дополнительно специфичного для vSphere 6.0.

Большая часть написанного умещается в стандартные рекомендации формата «используйте совместимое и сертифицированное оборудование» и «при сайзинге ВМ выделяйте ресурсы (vCPU, vRAM) в объёме не более необходимого».

Тем не менее, базовые вещи решил оформить отдельным постом, немного переструктурировав, избавив от «воды» и некоторых отсылок и замечаний, которые являются слишком специфичными и для большинства реализаций являются скорее вредными чем полезными. В сухом остатке остались рекомендации, советы и соображения, проверенные и протестированные на практике и применимые для 90% инфраструктур VMware vSphere и standalone ESXi. Разбавленные общими соображениями и дополнениями.

Хост ESXi

Общие рекомендации

Ну понятно, стоит использовать совместимое оборудование. Процессоры с аппаратной поддержкой виртуализации. Процессоры в разных хостах кластера должны быть минимум одного производителя (Intel/AMD) а желательно и одного уровня технологий и поколения. Иначе проблемы с vMotion и производительностью. И желательно вообще единообразие в аппаратной конфигурации кластера — проще управлять (Host Profiles) и диагностировать.
Установить свежие версии BIOS и firmware на все «железки». Не обязательно это скажется на росте производительности, но в случае проблем на стыке железо-софт техподдержка вендора всё равно будет требовать обновления прошивок. Мы с IBM так почти год чинили Blade-корзину — пока обновили прошивки на всех задействованных и не очень компонентах, они выпустили их новые версии и пришлось идти по второму кругу.

Убедиться, что включены все необходимые и полезные компоненты и технологии — ядра процессора, Turbo Boost, если есть, технологии виртуализации (VT-x, EPT, AMD-V и т.п.).
Отключена опция NUMA Node Interleaving или включена опция Enable NUMA. Данный пункт часто вводит в заблуждение. ESXi — NUMA-awared ОС, более того, она умеет транслировать NUMA-архитектуру в виртуальные машины, так что включение возможности распознавать NUMA-ноды сказывается положительно на общей производительности в большинстве случаев. Однако опция «NUMA Node Interleaving», будучи в состоянии «Enable» на деле объединяет ноды в единое пространство, то есть отключает распознавание NUMA-нод.

/NUMA — Non-Uniform Memory Access — архитектура серверных систем, при которой время доступа к памяти определяется размещением её относительно процессора. У каждого процессора свой набор модулей памаяти, куда доступ быстрее, этот комплект и образует NUMA-ноду./

Гипервизор

Тут стоит иметь ввиду, что и по процессору и по памяти для каждой виртуальной машины есть определённый оверхед — дополнительное количество того и другого, необходимое для работы самой ВМ:

— для процесса vmx (VM eXecutable);
— для процесса vmm (VM Monitoring) — мониторинг состояния виртуального процессора, маппинг — виртуальной памяти и т.д.;
— для работы виртуальных устройств ВМ;
— для работы других подсистем — kernel, management agents.

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

Виртуальные машины

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

— оверхед, описанный в предыдущем разделе;
— NUMA. Если количество vCPU соответствует количеству ядер в NUMA-сокете и объём памяти тоже не выходит за пределы NUMA-ноды, то гипервизор старается локализовать ВМ внутри одной NUMA-ноды. А значит доступ к памяти будет быстрее;
— Планировщик процессора. Если на хосте много ВМ с большим количеством vCPU (больше в сумме, чем количество физических ядер), то растёт вероятность появления такого явления как Co-Stop — притормаживание некоторых vCPU из-за невозможности обеспечить их синхронную работу в рамках отдельной ВМ, потому что количества физических ядер не хватает для одновременного цикла;
— DRS. Машины с небольшим количеством процессоров и памяти переносить с хоста на хост проще и быстрее. В случае внезапного скачка нагрузки легче будет перебалансировать кластер, если он состоит из небольших ВМ, а не из многогигабайтных монстров;
— Локализация кэша. Внутри ВМ гостевая ОС может переносить однопоточные процессы между различными процессорами и терять процессорный кэш.

Выводы и рекомендации:

Лучше один процессор, загруженный на 80%, чем 4 по 20%.
Если у сервера пиковая загрузка происходит раз в квартал, а в остальное время он работает на 10% своих ресурсов, лучше урезать их (ресурсы) сразу в 8 раз, а раз в квартал добавлять необходимое количество.
Стараться умещать ВМ по количеству vCPU и памяти в границы NUMA-node.
Если ВМ выходит за пределы NUMA-ноды (wide VM), конфигурировать число процессоров кратное числу ядер в NUMA-ноде. Если у нас в одном сокете 4 ядра, то кратные числа процессоров, рекомендуемые для ВМ будут 4, 8, 12.
При использовании нескольких vCPU, лучше конфигурировать их как отдельные виртуальные сокеты с одним виртуальным ядром в каждом. Ну или с количеством ядер, являющимся целым делителем от числа ядер в NUMA. Если в физическом сокете 4 ядра, то в виртуальном правильным значением будет 1, 2, 4. Но не 3 или 6.
Отключать неиспользуемое виртуальное оборудование виртуальной машины (COM-, LPT-, USB-порты, Floppy Disks, CD/DVD, сетевые интерфейсы и т.д.)
Использовать паравиртуальное оборудование (VMware Paravirtual для SCSI-контроллера и VMXNET для сетевого адаптера). Это уменьшает нагрузку на процессор и время отклика, но может потребовать драйвера для установки ОС.

Гостевая ОС

Использовать последние версии VMware Tools. После каждого обновления ESXi приводить в соответствие.
И вообще иметь установленными VMware Tools.
Отключать screen saver'ы и вообще любую анимацию и красивости. По возможности отключать графику. Это значительно снижает нагрузку на процессор.
Избегать одновременного запуска интенсивных задач (таких как антивирусное сканирование, бэкапы и особенно дефрагментация). Дефрагментацию лучше вообще отключить. Остальное, если нельзя избежать, размазывать для разных машин в разное время.
Синхронизировать время гостевой ОС с помощью ntp-сервисов или VMware Tools, но не обоих инструментов сразу. Но хотя бы одним. Так как стоит иметь ввиду, что время в гостевой ОС — не точная величина, поскольку зависит от процессора, а процессорного ресурса ВМ может получать не равномерно и не всегда в нужном объёме.
vNUMA. Стоит принимать во внимание, что для ВМ с количеством vCPU большим восьми активируется проброс NUMA-архитектуры внутрь ВМ. Для некоторых NUMA-awared приложений, например, Exchange или MS SQL это полезно. Однако vNUMA определяется при первой загрузке ОС и не меняется, пока не изменится количество процессоров. Поэтому, если в кластере наличествуют хосты с разным количеством ядер в сокетах, а значит с разной NUMA-архитектурой, то при переезде ВМ с хоста на хост, производительность может падать из-за того что vNUMA не совпадает с NUMA на новом хосте.

Хранение и хранилища

Главное, что стоит принять во внимание — ваше хранилище должно поддерживать vStorage API for Array Integration (VAAI). В этом случае будет поддерживаться следующее:

— Оффлоад процессов копирования, клонирования и переноса ВМ между LUN одного хранилища или между хранилищами, поддерживающими технологию. То есть процесс будет выполняться большей частью самим хранилищем, а не процессором хоста и сетью.
— ускорение зануления блоков при создании Thick Eager Zeroed дисков и при первичном наполнении Thick Lazy Zeroed и Thin дисков.
— Atomic Test and Set (ATS) — блокирование не всего LUN, при изменении метаданных, а только одного сектора на диске. Учитывая, что метаданные изменяются при таких процессах как включение/выключение ВМ, миграция, клонирование и расширение тонкого диска, LUN с большим количеством ВМ на нём может не вылезать из SCSI Lock'а.
— Unmap — «освобождение» блоков тонких LUN при удалении/переносе данных (касается только LUN, но не vmdk).

Соображения и рекомендации:

Independent Persistent Mode vmdk-диска — наиболее производительный, поскольку изменения вносятся сразу на диск, не журналируясь. Но такой диск не подвержен снапшотам, его нельзя откатить.
При использовании iSCSI рекомендуется настроить jumbo frames (MTA=9000) на всех интерфейсах и сетевом оборудовании.
MultiPathing — для большинства случаев RoundRobin — ОК. Fixed может дать большую производительность, но это после вдумчивого планирования и ручной настройки каждого хоста до каждого LUN. MRU можно поставить при active-passive конфигурации, если какие-то пути время от времени пропадают — чтобы не перескакивало туда-обратно.

Инфраструктура виртуализации

DRS и кластеры

Для управления ресурсами и контроля их использования, лучше использовать Shares в большей мере, а Limits и Reservation — в меньшей. Лимиты жёстко ограничивают ВМ, даже если кластер имеет свободные ресурсы. Резервирование, напротив, отъедает много ресурсов, даже если они не используются. Кроме того, при апгрейде физического оборудования настройки Shares автоматически распределяют новые мощности пропорционально. А забытые лимиты и резервирование могут привести к тому, что часть машине недополучает ресурсов, хотя в кластере их уже более чем достаточно.
Не стоит сооружать сложные многоступенчатые иерархические конструкции из Resource Pools. Для иерархий есть папки. А также держать на одном уровне (например, в корне) и Resource Pools и виртуальные машины. Потому что расчёт Shares для этих типов объектов производится по разному и могут появляться непредвиденные перепады производительности.
Ещё раз — чем ближе хосты друг другу по конфигурации, тем лучше. В идеале — в кластеры все хосты однотипные. Без EVC даже на хосты с процессорами одного вендора, но разным набором технологий ВМ перемещаться смогут только в выключенном состоянии.

vMotion и Storage vMotion

По умолчанию, на каждый активный процесс vMotion гипервизор отъедает 10% одного ядра процессора. И на приёмнике и на источнике. То есть если на хосте все процессорные ресурсы находятся в резервировании, с vMotion могут быть проблемы. (С DRS точно будут).

При Storage vMotion с исходного датастора активно идёт чтение, а на целевой — запись. Кроме того, на оба датастора идёт синхронная запись изменений внутри ВМ. Отсюда вывод — если двигаем ВМ с медленного датастора на быстрый, эффект будет заметен только по окончанию миграции. А если с быстрого на медленный, то деградация производительности наступит сразу.

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