Автоматизация для самых маленьких. часть 1.1. основы виртуализации

Инкапсуляция пакета

В виртуализации сети Hyper-V каждый виртуальный сетевой адаптер связан с двумя IP-адресами:

• Адрес клиента (ЦС) IP-адрес, назначенный клиентом на основе инфраструктуры интрасети. Этот адрес позволяет клиенту обмениваться сетевым трафиком с виртуальной машиной, как если бы он не был перемещен в общедоступное или частное облако. АК является видимым для виртуальной машины и доступным для клиента.

• Адрес поставщика (PA) IP-адрес, назначенный поставщиком услуг размещения или администраторами центров обработки данных на основе своей физической сетевой инфраструктуры. АП появляется в сети в виде пакетов. Обмен ими производится с сервером Hyper-V, на котором размещается виртуальная машина. АП является видимым в физической сети, но не для виртуальной машины.

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

Рисунок 6. Концептуальная схема виртуализации сетей относительно физической инфраструктуры

На схеме виртуальные машины клиента отправляют пакеты данных в пространстве ЦС, которые проходят через физическую сетевую инфраструктуру через собственные виртуальные сети или туннели. В приведенном выше примере туннели можно рассматривать как «конверты» вокруг пакетов данных Contoso и Fabrikam с зелеными метками доставки (PA-адреса), которые будут доставлены с исходного узла слева на целевой узел справа. Ключ заключается в том, как узлы определяют «адреса доставки» (PA), соответствующие Contoso и ЦС Fabrikam, как «конверт» помещается вокруг пакетов, и как конечные узлы могут распаковать пакеты и доставить их на конечные виртуальные машины Contoso и Fabrikam.

Ключевые аспекты виртуализации сетей объясняются при помощи простой аналогии:

• АК каждой виртуальной машины сопоставляется с АП физического узла. С одним АП может быть связано несколько АК.

• Виртуальные машины отправляют пакеты данных в пространстваХ ЦС, которые помещаются в «конверт» с парой источника и назначения PA на основе сопоставления.

• Сопоставления АК — АП должны позволять узлам производить дифференциацию пакетов для различных клиентских виртуальных машин.

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

Для чего нужна аппаратная виртуализация?

При аппаратной виртуализации на сервере (на хосте) устанавливается программная прослойка – гипервизор или операционная система со встроенным гипервизором с последующим предоставлением виртуальным машинам ресурсов сервера (хоста), таких как:

• вычислительные (виртуальные процессоры),
• памяти,
• дисковой и сетевой подсистемы.

Аппаратная виртуализация закрывает следующие задачи:

• быстрое предоставление сервисов бизнесу;
• исключение несовместимости приложений при совместной работе в одной общей ОС;
• возможность использования разного окружения операционных систем (на одном хосте системы Linux и Windows);
• сокращение затрат на приобретение новых серверов за счет утилизации существующих.

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

Облака

Модель обслуживания или сервисная модель

• IaaS (Infrastructure as a Service) — поставщик предоставляет только вычислительные ресурсы (servers, storage, processing, memory, network bandwidth). При этом может предоставляться набор подготовленных образов OS, которые разворачиваются за несколько минут. Также предоставляется сетевая связность между виртуальными машинами и дополнительные дисковые ресурсы. Отдельной частью IaaS является MaaS (Metal as a Service) — предоставление доступа к голому железу без OS (bare-metal servers). Пример поставщика IaaS: AWS. Платформы для построения IaaS: VMware, OpenStack, Azure.
• PaaS (Platform as a Service) — поставщик предоставляет операционную систему и определенный софт для самостоятельной реализации заказчиком своих услуг, например, DB, CMS. Примеры: OpenShift, Heroku, Google Cloud Platform, Cloud Foundry.
• SaaS (Software as a Service) — поставщик предоставляет софт для использования заказчиком, например: Microsoft Office 365, Microsoft Exchange, 1C и т.п.

Модель развертывания

