Как я ставил ESXi на Desktop
Вот и такие не тривиальные задачи порой приходится совершать 
.
Поставил я перед собой вопрос по сбору для себя небольшого стенда для тестирования. В моем небольшом подсобном хозяйстве УВЫ 
отсутствует EXS(i) совместимый сеовер. Поэтому пришлось обходиться небольшим и не маленьким десктопом.
Надеюсь Вы в курсе, что для ESX как правило подходит специально «заточенное» железо, которое рекомендовано VmWare .
Кстати, стоит помнить что куда интересней устанавливать ESX на отдельную флешку, а не на имеющийся HDD.
Первым делом стоит скачать оригинальный образ vSphere Hypervisor с сайта VmWare.
Затем скачать дополнительное программное обеспечение ESXi-Customizer, которое может добавить нужные нам драйвера.
Ну и скачать нужные нам драйвера для ESX, а для этого нужен Google.
Так как на плате 82579V LAN, то в поисковике нужно искать по следующему запросу: «esxi 82579 vib».
После чего запускаем ESXi-Customizer и указываем пути, а на выходе получаем рабочий для нас образ .
Собственно все что хотел сегодня Вам рассказать.
У этой статьи есть более актуальное продолжение Домашний ESXi.
Установка esxi на ноутбук
Добрый день! Уважаемые читатели и гости, крупнейшего IT блога Pyatilistnik.org. Продолжаем с вами изучать технологии виртуализации и различные гипервизоры. В прошлый раз мы с вами рассматривали установку гипервизора ESXI 5.5, данная версия хорошая, но уже имеет обновленную версию 6.5 или 6.7. Сегодня я подробно рассмотрю, как производится установка Esxi 6.5 с последующей, начальной настройкой, которая вам позволит получить хост виртуализации, готовый к вводу в эксплуатацию со всеми последними возможностями. В следующих статьях, я покажу алгоритм перехода с 5.5 на 6.5 и выше.
Алгоритм установки гипервизора VMware ESXI 6.5
Хочу отметить, что существуют несколько методов достижения нашей поставленной цели, которые могут инсталлировать данную операционную систему:
Когда вы выбрали метод загрузки дистрибутива Vmware ESXI 6.5, можно приступать к его установке, сама инсталляция во всех методах одинакова. Загрузившись с вашего носителя, у вас появится вот такое синее окно инсталлятора, тут будет два пункта:
У вас появится окно загрузчика «Load ESXi installer», тут можно выбрать старую версию загрузчика или же продолжить установку, нажав Enter.
Начинается процесс подгрузки в оперативную память необходимых файлов Vmware ESXI 6.5 инсталлятора.
Через пару мгновений у вас появится привычный серо-желтый экран, в котором будут загружаться библиотеки и пакеты, тут вы увидите версию релиза, количество вашей ОЗУ и CPU.
Если у вас будет в сервере оперативной памяти меньше, чем 4 ГБ, то вы увидите вот такое пурпурное окно с напоминанием:
Если по ресурсам у вас все хорошо, то вы увидите приветственный баннер, на котором нажимаем «Enter».
Читаем лицензионное соглашение и если все вас устраивает, то нажимаем клавишу F11.
Установщик ESXI 6.5, начнет сканирование сервера, на предмет локальный, сетевых или внешних дисков.
В списке дисковых устройств выберите нужные вам, на которое будет устанавливаться ваш гипервизор, хочу отметить, что вы спокойно можете установить на встроенную SD карту, если такая есть или же на внешнюю флешку. Я выбираю локальный диск, размером 5 ГБ.
Задаем язык гипервизора Vmware ESXI 6.5, я оставлю по умолчанию английский, нажимаем Enter.
Указываем пароль от root пользователя, тут требования минимум 7 символов и желательно большие и маленькие буквы.
При нажатии клавиши F11 у вас начинается установка esxi 6.5.
Вот так вот выглядит сам процесс инсталляции гипервизора Vmware ESXI.
Как видим установка Vmware ESXi 6.5, успешно закончена и вам предлагается перезагрузить ваш сервер, соглашаемся.
Начальная настройка VMware ESXI 6.5
После успешной установки ESXI 6.5, у вас после перезагрузки появится вот такое черное окно, в котором у вас будет два возможных варианта развития событий:
заходим в режим «Customize SystemView Logs», у вас появится окно авторизации, где вы указываете логин root и пароль, который задавали при установке ESXI 6.5.
У вас откроется окно «System Customization». На первом пункте «Configure Password», вы можете поменять пароль от root.
Вы указываете один раз старый пароль и два раза новый.
Переходим к пункту меню «Configure Management Network», тут производится настройка сети управления у ESXI 6.5, справа вы можете так же получить информацию, о IPv-4 адресах. Переходим в данный пункт.
Пункт «Network Adapters», покажет вам ваши сетевые интерфейсы, переходим в него
В моем примере их два, один активный, второй нет, если вы его хотите активировать, то выберите его и нажмите клавишу пробел, на против него появится крестик. Обратите внимание, выделенные сети будут отданы под сеть управления. В идеале для нее лучше назначать минимум два адаптера, для отказоустойчивости. Тут же вы найдете и mac-адреса.
Следующим этапом настройки ESXI 6.5, будет пункт меню «VLAN (options)», отвечающий за указание в каком сегменте VLAN у вас располагается ваш сетевой интерфейс, если у вас их нет, то тут стоит оставить все по умолчанию. Обычно с помощью VLAN и отделяют сеть управления от остальных.
Задается он просто, числом от 1 до 4095
Далее настройка EXI 6.5, позволяет вам в пункте «IPv4 Configuration», изменить ip-адрес на статический или вообще отключить сетевой интерфейс.
На выбор будет три пункта:
То же самое вы можете выполнить и по отношению к интерфейсу IPv6.
Далее переходим к настройке DNS серверов, через пункт «DNS Configuration»
Тут будет два пункта:
В пункте «Custom DNS Suffixes», можно задать доменный суффикс.
В моем примере, это root.pyatilistnk.org.
Выходя из настроек сети ESXI 6.5, необходимо будет сохранить настройки и перезапустить сеть управления.
Отдельно можно перезапустить сеть управления из пункта «Restart Management Network»
Выглядит это вот так, вы соглашаетесь с рестартом.
В итоге сеть управления ESXI 6.5 будет выключена и заново включена.
В момент настройки VMware ESXI 6.5 у вас есть возможность из «System Customization», произвести сетевые тесты, на предмет доступности DNS или шлюза, сделать это можно из пункта «Test Management Network».
Проверяются пинги до нужных адресов и разрешение DNS имен.
Вот так вот выглядят результаты тестирования, тут сразу можно увидеть, есть ли проблемы с DNS или маршрутизацией.
Если вы допустили какие-либо ошибки в момент настройки или работы хоста виртуализации, и не знаете как все восстановить, то можно сбросить сетевые настройки на те, что были по умолчанию и быстро потом все перенастроить, так как появится доступ к сети управления. Делается, это все из меню «Network Restore Options».
Запускаем VMWare ESXi 6.5 под гипервизором QEMU
На свете существует замечательный гипервизор ESXi от компании VMWare, и все в нем хорошо, но вот требования к “железу”, на котором он может работать, весьма нескромные. ESXi принципиально не поддерживает программные RAID’ы, 100-мегабитные и дешевые гигабитные сетевые карты, поэтому попробовать, каков он в работе, можно только закупившись соответствующим оборудованием.
Однако ESXi самые “вкусные” возможности ESXi открываются тогда, когда у нас есть не один, а несколько хостов ESXi — это кластеризация, живая миграция, распределенное хранилище VSAN, распределенный сетевой коммутатор и т.п. В этом случае затраты на тестовое оборудование уже могут составить приличную сумму. К счастью, ESXi поддерживает Nested Virtualization — то есть способность запускаться из-под уже работающего гипервизора. При этом и внешний гипервизор понимает, что его гостю нужен доступ к аппаратной виртуализации, и ESXi знает, что работает не на голом железе. Как правило, в качестве основного гипервизора также используется ESXi — такая конфигурация поддерживается VMWare уже довольно давно. Мы же попробуем запустить ESXi, использую гипервизор QEMU. В сети есть инструкции и на этот счет, но, как мы увидим ниже, они слегка устарели.
Для начала обозначим версию QEMU, на которой будем ставить эксперименты:
Последняя на данный момент версия, но у меня фокус получался даже на 2.4.0.
Затем отключим невежливое поведение модуля KVM в моменты, когда гость пытается читать машинно-специфические регистры, которых на самом деле нет. По-умолчанию, KVM в ответ на это генерирует внутри гостя исключение General protection fault, отчего гость ложится в синий (в нашем случае-розовый) экран смерти. Сделаем под рутом:
В некоторых дистрибутивах модуль kvm грузится по умолчанию с нужными параметрами, в некоторых — нет. В любом случае нужно проверить dmesg на наличие строк
Если этих строк нет — добавить в /etc/modprobe.d/kvm.conf строку
и перезагрузиться. Для процессора Intel строка примет вид:
Что интересно — сообщения о включенных Nested Paging/Nested Virtualization в dmesg подает только kvm-amd, а kvm-intel этого не делает.
Попробуем решить проблему “в лоб” — пойдем на сайт VMWare, зарегистрируемся там и скачем последний на данный момент образ VMware-VMvisor-Installer-201701001-4887370.x86_64.iso.
Не будем измудряться, создадим аналог “флешки” на 16Gb, возьмем наверняка поддерживаемую сетевую карту e1000, поставим RAM в 4 Gb (с меньшим количеством памяти ESXi гарантированно не встанет) и запустим установку, полагая, что в такой конфигурации ESXi как минимум не увидит IDE-диска:
И тут нас ждет первая неожиданность — ESXi не только обнаруживает наш IDE-диск, но и успешно ставиться на него, правда, на пять минут подвисая на 27% установки:
Кстати, перед началом установки у меня появляется вот такое сообщение:
А вот 8086:100e — это идентификатор чипа “Intel 82540EM Gigabit Ethernet Controller”, который с некоторых пор объявлен unsupported, т.е. он работает, но с ним не работает техническая поддержка.
Вообще, QEMU поддерживает эмуляцию разных сетевых карт:
но не все они работают в ESXi одинаково хорошо, например, с формально поддерживаемым e1000e не работает проброс портов в user-режиме сети, а у vmxnet3 пропадает половина пакетов. Так что остановимся на e1000.
Перезагружаем ВМ и видим, что гипервизор стартовал успешно. Собственно, и все — патчить QEMU для ESXi, как рекомендуют некоторые руководства, не нужно.
Нужно отметить, что я использую параметр nocow=on при создании диска, поскольку диск ВМ будет лежать на btrfs, которая сама по себе является ФС с концепцией copy-on-write. Если добавить к этому то, что и thin-provisioned диск формата qcow2 тоже реализует этот принцип, то получится кратное увеличение числа записей на диск. Параметр nocow=on заставляет qemu-img создавать файл с атрибутом nocow и тем самым блокировать механизм copy-on-write в btrfs для конкретного файла.
В режиме сети user внутри ВМ работает легковесный DHCP-сервер, поэтому адрес присваивать не нужно, однако придется пробрасывать порты. Заходим в консоль QEMU, нажав Ctrl+Alt+1, вводим там команду
и пробрасываем 443 порт с сетевого интерфейса виртуальной машины на 4443 порт хоста. Затем в браузере набираем
подтвердим исключение безопасности (ESXi, понятное дело, пока использует самоподписанный сертификат для https) и увидим Web-интерфейс гипервизора:
Удивительно, но установщик ESXi даже создал в свободной области диска “хранилище” размером целых 8Gb. Первый делом поставим пакет с обновленным Web-интерфейсом, потому что разработка этого полезнейшего компонента идет быстрее, чем выходят новые версии ESXi. Идем в консоль QEMU по Ctrl+Alt+1 и пробрасываем там 22 порт:
потом переключаемся в консоль гипервизора по Ctrl+Alt+2, нажимаем F2 — Troubleshooting Options — Enable SSH и подключаемся клиентом SSH:
Идем во временный каталог
Как видно, размер Web-интерфейса — чуть больше трех мегабайт.
Теперь попробуем улучшить нашу виртуальную машину. Первым делом сменим контроллер дисков с IDE на AHCI, потому что реализация контроллера PIIX3 1996 года выпуска в QEMU, как бы это сказать, слегка тормознутая. А контроллер AHCI (эмулируется чипсет Intel ICH9) во-первых, быстрее, а, во вторых, поддерживает очереди команд NCQ.
Даже по уменьшению времени загрузки компонентов гипервизора видно, что прирост в скорости мы получили. На радостях заходим в Web-интерфейс и… как это нет дисков? На вкладке “Adapters” AHCI-контроллер имеется, однако диски на нем не определяются. А как же тогда загрузился гипервизор? Очень просто — на начальном этапе загрузчик считывает данные диска при помощи BIOS и видеть диски напрямую ему не нужно. После того, как компоненты загружены в память, загрузчик передает на них управление, а инициализация гипервизора проходит уже без обращений к диску.
Как бы то ни было, ESXi 6.5 дисков на AHCI-контроллере не видит, а вот ESXi 6.0 эти диски видел — зуб даю. С помощью Google и такой-то матери выясняем причину: в ESXi 6.5 старый драйвер ahci замене на полностью переписанный драйвер vmw_ahci, из-за чего у кучи народа тормозят SSD, а у нас не определятся диски. Согласно совету из статьи делаем на гипервизоре
перезагружаемся и… ничего не происходит. А чего мы хотели? Дисков-то нет, записывать конфигурацию некуда, следовательно, наши изменения и не сохранились. Надо вернуться на IDE-диск, выполнить эту команду и уже потом загружаться с AHCI — тогда диски определяться.
Кстати, если мы зайдем в web-интерфейс, то увидим, что созданное установщиком 8-гигабайтное “хранилище” теперь недоступно. Так что для разных типов контроллеров VMWare имеет разные политики определения хранилищ. Теперь попробуем изобразить реальную конфигурацию системы, когда ESXi установлен на флеш-накопитель, подключенный по USB, а хранилище располагается на жестких дисках. Используем эмуляцию USB 3.0:
USB 3.0 диски тоже не определяются. Видимо, и здесь драйвер переписан. Ну что ж, мы уже знаем, что делать. Идем в консоль гипервизора, там пишем
Когда система загрузится, зайдем в Storage — Devices и увидим там нашу флешку. Кстати, с USB 3.0 контроллером nec-usb-xhci система загружается намного быстрее, чем с ich9-usb-ehci2.
Итак, минимум два драйвера контроллера диска в ESXi 6.5 переписаны заново по сравнению с ESXi 6.0. А казалось бы — только цифра после точки в номере версии изменилась, можно сказать, минорный релиз.
Заходим в консоль — вот они, наши диски.
Продолжим эксперименты: теперь нам нужно объединить несколько гипервизоров в сеть. Какой-нибудь libvirt самостоятельно создает виртуальный коммутатор и подключает к нему машины, а мы попробуем провести эти операции вручную.
Пусть у нас будут две виртуальные машины, значит, нам потребуется два виртуальных адаптера
Теперь нам нужен виртуальный коммутатор. Долгое время для этих целей принято было использовать встроенный в ядро Linux виртуальный коммутатор, управляемый утилитой brctl. Сейчас же принято решать задачу через Open vSwitch — реализацию коммутатора, предназначенную именно для виртуальных сред. Open vSwitch имеет встроенную поддержку VLAN, протоколов туннелирования (GRE и т.п) для объединения нескольких коммутаторов и, что самое интересное — технологии OpenFlow. Иными словами, в коммутатор можно загружать правила фильтрации L2/L3 в удобочитаемом формате. Раньше для фильтрации требовалось использовать iptables/ebtables, а, как говориться, хорошую вещь “ebtables” не назовут.
Установим Open vSwitch, если он еще не стоит:
Создадим виртуальный коммутатор:
Добавим в него интерфейсы:
Посмотрим, что получилось:
Теперь присвоим интерфейсу коммутатора адрес:
Казалось бы, достаточно просто изменить тип сети в командной строке QEMU с user на tap, примерно так:
и все будет работать.
Зайдем в консоль ESXi и присвоим ему адрес — 192.168.101.2, а затем проверим связь:
….
и из консоли ESXi — F2- Test Network
Все работает, пинги ходят.
Сделаем копию диска esxi_6.5-1.qcow2 и запустим второй экземпляра ESXi:
Тут нас ждут неожиданности: ping от хоста к первому гостю ходит лишь до того момента, пока мы не запускаем пинг ко второму гостю. После прерывания второй команды ping пакеты к первому гостю начинают ходить секунд через 10. Пинги между гостями не ходят вообще.
Ясно, что мы напортачили с mac-адресами, и действительно, QEMU присваивает всем tap-адаптерам один и тот же mac-адрес, если не указано иное.
Выключим оба ESXi’а, укажем им уникальные mac’и и запустим снова.
И в другой консоли:
К нашему громадному удивлению, проблема с пингами никуда не делась, мало того, команда arp показывает, что не изменились и MAC-адреса гипервизоров. Тут самое время вспомнить, как устроена сеть в ESXi: физическая сетевая карта переведена в “неразборчивый режим” и подключена в качестве одного из портов к виртуальному коммутатору. Другим портом к этому коммутатору подключен интерфейс vmkernel, который и является сетевой картой с точки зрения гипервизора. В момент установки ESXi аппаратный адрес физической сетевой карты клонируется в vmkernel, чтобы не смущать системного администратора. После этого его можно изменить только удалив интерфейс и создав его заново или же указав гипервизору, что следует переконфигурировать vmkernel из-за изменения адреса физической карты.
Существенная различие между указанными способами состоит в том, что первый не требует перезагрузки гипервизора, а второй — требует.
Выполнив эти нехитрые операции, мы получим в одной сети два гипервизора.
Теперь можно ставить vCenter и проверять”живую миграцию”. С некоторых пор vCenter доступен в виде образа виртуальной машины с Linux и соответствующими службами на борту. Именно такой вариант мы попробуем установить. Берем образ VMware-VCSA-all-6.5.0-5178943.iso, монтируем его в хостовой ОС, запускаем инсталлятор из каталога vcsc-ui-installer\lin64 и разворачиваем образ, следуя указаниям мастера. Для виртуальной машины потребуется 10 Gb оперативной памяти, так что на хостовой системе неплохо было бы иметь минимум 16 Gb. Впрочем, у меня образ развернулся и на 12 Gb RAM, съев всю доступную память и загнав систему в своп.
После установки VCSA заходим в Web-интерфейс с учетными данными вида administrator@mydomain.tlb и паролем, которые мы указали при настройке SSO. После этого добавляем в vCenter оба хоста и получаем простейший кластер, в котором работает живая миграция. Настроим vMotion на сетевых картах обоих хостов, создадим виртуальную машину TestVM и убедимся, что она может переезжать с одного хоста на другой, меняя как хост, так и хранилище.
Кстати, на предыдущих версиях ESXi до 6.0 включительно виртуальную машину невозможно было запустить в режиме вложенной виртуализации без добавления строки
в ее конфигурационный файл. В ESXi 6.5 этого делать не требуется, и виртуальная машина запускается без вопросов.
В заключение — небольшой лайфхак. Допустим, вам нужно скопировать файл диска ВМ из хранилища ESXi куда-нибудь на сервер резервных копий, при этом у вас нет возможности пользоваться FastSCP из состава Veeam Backup and Replication. Вам на помощь придет старый добрый rsync, нужно только найти бинарный файл, который запуститься на ESXi. К сожалению, в rsync вплоть до версии 3.0.9 включительно есть баг, из-за которого некорректно обрабатываются большие файлы на томах VMFS, поэтому стоит использовать rsync версии 3.1.0. и выше. Взять его можно здесь.