• Private cloud (Частное облако) — инфраструктура разворачивается внутри организации, тем самым обеспечивается безопасность и производительность.
• Public cloud (Публичное облако) — инфраструктура предназначена для предоставления услуг сторонним заказчикам. Например, AWS, Google Cloud. Преимущества тут очевидны: не нужен обслуживающий персонал, быстрорасширяемые ресурсы, платишь только за то, что потребил (часы, гигабайты), возможность сосредоточится на идее или бизнесе, а не на обслуживании инфраструктуры. Хорошо подходят для быстрого развертывания небольших систем, для организации стартапов.
• Community cloud (Общественное облако) — инфраструктура разделяется между несколькими организациями со схожими концепциями потребления ресурсов, политиками в безопасности и т.п. Потребителей меньше чем в публичном облаке, но больше чем в частном. Пример: Google Apps for Government.
• Hybrid cloud (Гибридное облако) — это комбинация из двух или более различных облачных инфраструктур (частных, публичных или общественных). Среди гибридных облаков есть интересные кейсы использования, например: внутри частного облака организация хранит всю необходимую актуальную информацию, а резервные копии прозрачно отправляются в публичное облако.

Функциональные характеристики

• Broad Access Network — возможность доступа к ресурсам из Интернета с помощью разнообразных устройств.
• Rapid Elasticity — эластичность ресурсов. При необходимости быстрое выделение дополнительных ресурсов, вплоть до бесконечности.
• Measured Services — автоматическое измерение услуг и выставление счетов для оплаты.
• On-Demand Self Services, Resource Pooling — выделение вычислительных ресурсов (resource pooling) по запросу от заказчиков (on demand).

Обратная сторона облаков

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

1. Как обрабатываются конфиденциальные данные?
2. Соблюдены ли требования регулятора к персональным данным?
3. Насколько надежна сохранность данных (дублирование, бекапирование)?
4. Какая защита от хакерских атак?

Управление виртуальными машинами

Создание снимков гостевых систем

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

Внимание! Не делайте этого с продукционными машинами.

• Выделить гостевую систему, с которой нужно сделать снимок
• Перейти на вкладку «Snapshots»
• Нажать кнопку «Take Snapshot» (с изображением фотоаппарата)
• Ввести название снимка и комментарий

• Выделить гостевую систему, с которой нужно сделать снимок
• Выключить гостевую систему, нажав «Stop»>«Power Off»
• Перейти на вкладку «Snapshots»
• Выделить снимок, который нужно восстановить
• Нажать кнопку «Restore Snapshot» (с изображением компьютера со стрелкой вверх)

Установка Virtuozzo

Установка Virtuozzo аналогична установке дистрибутива Fedora — инсталлятор Anaconda абсолютно такой же (рис. 2). Для установки Virtuozzo нужно выполнить следующие действия:

1. Загрузиться с инсталляционного диска.
2. Нажать кнопку «Installation destination».
3. Если устанавливаешь на новый сервер, где нет операционной системы, выбери «Automatically configure a partitioning» и нажми кнопку «Done» (рис. 3).
4. Если операционная система уже установлена и есть желание ее сохранить, тогда нужно выбрать «I will configure partitioning» и настроить разделы вручную.
5. Нажать кнопку «Begin installation» (рис. 4).
6. Во время установки системы нужно установить пароль root и создать одного обычного пользователя (рекомендуется из соображений безопасности), см. рис. 5.

Рис. 2. Инсталлятор VirtuozzoРис. 3. Разметка дискаРис. 4. Нажми кнопку Begin installationРис. 5. Установка Virtuozzo

После перезагрузки появится возможность войти в систему (рис. 6).

Рис. 6. Вход в систему
Рекомендуем почитать:

Что нужно знать о VLAN

VLAN — это виртуальные сети, которые существуют на втором уровне модели OSI и реализуются с помощью коммутаторов второго уровня. Не вдаваясь в подробности, можно сказать, что это группа портов коммутатора, разделенная на логические сегменты сети. Каждый такой сегмент имеет свой маркер (тег PVID). Каждая группа портов VLAN’а знает о своей принадлежности к определенной группе благодаря этим тегам.

Существует два типа портов: access и trunk. В access подключаются конечные сетевые устройства, в trunk подключаются только другие trunk-порты. Если с компьютера пакет попадает на access-порт, то он помечается тегом (PVID), и далее коммутатор отправляет этот пакет только на порты точно с такими же VLAN ID или на trunk-порт. При отправке кадра конечному узлу тег снимается, так что они понятия не имеют о том, что находятся в каком-либо VLAN’е.

Когда пакет попадает на trunk-порт, он передается как есть, тег не снимается. Таким образом, внутри trunk-порта передаются пакеты с несколькими тегами (PVID).

Стоит заметить, что access-порт можно настроить так, чтобы тег на выходе не снимался, тогда для принятия пакета конечный клиент должен знать, в какой VLAN он подключен. Не все сетевые карты и/или ОС поддерживают работу с VLAN по умолчанию. Как правило, это зависит от драйвера сетевой карты.

Аппаратная виртуализация

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

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

Окно настроек аппаратного гипервизора Xen

Установка пакета инструментов виртуальной машины

После установки на виртуальную машину гостевой операционной системы, первое, что необходимо сделать – это установить пакет инструментов или драйверов вашей виртуальной машины, например: VirtualBox Guest Additions или VMware Tools. Такие пакеты содержат драйвера, которые помогут гостевой операционной системе работать быстрее.

Установить их просто. В VirtualBox, загрузите гостевую операционную систему и выберите УстройстваПодключить образ диска Дополнительной гостевой ОС… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.

В VMware Workstation, выберите меню Виртуальная машинаУстановить паке VMware Tools… После чего запустите установщик, который появится как отдельный диск в папке «Этот компьютер» гостевой операционной системы.

Сводка

Центры регистрации и обработки данных на основе технологии облака могут обеспечивать множество преимуществ, например улучшенную масштабируемость и более эффективное использование ресурсов. Реализация этих потенциальных преимуществ требует применения технологии, посвященной принципиальному решению проблем многоклиентской масштабируемости в динамической среде. Виртуализация сети Hyper-V создана для решения этих проблем и повышения рабочей эффективности центров обработки данных за счет разделения топологий виртуальной и физической сетей. Основываясь на существующем стандарте, HNV работает в современном центре обработки данных и работает с существующей инфраструктурой VXLAN. Клиенты с HNV теперь могут консолидировать свои центры обработки данных в частном облаке или легко расширять свои центры обработки данных до среды поставщика серверов размещения с гибридным облаком.

1.3.2. Процессные и системные виртуальные машины

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

Процессная виртуальная машина — это виртуальная платформа для выполнения отдельного процесса. Она предназначена для поддержки процесса, создаётся при его активации и «умирает» после его окончания. Системная виртуальная машина – полнофункциональная, постоянно действующая системная среда, служащая для поддержки операционной системы вместе с большим количеством её пользовательских процессов; она обеспечивает «гостевой» операционной системе доступ к виртуальным аппаратным средствам, в том числе к процессору и памяти, устройствам ввода/вывода, а иногда — и к графическому интерфейсу.

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

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

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

Двигаемся дальше

Виртуализация развивается уже в течение приблизительно 50 лет, но только сейчас достаточное
внимание уделяется виртуализации ввода/вывода. Коммерческие процессоры, поддерживающие виртуализацию,
появились только пять лет назад

Так что, в сущности, мы находимся на пороге перехода к платформенной
виртуализации и виртуализации ввода/вывода. И, как один из ключевых элементов архитектур
вычислительных систем будущего, таких как облачные вычисления, виртуализация, безусловно, будет
рассматриваться как интересная технология, которая будет развиваться. Как обычно, Linux находится
на переднем крае поддержки этих новых архитектур и в последних версиях ядра (2.6.27 и выше)
начинает появляться поддержка этих новых технологий виртуализации.

Причины, по которым я не выбрал бы его сейчас

• Отсутствие хороших web-морд. Имеющийся web-интерфейс, несмотря на то, что он позволяет совершать с виртуальными машинами большинство требуемых действий (создание, снимки, удаление, создание виртуальных сетей), и реализован очень качественно, обладает следующими ограничениями:
  • Не позволяет назначать права на виртуальные машины (предоставления доступа разработчиками по списку только к своим машинам)
  • Не позволяет управлять несколькими физическими серверами из одной панели управления
  • Не отображает статистику по загрузке сервера
  • Пишется сторонними разработчиками, не имеющими отношения к VirtualBox, в их свободное время, из-за чего вызывает опасение возможность прекращения его развития
• Более медленная работа при большом количестве запущенных виртуальных машин по сравнению с KVM.
• Оговорка в лицензии

Управление ресурсами контейнера

После создания контейнера его конфигурация хранится в файле . По умолчанию создается контейнер с 64 Мбайт оперативной памяти, 10 Гбайт дискового пространства, 1000 единиц CPU. Пример конфигурационного файла приведен на рис. 10.

Рис. 10. Конфигурационный файл контейнера

Очень важен параметр — если он включен (значение yes), то контейнер будет загружаться при запуске сервера виртуализации.
Единственное, к чему придется привыкнуть, — это неудобные идентификаторы контейнеров. Вывести список доступных контейнеров можно командой

Рис. 11. Команда prlctl list -a

Поле STATUS показывает состояние контейнера или виртуальной машины, IP-ADDR — IP-адрес контейнера, T — это тип объекта, может быть или CT (контейнер), или VM (виртуальная машина), NAME — это имя контейнера/машины, заданное при создании (в нашем случае MyCT). Конечно же, UUID содержит уникальный идентификатор контейнера/машины.

Рассмотрим несколько примеров управления ресурсами контейнера (подробная информация есть в мануале). Начнем с изменения производительности процессора. По умолчанию задается 1000 процессорных единиц (CPU Units). При желании можно повысить производительность процессора и отдать больше процессорных единиц:

Процессорные единицы — немного абстрактное понятие, но Virtuozzo позволяет задавать конкретные значения. Так, в следующем примере контейнер не может расходовать более 25% от физического процессорного времени:

Можно задать частоту процессора контейнера (750 МГц):

Или ограничить количество ядер:

Теперь о памяти. Задать размер оперативки и свопа можно так:

Можно также отредактировать файл конфигурации контейнера (разумеется, при остановленном контейнере):

Изменить размер виртуального диска позволяет команда :

Перед изменением размера нужно остановить контейнер / виртуальную машину, а также удалить любые снапшоты, если они были созданы.
Параметры сети задаются так:

Первая команда определяет имя узла, вторая — его IP-адрес. Процесс настройки контейнера изображен на рис. 12.

Рис. 12. Конфигурирование контейнера 

Open vSwitch

Open vSwitch — программный многоуровневый коммутатор с открытым исходным текстом, предназначенный для работы с гипервизорами. Работает в Linux начиная с версии 2.6.15. Основные возможности коммутатора:

• учет трафика, в том числе проходящего между виртуальными машинами с использованием SPAN/RSPAN, sFlow и Netflow;
• поддержка VLAN (IEEE 802.1q);
• привязка к конкретным физическим интерфейсам и балансировка нагрузки по исходящим MAC-адресам;
• работа на уровне ядра, совместимость с программным мостом Linux Bridge;
• поддерживает OpenFlow для управления логикой коммутации;
• с меньшей производительностью, чем в режиме на уровне ядра, Open vSwitch может работать как обычное приложение.

Open vSwitch используется в составе Xen Server, Xen Cloud Platform, KVM, VirtualBox, QEMU, ProxMox (начиная с 2.3).

В качестве наглядного примера будем виртуализировать сервер Kerio 9.1.4. Итак, чтобы понимать, как сейчас все устроено до переделки. Железный сервер Kerio — второй сервер виртуализации, в котором работает несколько сетевых сервисов организации: клиентские сети net1, net2, net3 и net4, серверная сеть net5. Каждый сегмент сети подключен в отдельный сетевой интерфейс «железного» Kerio.

Схема, которую будем реализовывать
Другие статьи в выпуске:

Xakep #222. Логика подлога

• Содержание выпуска
• Подписка на «Хакер»-60%

Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет bridge-utils и настроен сетевой мост br0. В системе присутствуют некоторые виртуальные машины, подключенные через этот сетевой мост.

Улучшение производительности внутри виртуальной машины

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

Например, производительность системы увеличится если закрыть фоновые программы или те, которые автоматически запускаются при старте системы. На производительность системы влияет необходимость осуществления дефрагментации диска (если виртуальная машина расположена на HDD диске), и так далее.

Приступаем к настройке

Напоминаю, что в одной из предыдущих статей мы рассматривали построение виртуализации на базе Ubuntu/Debian и KVM. Поэтому исходить будем из того, что система установлена и настроена, есть два физических интерфейса, один подключен к виртуальному мосту и есть виртуальные машины, которые им пользуются. Второй интерфейс не сконфигурирован.

Теперь вернемся к нашим VLAN’ам. Чтобы наша идея работала, нам нужно подключить первый физический интерфейс нашей машины к trunk-порту коммутатора, но при этом заблаговременно разделить (а точнее, протегировать) трафик виртуалок по разным VLAN’ам.

Самый простой и примитивный вариант это сделать — создавать виртуальные сетевые карты, каждую настраивать на определенный VLAN и для каждой виртуальной карты поднять отдельный виртуальный сетевой мост, через который и подключать нужную виртуальную машину. Способ рабочий, правда есть несколько недостатков:

1. Очень некрасивый вывод ifconfig.
2. Нет возможности на лету добавить или удалить VLAN. Иначе говоря, для каждого нового VLAN’а нужно добавлять виртуальный интерфейс. Подключать его в VLAN, включать в мост. Останавливать виртуальную машину и подключать сеть через этот мост.
3. Занимает много времени.

Но если у нас виртуальные машины, почему бы не воспользоваться виртуальным коммутатором второго уровня, в который и воткнуть все виртуальные проводки? Это решение гораздо лучше, позволяет более гибко настроить систему. Ну и использовать такой коммутатор, как самый обычный!

Гугление привело к трем наиболее популярным решениям. Одно входит в состав Hyper-V, который платный и не умеет OpenFlow. Второе: MikroTik, с помощью которого можно не только создать виртуальный коммутатор, но и перенести его конфигурацию на железный. Отпугивает только, что он базируется на полноценной операционной системе — RouterOS. А это уже совсем не то. И наконец, встречай — Open vSwitch.

Управление контейнерами

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

После этого сразу вводим команду просмотра состояния и видим, что наш контейнер запущен (статус running) и ему присвоен IP-адрес 192.168.52.101. Попробуем его пропинговать. Результат всех этих действий приведен на рис. 13. Как видишь, контейнер полностью функционирует — он запущен, и к нему идет ping.

Рис. 13. Контейнер запущен

Для остановки и перезапуска контейнера используются команды и соответственно:

Для удаления контейнера его нужно сначала остановить, а потом удалить:

prlctl delete MyCT

Системные требования и ограничения

Системные требования для автономных установок выглядят так:

• платформа x86-64 с аппаратной поддержкой виртуализации Intel VT-x (с «неограниченным гостем»);
• минимум четырехъядерный 64-битный процессор;
• минимум 4 Гбайт оперативной памяти;
• минимум 64 Гбайт на жестком диске, желательно SSD;
• сетевой адаптер Ethernet с подключением к сети и корректным IP-адресом.

Проверить, поддерживает ли твой Intel-процессор «неограниченного гостя», можно с помощью этого сценария. Запусти его так:

Результат должен быть yes.

Системные требования для размещения серверов в Virtuozzo Storage Cluster:

• Virtuozzo 7;
• 1 Гбайт оперативной памяти на каждые 100 Тбайт хранилища;
• 10 Гбайт или более дискового пространства;
• 1 Ethernet-адаптер 1 Гбит/с, статический IP-адрес для каждого адаптера.

Ограничения:

• максимальный объем оперативки (сертифицированный) — 256 Гбайт, теоретический максимум — 64 Тбайт;
• максимальный размер HDD — 16 Тбайт.

vSphere

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

Она предоставляет ряд ключевых компонентов, включая инфраструктурные сервисы (vCompute, vStorage и vNetwork), сервисы приложений, vCenter Server, vSphere Client и т. д.

Функционал VMware vSphere:

• vCenter Server: инструмент централизованного управления, используемый для настройки, предоставления и управления виртуальными IT средами.
• vSphere Clien: vSphere 6.7 имеет финальную версию vSphere Web Client на основе Flash. Новые рабочие процессы в обновленном выпуске vSphere Client включают vSphere Update Manager, библиотеку контента, vSAN, политики хранения, профили хостов, схему топологии VMware vSphere Distributed Switch и лицензирование.
• vSphere SDK: предоставляет интерфейсы для сторонних решений для доступа к vSphere.
• VM File System: кластерная файловая система для VM.
• Virtual SMP: позволяет одной виртуальной машине одновременно использовать несколько физических процессоров.
• vMotion: активная миграция с целостностью транзакций.
• Storage vMotion: обеспечивает миграцию файлов виртуальных машин из одного места в другое без прерывания обслуживания.
• Высокая доступность: в случае сбоя одного сервера виртуальная машина перемещается на другой сервер с резервной емкостью для обеспечения непрерывности бизнес-процессов.
  Планировщик распределенных ресурсов (DRS): автоматически назначает и балансирует вычисления по аппаратным ресурсам, доступным для виртуальных машин.
• Отказоустойчивость: создает копию основной виртуальной машины, чтобы обеспечить ее постоянную доступность.
• Распределенный коммутатор (VDS): охватывает несколько хостов ESXi и позволяет значительно сократить объем работ по обслуживанию сети.

Для получения дополнительной информации о виртуализации серверов с помощью VMware прочтите этот PDF-файл.

Важное предупреждение

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

Если у вас не появилось такого сообщения при первом запуске какого-нибудь эмулятора/виртуальной машины, то это может значить следующее:

• Технология «Intel Virtualization Technology» в БИОСе уже подключена по умолчанию (такое бывает редко);
• Компьютер не поддерживает этот параметр;
• Эмулятор не способен произвести анализ и оповестить пользователя о возможности подключения виртуализации.

Включение виртуализации на процессоре Intel

Воспользовавшись этой пошаговой инструкцией, вы сможете активировать виртуализацию (актуальна только для компьютеров, работающих на процессоре Intel):

Перезагрузите компьютер и войдите в BIOS. Используйте клавиши от F2 до F12 или Delete (точная клавиша зависит от версии).
Теперь вам нужно перейти в пункт «Advanced». Также он может называться «Integrated Peripherals».
В нём нужно перейти в «CPU Configuration».
Там необходимо найти пункт «Intel Virtualization Technology»

Если данного пункта нет, то это значит, что ваш компьютер не поддерживает виртуализацию.
Если он есть, то обратите внимание на значение, которое стоит напротив него. Должно быть «Enable»

Если там другое значение, то выберите данный пункт при помощи клавиш со стрелочками и нажмите Enter. Появится меню, где нужно выбрать корректное значение.
Теперь можно сохранить изменения и выйти из BIOS с помощью пункта «Save & Exit» или клавиши F10.

Включение виртуализации на процессоре AMD

Пошаговая инструкция выглядит в этом случае похожим образом:

Войдите в BIOS.
Перейдите в «Advanced», а оттуда в «CPU Configuration».
Там обратите внимание на пункт «SVM Mode». Если напротив него стоит «Disabled», то вам нужно поставить «Enable» или «Auto»

Значение меняется по аналогии с предыдущей инструкцией.
Сохраните изменения и выйдите из BIOS.

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

XenServer

Основанный на Xen Project Hypervisor, XenServer является платформой виртуализации серверов с открытым исходным кодом для платформ без операционной системы. Он состоит из функций корпоративного уровня, которые помогают предприятиям легко справляться с рабочими нагрузками, комбинированными ОС и сетевыми конфигурациями.

XenServer обеспечивает улучшенную виртуализированную графику с NIVIDA и Intel и позволяет запускать несколько компьютерных операционных систем на одном оборудовании.

Функционал Citrix XenServer:

• Восстановление узла
• Защита хоста от сбоев
• Мультисерверное управление
• Управление динамической памятью
• Интеграция Active Directory
• Администрирование и контроль на основе ролей (RBAC)
• Пулы смешанных ресурсов с маскированием ЦП
• Контроллер распределенного виртуального коммутатора
• Встроенное в память кэширование операций чтения
• Живая миграция виртуальных машин и хранилище XenMotion
• Если вас интересуют подробности, вы можете прочитать этот PDF.

Установка и первоначальная настройка

На самом деле установка Open vSwitch сводится к установке одного пакета:

После установки никаких изменений не происходит, кроме запуска сервиса OVS. Создадим коммутатор:

Посмотрим, что к нему подключено:

Мы видим, что создан коммутатор br1 с подключенным интерфейсом . Если требуется, можно этот порт настроить, например задать ему определенный VLAN или порт как trunk с ограничениями по конкретным VLAN’ам. Далее подключим к нашему коммутатору свободный сетевой интерфейс ОС.

Схема подключения OVS и физического интерфейса

По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все VLAN’ы. Далее можно сделать этот порт транковым для указанных VLAN ID. Или можно оставить как есть, тогда порт будет пропускать все VLAN ID. У нас структура большая, сеть может каждый день меняться, поэтому оставим как есть.

Далее вместо eth0 подключаем к TCP/IP-стеку ОС новый внутренний интерфейс коммутатора br1. Приятная новость: OVS автоматически применяет и сохраняет свою конфигурацию, поэтому ничего особо делать не придется. Интерфейс OVS управляется, как обычный интерфейс операционной системы, а значит, идем в /etc/network/interfaces и делаем необходимые изменения — меняем на , пишем как manual:

И все! Никаких дополнительных настроек bridge, как в случае с мостом.

Подключаем наш интерфейс к порту коммутатора, на котором настройки такие: trunk-порт для всех VLAN, для VLAN ID 1 трафик не тегирован. То есть порт пропускает транком все VLAN ID и трафик без VLAN вообще. Запускаем сеть командой , после этого мы в сети. В некоторых случаях это может не сработать из-за правки файла настроек сети. Тогда можно попробовать запустить интерфейс вот так:

Проверяем пингами доступность.

Посмотрим, что изменилось у нас на виртуальном коммутаторе:

Как видим, в коммутатор подключено уже два интерфейса: физический интерфейс коммутатора eth0 и интерфейс операционной системы br1.

Теперь займемся виртуальными машинами.

Активация Intel VT-x или AMD-V

Intel VT-x и AMD-V – это специальные технологии виртуализации, которые предназначены для обеспечения большей производительности виртуальных машин. Современные процессоры Intel и AMD, как правило обладают такой функцией. Но на некоторых компьютерах она автоматически не активирована. Чтобы её включить, необходимо перейти в BIOS компьютера и активировать её вручную.

AMD-V часто уже активирована на ПК, если поддерживается. А Intel VT-x чаще всего отключена. Поэтому, убедитесь в том, что указанные функции виртуализации уже активированы в BIOS, после чего включите их в виртуальной машине.