виртуализация в процессоре что это
Что такое виртуализация процессора простыми словами и как ее включить?
Привет, на связи Алексей! Слово «виртуальный» сегодня у всех на слуху. У меня до сих пор «виртуальность» ассоциациируется с фильмом «Косильщик лужаек», который вышел в девяностые годы. С тех пор прошло много времени. У нас еще не в ходу виртуальная реальность, слава Богу. Мы пока живем и мыслим в реальном мире. А вот виртуальные компьютеры уже легко может создать любой человек у себя дома. Сделать это позволяет технология виртуализации на процессоре вашего компьютера (или ноутбука).
В сегодняшнем материале сделаю краткий обзор как это работает, и расскажу для чего бывает нужен виртуальный компьютер. Самый простой пример — у вас дома в наличии есть обычный современный настольный ПК. На нем установлена операционная система Windows 7.
Вы решили осваивать Windows 10 или другую операционной систему, например Linux Mint. Раньше было доступно только два варианта. Или поставить новую вместо старой и потом переносить туда данные. Можно установить обе системы на один компьютер и запускать их поочередно. Но это не удобно.
Для того, чтобы на одном компьютере можно было запускать сразу несколько операционных систем одновременно и была реализована технология виртуализации. Проблема эта оказывается не нова, еще в 80 г двадцатого века ее пытались решить на Западе. В домашних условиях Вы, например, можете легко научиться самостоятельно устанавливать и осваивать такие операционные системы, с какими раньше не были знакомы. А потом и научиться использовать их.
Можно тестировать работу программ в разных операционных системах. Можно играть в любимые старые игры, которые не запускаются на новых операционных системах. Что еще дает запуск нескольких операционных систем? Виртуализация была придумана для того, чтобы экономить денежные средства. В крупных организациях стоят дорогие сервера, и вместо того чтобы тратить деньги на на покупку нового «железа» можно на ОДНОМ физическом системном блоке установить к примеру два виртуальных сервера.
Один почтовый, другой DNS. Мы получаем ДВА отдельных сервера. Каждый из этих виртуальных серверов работает изолированно от друг от друга как отдельный компьютер. При этом ресурсы физического компьютера используются на полную мощность (при правильном расчете). Никакого простоя. А если мы под эти задачи купили бы два раздельных сервера, то их ресурсы использовались бы процентов на сорок или даже меньше. А это невыгодно, даже с точки зрения потребления электричества.
Для того, чтобы технология заработала на вашем ПК, нужно чтобы его процессор поддерживал ее. В чем ее суть простыми словами? Обычный процессор работает примерно так. Есть операционная система (любая) и процессор. Часть данных операционной системы обрабатывается процессором на уровне «1«. Другая важная часть команд от операционной системы работает с процессором, например только на уровне «0» и занимает эту область. Вы пытаетесь запустить виртуальную машину, а эта «нулевая» область уже занята реальной операционной системой.
Ничего не получится. Поэтому в процессоре должна быть область «-1«, которая одновременно принимала бы команды от «новой» операционной системы, и не затрагивала бы работу «старой». Нужен процессор, который умеет управлять работой двух операционных систем одновременно.
Что означает виртуализация процессора AMD?
Традиционно считается, что процессоры AMD у нас доступнее и дешевеле, чем INTEL. Это совсем не значит что они хуже. Многие домашние игровые компьютеры управляются процессорами AMD. Есть мнение, что технология виртуализации от AMD тоже проще и эффективнее, чему у Intel.
Виртуализация AMD (AMD—V™) — это набор уникальных интегрированных в чип функций, которые позволяют клиентам на базе процессоров AMD запускать несколько операционных систем и приложений на одной машине. Впервые появилась в 2008 году на процессорах Athlon x64
Что такое виртуализация в процессорах Intel Core i5?
Компания Intel объявила о своих наработках в этом направлении в 2005 году. Технология носит название Intel VT и со времен процессора Pentium4 (672) ее процессоры поддерживают эту функцию. С тех пор функционал непрерывно совершенствуется и добавляются новые возможности. На сайте компании есть краткий перечень достижений:
Что лучше — AMD или Intel — тут я думаю, что обе компании добились примерно одинаковых результатов. Теперь, когда мы познакомились с теорией, перейдем к практике. Для того, чтобы у вас заработало, нужно проверить включена ли у вас эта фукнция в настройках материнской платы.
Все современные процессоры поддерживают функцию. Ее только надо включить на материнской плате. Обычно она выключена и виртуальная машина не запустится. Для начала убеждаемся, что наш процессор поддерживает виртуализацию. Сделать это можно любым приложением, которое умеет собирать данные о вашем «железе» и выдавать ее в виде отчета.
Как проверить включена ли виртуализация на вашем ПК?
Есть утилиты которые проверяют включена ли функция на вашем процессоре, а не только ее наличие. Я пользуюсь CPU-Z, а включение проверяю в BIOS. Запустив програму переходим на вкладку «Процессор»:
У меня процессор Intel и набор инструкций должен быть AVX. На процессорах AMD соответсвенно будет AMD-V. Если у вас в наборе инструкции есть такая запись, значит нужно ее активировать в BIOS.
Включение виртуализации никак не влияет на производительность процессора если вы не запускаете никаких виртуальных машин на компьютере. Однако, если вы будете использовать виртуальную машину, то производительность возрастает.
В UEFI BIOS примерно так включается виртуализация:
На обычных BIOS включать можно так:
Теперь можно устанавливать и настраивать виртуальную машину. Об этом читаем далее.
Виртуализация в процессоре
Привет, друзья! В последнее время, гиганты IT-индустрии, как с расписной торбой, носятся с идеей виртуализации. Мол, это настолько круто, что на любом офисном ПК должна быть виртуализация процессора. Для чего нужна такая технология, как это работает и нужна ли она конкретно вам, расскажу в сегодняшней публикации.
Virtualization Technology
Термин звучит, как название какой-нибудь секретной лаборатории, изобретающей адские машины для порабощения человечества, для дальнейшей интеграции его в Матрицу. В случае с процессором, это гораздо скучнее – всего лишь предоставление части вычислительной мощности, под конкретную задачу или несколько сразу.
Особенность в том, что под них создается специальная среда – своего рода «песочница», процессы в которой никак не могут повлиять на систему в целом, но могут обращаться к процессору напрямую, минуя посредников в виде основной ОС и все сопутствующие службы.
Сегодня, область практического применения, это технологии, развиваются по трем направлениям:
Виртуализация представлений
Терминальный сервер предоставляет свои мощности пользователю, и он же выполняет клиентское приложение, а на устройстве юзера отображаются только результаты расчетов. Это удобно тем, что существенно снижаются требования к программно-аппаратному обеспечению клиента и повышается безопасность.
В качестве терминального оборудования, можно использовать даже бюджетный смартфон. Недостаток в том, что существенно возрастают аппаратные требования к серверам, так как им приходится вести больше вычислений. Самый известный пример такого способа использования этой технологии – браузерные многопользовательские игры.
Виртуализация устройств
Так называется имитация аппаратной части компьютера, со строго заданными параметрами. На такой виртуальный компьютер можно установить собственную ОС и запускать с ее помощью приложения.
Технология широко используется для тестовых целей: перед релизом, программу всегда проверяют на разных устройствах, при необходимости оптимизируя и фикся баги.
Пример использования – эмулятор Андроида: создается отдельное виртуальное устройство с собственной ОС, которое может быть использовано как для развлечений, так и проверки работоспособности приложений.
Виртуализация приложений
Программа запускается в изолированной среде и никак не контактирует с «внешним миром», поэтому не конфликтует и не наносит вреда другим приложениям. Таким же способом можно запустить разные версии одной и той же программы.
Пример использования технологии – безопасные браузеры, которые часто идут в программном пакете как дополнения к многим антивирусам. Даже при посещении вредоносных сайтов, расплодившаяся там зараза не может попасть в операционную систему.
Надо ли вам это
Зачем такая замечательная технология рядовому юзеру, что дает она и дает ли вообще? По большому счету, незачем, и поддержка виртуализации в процессоре домашнего ПК – скорее дань трендам, чем насущная необходимость.
С задачами по виртуализации, которые могут возникнуть, прекрасно справляются и программные средства. Если не поддерживает виртуализацию процессор вашего ПК – не спешите начинать апгрейд. Скорее всего, необходимости в этой технологии у вас не возникает вовсе.
Меж тем, технологии сегодня оказывают поддержку и широко внедряют оба кита, на которых держится производство компьютерных процессоров – Intel и AMD. Естественно, обойдется покупка такого девайса дороже – и не потому, что технически он гораздо сложнее.
Дело в маркетинге – за поддержку виртуализации, некоторые готовы выложить лишние деньги, не понимая толком, что такое им хотят продать.
Как включить виртуализацию
Активировать эту опцию можно в БИОСе (при условии, что она не включена изначально). Как включить: при перезагрузке компьютера нажать кнопку Del или F2 (чаще всего, на некоторых материнских платах кнопка может быть другой) и найти в меню пункт Virtualization Technology.
Где именно искать – зависит от модели и версии BIOS. Следует выбрать опцию Enabled и, сохранив изменения, перезагрузить компьютер.
Вопреки распространенному заблуждению, базовая частота или коэффициент умножения, при этом не увеличивается, компьютер не станет мощнее и не начинают «летать», программы, которые до этого работали с глюками и тормозами – количество гигагерц, в которых измеряется производительность процессора, не возрастает и не образовываются дополнительные ядра.
Разницу можно почувствовать только при запуске гостевой ОС в привычной вам среде. Работать она будет шустро, именно благодаря прямому доступу виртуальной ОС к ресурсам процессора, что и должна обеспечить виртуализация.
Я уже упоминал в этой статье эмуляторы Android. Да, это виртуальные устройства с поддержкой виртуальной же ОС, поэтому для нормальной их работы, поддержка виртуализации таки необходима. В противном случае даже простенькие приложения будут дико тормозить – впрочем, как и сам Андроид, запущенный в среде Виндовс.
Отдельного упоминания эмуляторы заслуживают потому, что в последнее время они стали очень популярны. Несмотря на то, что почти в каждой семье уже есть планшет и несколько смартфонов, в некоторые игры удобнее играть с помощью клавиатуры и мышки – например, в PUBG Mobile.
Впрочем, это касается исключительно олдскульных геймеров. Поколению, выросшему на играх для сенсорных устройств, рубиться в шутеры, таки удобнее на планшетах и смартфонах.
А на этом откланиваюсь и настоятельно рекомендую подписаться на новостную рассылку, чтобы не пропустить очередную интересную и полезную публикацию. Буду весьма признателен, если вы поделитесь этой статьей в социальных сетях.
Зачем же нужна виртуализация?
Слово «виртуализация» в последнее время стало какой-то «модой» в ИТ-среде. Все вендоры железа и ПО, все ИТ-компании в один голос кричат, что виртуализация – это круто, современно, и нужно всем. Но, давайте, вместо того, чтобы идти на поводу у маркетинговых лозунгов (а иногда бывают такими, что сам Геббельс умер бы от зависти), попытаемся посмотреть на это модное слово с точки зрения простых «технарей» и решить, нужно нам это или нет.
Типы виртуализации
Виртуализация приложений – достаточно интересное, и относительно новое направление. Рассказывать здесь подробно о нем я не буду, поскольку это тема для целой отдельной статьи. Коротко говоря, виртуализация приложений позволяет запускать отдельное приложение в своей собственной изолированной среде (иногда называется «песочница», sandbox). Такой способ помогает решить множество проблем. Во-первых – опять же безопасность: приложение, запущенное в изолированной среде – не способно нанести вред ОС и другим приложениям. Во-вторых – все виртуализированные приложения можно обновлять централизованно из одного источника. В-третьих – виртуализация приложений позволяет запускать на одном физическом ПК несколько разных приложений, конфликтующих друг с другом, или даже несколько разных версий одного и того же приложения. Более подробно о виртуализации приложений можно посмотреть, к примеру, в этом вебкасте: www.techdays.ru/videos/1325.html Возможно, однажды я даже напишу статью на эту тему.
И, наконец, перейдем к виртуализации серверов и остановимся на ней подробно.
Виртуализация серверов – это программная имитация с помощью специального ПО аппаратного обеспечения компьютера: процессор, память, жесткий диск, и т.д. Далее, на такой виртуальный компьютер можно установить операционную систему, и она будет на нем работать точно так же, как и на простом, «железном» компьютере. Самое интересное достоинство этой технологии – это возможность запуска нескольких виртуальных компьютеров внутри одного «железного», при этом все виртуальные компьютеры могут работать независимо друг от друга. Для чего это можно применять?
Первое, что приходит в голову – виртуализацию серверов можно использовать в целях обучения и в тестовых целях. К примеру, новые приложения или ОС можно протестировать перед запуском в промышленную эксплуатацию в виртуальной среде, не покупая специально для этого «железо» и не рискуя парализовать работу ИТ-инфраструктуры, если что-то пойдет не так.
Но кроме этого, виртуализация серверов может использоваться и в продакшн-среде. Причин тому много.
Виртуализация позволяет сократить количество серверов благодаря консолидации, то есть там, где раньше требовалось несколько серверов – теперь можно поставить один сервер, и запустить нужное число гостевых ОС в виртуальной среде. Это позволит сэкономить на стоимости приобретения оборудования, а так же снизить энергопотребление, а значит и тепловыделение системы – и, следовательно, можно использовать менее мощные, и, соответственно – более дешевые системы охлаждения. Но у этой медали есть и обратная сторона, и не одна. Дело в том, что при внедрении решений на базе виртуализации, скорее всего придется покупать новые сервера. Дело в том, что виртуальные сервера используют аппаратные ресурсы физического сервера, и, соответственно – понадобятся более мощные процессоры, большие объемы оперативной памяти, а так же более скоростная дисковая подсистема, и, скорее всего – большего объема. Кроме того, некоторые системы виртуализации (в частности – MS Hyper-V) требуют поддержки процессором аппаратных технологий виртуализации (Intel VT или AMD-V) и некоторых других функций процессора. Многие процессоры, которые выпускались до недавнего времени, в частности – все x86_32bit – этим требованиям не удовлетворяют, и поэтому от старых, хотя и вполне рабочих серверов придется отказаться. Однако же, один более мощный сервер скорее всего будет стоить намного дешевле нескольких менее мощных, да и старые сервера, скорее всего давно пора менять из-за морального устаревания.
Есть еще один очень важный момент: виртуализация северов позволяет до предела упростить администрирование инфраструктуры. Главное преимущество, которое оценят все сисадмины – это возможность удаленного доступа к консоли виртуальных серверов на «аппаратном», точнее – «вирутально-аппаратном» уровне, независимо от установленной гостевой ОС и ее состояния. Так, чтобы перезагрузить «зависший» сервер, теперь не нужно бежать в серверную, или покупать дорогостоящее оборудование типа IP-KVM-переключателей, достаточно просто зайти в консоль виртуального сервера и нажать кнопку «Reset». Помимо этого, виртуальные сервера поддерживают технологию моментальных снимков (о ней см. мою предыдущую статью), а так же бэкап и восстановление виртуальных систем намного легче.
Еще одно неоспоримое преимущество – ОС, запущенная внутри виртуальной машины (гостевая ОС) понятия не имеет, какое оборудование установлено на физическом сервере, внутри которого она работает (хост). Поэтому, при замене железа, при апгрейде или даже переезде на новый сервер необходимо обновить драйверы только на ОС самого хоста (хостовой ОС). Гостевые ОС по будут работать как и раньше, поскольку «видят» только виртуальные устройства.
Так же, хочется напомнить, что в виртуальной среде могут действовать особые правила лицензирования ПО (в частности, покупка лицензии на Microsoft Windows Server 2008 Enterprise позволяет использовать бесплатно четыре копии ОС в качестве гостевой, а Microsoft Windows Server 2008 Datacenter вообще разрешает использовать неограниченное число гостевых ОС при условии полного лицензирования по процессорам).
Еще нельзя не упомянуть о технологиях отказоустойчивости. Физические сервера, на которых запускаются виртуальные машины, могут быть объединены в кластер, и в случае отказа одного из серверов – автоматически «переезжать» на другой. Полной отказоустойчивости добиться не всегда возможно (в частности, в MS Hyper-V такой «внезапный переезд» будет выглядеть так же, и иметь такие же возможные последствия, как внезапное обесточивание сервера), но возможные простои сильно сократятся: «переезд» занимает несколько минут, тогда как ремонт или замена самого сервера может занять часы, а то и дни. Если же «переезд» виртуальных машин происходит в штатном режиме, то он может пройти совершенно незаметно для пользователей. Такие технологии у разных вендоров называются по-разному, к примеру у MS она называется «Live Migration», у VMware – Vmotion. Использование таких технологий позволит проводить работы, связанные с выключением сервера (к примеру – замену некоторых аппаратных компонент, или перезагрузку ОС после установки критических обновлений) в рабочее время и не выгоняя пользователей из их любимых приложений. Кроме этого, если инфраструктура построена соответствующим образом – запущенные виртуальные машины могут автоматически перемещаться на менее нагруженные сервера, или же наоборот «разгружать» наиболее загруженные. В инфраструктуре на базе технологий Microsoft для этого используются System Center Virtual Machine Manager и Operations Manager.
В заключение темы по виртуализации серверов — отмечу, что виртуализация не всегда одинаково полезна. В частности, не всегда будет хорошей идеей переносить в виртуальную среду высоконагруженные сервера, а особенно — высоконагруженные по дисковой подсистеме — это «тяжелые» СУБД, Exchange Server, особенно — роль Mailbox Server, и прочие высоконагруженные приложения. А вот сервера с меньшей нагрузкой (контроллеры доменов AD, WSUS, всевозможные System Center * Manager, веб-сервера) виртуализировать можно и даже нужно. Замечу, кстати, что именно с контроллерами доменов — очень желательно, чтобы хотя бы один из контроллеров был «железным», то есть не виртуальным. Нужно это потому, что для корректной работы всей инфраструктуры желательно, чтобы при запуске всех остальных серверов хотя бы один КД уже был доступен в сети.
Резюме
Итак, давайте подведем итоги: какая именно виртуализация когда может пригодиться, и какие у нее есть плюсы и минусы.
Если у вас есть много пользователей, работающих с одинаковым набором ПО, и система сильно распределена территориально – то стоит подумать об использовании виртуализации представлений, сиречь – терминальных службах.
Если у вас существует множество приложений, которые некорректно работают в новой ОС, либо же конфликтуют между собой, или необходимо запускать на одном компьютере несколько версий одной и той же программы – то нужна виртуализация на уровне приложений.
Если же вам нужно освободить место в стойке, снизить энергопотребление систем, избавиться от «серверного зоопарка» — то ваше решение – виртуализация серверов.
Недостатки – в принципе, те же, что и у терминальных решений:
Надеюсь, моя статья окажется для кого-то полезной. Благодарность и конструктивную критику, как всегда, можно высказать в комментариях.
Автоматизация Для Самых Маленьких. Часть 1.1. Основы виртуализации
Предыдущая статья рассматривала архитектуру виртуализированной сети, underlay-overlay, путь пакета между VM и прочее.
Роман Горге вдохновился ею и решил написать обзорный выпуск о виртуализации вообще.
В данной статье мы затронем (или попытаемся затронуть) вопросы: а как собственно происходит виртуализация сетевых функций, как реализован backend основных продуктов, обеспечивающих запуск и управление VM, а также как работает виртуальный свитчинг (OVS и Linux bridge).
Тема виртуализации широка и глубока, объяснить все детали работы гипервизора невозможно (да и не нужно). Мы ограничимся минимальным набором знаний необходимым для понимания работы любого виртуализированного решения, не обязательно Telco.
Содержание
Введение и краткая история виртуализации
История современных технологий виртуализации берет свое начало в 1999 году, когда молодая компания VMware выпустила продукт под названием VMware Workstation. Это был продукт обеспечивающий виртуализацию desktop/client приложений. Виртуализация серверной части пришла несколько позднее в виде продукта ESX Server, который в дальнейшем эволюционировал в ESXi (i означает integrated) — это тот самый продукт, который используется повсеместно как в IT так и в Telco как гипервизор серверных приложений.
На самом деле на сегодняшний момент вся функциональность KVM доступна в QEMU, но это не принципиально, так как бо́льшая часть пользователей виртуализации на Linux не использует напрямую KVM/QEMU, а обращается к ним как минимум через один уровень абстракции, но об этом позже.
Обсуждение что лучше, а что хуже выходит за рамки данной статьи.
Производители железа также должны были сделать свою часть работы, дабы обеспечить приемлемую производительность.
Пожалуй, наиболее важной и самой широко используемой является технология Intel VT (Virtualization Technology) — набор расширений, разработанных Intel для своих x86 процессоров, которые используются для эффективной работы гипервизора (а в некоторых случаях необходимы, так, например, KVM не заработает без включенного VT-x и без него гипервизор вынужден заниматься чисто софтверной эмуляцией, без аппаратного ускорения).
Наиболее известны два из этих расширений — VT-x и VT-d. Первое важно для улучшения производительности CPU при виртуализации, так как обеспечивает аппаратную поддержку некоторых ее функций (с VT-x 99.9% Guest OS кода выполняется прямо на физическом процессоре, делая выходы для эмуляции только в самых необходимых случаях), второе для подключения физических устройств напрямую в виртуальную машину (для проброса виртуальных функций (VF) SRIOV, например, VT-d должен быть включен).
Следующей важной концепцией является отличие полной виртуализации (full virtualization) от пара-виртуализации (para-virtualization).
Полная виртуализация — это хорошо, это позволяет запускать какую угодно операционную систему на каком угодно процессоре, однако, это крайне неэффективно и абсолютно не подходит для высоконагруженных систем.
Пара-виртуализация, если коротко, это когда Guest OS понимает что она запущена в виртуальной среде и кооперируется с гипервизором для достижения большей эффективности. То есть появляется guest-hypervisor интерфейс.
Подавляющее большинство используемых операционных систем сегодня имеют поддержку пара-виртуализации — в Linux kernel это появилось начиная с ядра версии 2.6.20.
Если вы хоть раз писали вопрос в RFP или отвечали на вопрос в RFP «Поддерживается ли в вашем продукте virtio?» Это как раз было о поддержке front-end virtio драйвера.
Типы виртуальных ресурсов — compute, storage, network
Из чего же состоит виртуальная машина?
Выделяют три основных вида виртуальных ресурсов:
Compute
Теоретически QEMU способен эмулировать любой тип процессора и соотвествующие ему флаги и функциональность, на практике используют либо host-model и точечно выключают флаги перед передачей в Guest OS либо берут named-model и точечно включают\выключают флаги.
По умолчанию QEMU будет эмулировать процессор, который будет распознан Guest OS как QEMU Virtual CPU. Это не самый оптимальный тип процессора, особенно если приложение, работающее в виртуальной машине, использует CPU-флаги для своей работы. Подробнее о разных моделях CPU в QEMU.
QEMU/KVM также позволяет контролировать топологию процессора, количество тредов, размер кэша, привязывать vCPU к физическому ядру и много чего еще.
Нужно ли это для виртуальной машины или нет, зависит от типа приложения, работающего в Guest OS. Например, известный факт, что для приложений, выполняющих обработку пакетов с высоким PPS, важно делать CPU pinning, то есть не позволять передавать физический процессор другим виртуальным машинам.
Memory
Далее на очереди оперативная память — RAM. С точки зрения Host OS запущенная с помощью QEMU/KVM виртуальная машина ничем не отличается от любого другого процесса, работающего в user-space операционной системы. Соотвественно и процесс выделения памяти виртуальной машине выполняется теми же вызовами в kernel Host OS, как если бы вы запустили, например, Chrome браузер.
Перед тем как продолжить повествование об оперативной памяти в виртуальных машинах, необходимо сделать отступление и объяснить термин NUMA — Non-Uniform Memory Access.
Архитектура современных физических серверов предполагает наличие двух или более процессоров (CPU) и ассоциированной с ней оперативной памятью (RAM). Такая связка процессор + память называется узел или нода (node). Связь между различными NUMA nodes осуществляется посредством специальной шины — QPI (QuickPath Interconnect)
Выделяют локальную NUMA node — когда процесс, запущенный в операционной системе, использует процессор и оперативную память, находящуюся в одной NUMA node, и удаленную NUMA node — когда процесс, запущенный в операционной системе, использует процессор и оперативную память, находящиеся в разных NUMA nodes, то есть для взаимодействия процессора и памяти требуется передача данных через QPI шину.
С точки зрения виртуальной машины память ей уже выделена на момент ее запуска, однако в реальности это не так, и kernel Host OS выделяет процессу QEMU/KVM новые участки памяти по мере того как приложение в Guest OS запрашивает дополнительную память (хотя тут тоже может быть исключение, если прямо указать QEMU/KVM выделить всю память виртуальной машине непосредственно при запуске).
Память выделяется не байт за байтом, а определенным размером — page. Размер page конфигурируем и теоретически может быть любым, но на практике используется размер 4kB (по умолчанию), 2MB и 1GB. Два последних размера называются HugePages и часто используются для выделения памяти для memory intensive виртуальных машин. Причина использования HugePages в процессе поиска соответствия между виртуальным адресом page и физической памятью в Translation Lookaside Buffer (TLB), который в свою очередь ограничен и хранит информацию только о последних использованных pages. Если информации о нужной page в TLB нет, происходит процесс, называемый TLB miss, и требуется задействовать процессор Host OS для поиска ячейки физической памяти, соответствующей нужной page.
Данный процесс неэффективен и медлителен, поэтому и используется меньшее количество pages бо́льшего размера.
QEMU/KVM также позволяет эмулировать различные NUMA-топологии для Guest OS, брать память для виртуальной машины только из определенной NUMA node Host OS и так далее. Наиболее распространенная практика — брать память для виртуальной машины из NUMA node локальной по отношению к процессорам, выделенным для виртуальной машины. Причина — желание избежать лишней нагрузки на QPI шину, соединяющую CPU sockets физического сервера (само собой, это логично если в вашем сервере 2 и более sockets).
Storage
Виртуальная машина нуждается в persistent storage, однако, как это сделать, если виртуальная машина «живет» в оперативной памяти Host OS? Если вкратце, то любое обращение Guest OS к контроллеру виртуального диска перехватывается QEMU/KVM и трансформируется в запись на физический диск Host OS. Этот метод неэффективен, и поэтому здесь так же как и для сетевых устройств используется virtio-драйвер вместо полной эмуляции IDE или iSCSI-устройства. Подробнее об этом можно почитать здесь. Таким образом виртуальная машина обращается к своему виртуальному диску через virtio-драйвер, а далее QEMU/KVM делает так, чтобы переданная информация записалась на физический диск. Важно понимать, что в Host OS дисковый backend может быть реализован в виде CEPH, NFS или iSCSI-полки.
Наиболее простым способом эмулировать persistent storage является использование файла в какой-либо директории Host OS как дискового пространства виртуальной машины. QEMU/KVM поддерживает множество различных форматов такого рода файлов — raw, vdi, vmdk и прочие. Однако наибольшее распространение получил формат qcow2 (QEMU copy-on-write version 2). В общем случае, qcow2 представляет собой определенным образом структурированный файл без какой-либо операционной системы. Большое количество виртуальных машин распространяется именно в виде qcow2-образов (images) и являются копией системного диска виртуальной машины, упакованной в qcow2-формат. Это имеет ряд преимуществ — qcow2-кодирование занимает гораздо меньше места, чем raw копия диска байт в байт, QEMU/KVM умеет изменять размер qcow2-файла (resizing), а значит имеется возможность изменить размер системного диска виртуальной машины, также поддерживается AES шифрование qcow2 (это имеет смысл, так как образ виртуальной машины может содержать интеллектуальную собственность).
Далее, когда происходит запуск виртуальной машины, QEMU/KVM использует qcow2-файл как системный диск (процесс загрузки виртуальной машины я опускаю здесь, хотя это тоже является интересной задачей), а виртуальная машина имеет возможность считать/записать данные в qcow2-файл через virtio-драйвер. Таким образом и работает процесс снятия образов виртуальных машин, поскольку в любой момент времени qcow2-файл содержит полную копию системного диска виртуальной машины, и образ может быть использован для резервного копирования, переноса на другой хост и прочее.
В общем случае этот qcow2-файл будет определяться в Guest OS как /dev/vda-устройство, и Guest OS произведет разбиение дискового пространства на партиции и установку файловой системы. Аналогично, следующие qcow2-файлы, подключенные QEMU/KVM как /dev/vdX устройства, могут быть использованы как block storage в виртуальной машине для хранения информации (именно так и работает компонент Openstack Cinder).
Network
Последним в нашем списке виртуальных ресурсов идут сетевые карты и устройства ввода/вывода. Виртуальная машина, как и физический хост, нуждается в PCI/PCIe-шине для подключения устройств ввода/вывода. QEMU/KVM способен эмулировать разные типы чипсетов — q35 или i440fx (первый поддерживает — PCIe, второй — legacy PCI ), а также различные PCI-топологии, например, создавать отдельные PCI-шины (PCI expander bus) для NUMA nodes Guest OS.
После создания PCI/PCIe шины необходимо подключить к ней устройство ввода/вывода. В общем случае это может быть что угодно — от сетевой карты до физического GPU. И, конечно же, сетевая карта, как полностью виртуализированная (полностью виртуализированный интерфейс e1000, например), так и пара-виртуализированная (virtio, например) или физическая NIC. Последняя опция используется для data-plane виртуальных машин, где требуется получить line-rate скорости передачи пакетов — маршрутизаторов, файрволов и тд.
Здесь существует два основных подхода — PCI passthrough и SR-IOV. Основное отличие между ними — для PCI-PT используется драйвер только внутри Guest OS, а для SRIOV используется драйвер Host OS (для создания VF — Virtual Functions) и драйвер Guest OS для управления SR-IOV VF. Более подробно об PCI-PT и SRIOV отлично написал Juniper.
Для уточнения стоит отметить что, PCI passthrough и SR-IOV это дополняющие друг друга технологии. SR-IOV это нарезка физической функции на виртуальные функции. Это выполняется на уровне Host OS. При этом Host OS видит виртуальные функции как еще одно PCI/PCIe устройство. Что он дальше с ними делает — не важно.
А PCI-PT это механизм проброса любого Host OS PCI устройства в Guest OS, в том числе виртуальной функции, созданной SR-IOV устройством
Таким образом мы рассмотрели основные виды виртуальных ресурсов и следующим шагом необходимо понять как виртуальная машина общается с внешним миром через сеть.
Виртуальная коммутация
Архитектура OVS на первый взгляд выглядит довольно страшно, но это только на первый взгляд.
Каким же образом сетевое устройство виртуальной машины оказывается в OVS?
Для решения данной задачи нам необходимо каким-то образом связать между собой виртуальный интерфейс, находящийся в user-space операционной системы с datapath OVS, находящимся в kernel.
В операционной системе Linux передача пакетов между kernel и user-space-процессами осуществляется посредством двух специальных интерфейсов. Оба интерфейса использует запись/чтение пакета в/из специальный файл для передачи пакетов из user-space-процесса в kernel и обратно — file descriptor (FD) (это одна из причин низкой производительности виртуальной коммутации, если datapath OVS находится в kernel — каждый пакет требуется записать/прочесть через FD)
Именно поэтому при запущенной виртуальной машине в Host OS можно увидеть созданные TAP-интерфейсы командой ip link или ifconfig — это «ответная» часть virtio, которая «видна» в kernel Host OS. Также стоит обратить внимание, что TAP-интерфейс имеет тот же MAC-адрес что и virtio-интерфейс в виртуальной машине.
TAP-интерфейс может быть добавлен в OVS с помощью команд ovs-vsctl — тогда любой пакет, скоммутированный OVS в TAP-интерфейс, будет передан в виртуальную машину через file descriptor.
Реальный порядок действий при создании виртуальной машины может быть разным, т.е. сначала можно создать OVS bridge, потом указать виртуальной машине создать интерфейс, соединенный с этим OVS, а можно и наоборот.
Теперь, если нам необходимо получить возможность передачи пакетов между двумя и более виртуальными машинами, которые запущены на одном гипервизоре, нам потребуется лишь создать OVS bridge и добавить в него TAP-интерфейсы с помощью команд ovs-vsctl. Какие именно команды для этого нужны легко гуглится.
На гипервизоре может быть несколько OVS bridges, например, так работает Openstack Neutron, или же виртуальные машины могут находиться в разных namespace для реализации multi-tenancy.
А если виртуальные машины находятся в разных OVS bridges?
Для решения данной задачи существует другой инструмент — veth pair. Veth pair может быть представлен как пара сетевых интерфейсов, соединенных кабелем — все то, что «влетает» в один интерфейс, «вылетает» из другого. Veth pair используется для соединения между собой нескольких OVS bridges или Linux bridges. Другой важный момент что части veth pair могут находиться в разных namespace Linux OS, то есть veth pair может быть также использован для связи namespace между собой на сетевом уровне.
Инструменты виртуализации — libvirt, virsh и прочее
В предыдущих главах мы рассматривали теоретические основы виртуализации, в этой главе мы поговорим об инструментах, которые доступны пользователю непосредственно для запуска и изменения виртуальных машин на KVM-гипервизоре.
Остановимся на трех основных компонентах, которые покрывают 90 процентов всевозможных операций с виртуальными машинами:
Конечно, существует множество других утилит и CLI-команд, которые позволяют управлять гипервизором, например, можно напрямую пользоваться командами qemu_system_x86_64 или графическим интерфейсом virt manager, но это скорее исключение. К тому же существующие сегодня Cloud-платформы, Openstack, например, используют как раз libvirt.
libvirt
libvirt — это масштабный open-source проект, который занимается разработкой набора инструментов и драйверов для управления гипервизорами. Он поддерживает не только QEMU/KVM, но и ESXi, LXC и много чего еще.
Основная причина его популярности — структурированный и понятный интерфейс взаимодействия через набор XML-файлов плюс возможность автоматизации через API. Стоит оговориться что libvirt не описывает все возможные функции гипервизора, он лишь предоставляет удобный интерфейс использования полезных, с точки зрения участников проекта, функции гипервизора.
И да, libvirt это де-факто стандарт в мире виртуализации сегодня. Только взгляните на список приложений, которые используют libvirt.
Хорошая новость про libvirt — все нужные пакеты уже предустановлены во всех наиболее часто используемых Host OS — Ubuntu, CentOS и RHEL, поэтому, скорее всего, собирать руками нужные пакеты и компилировать libvirt вам не придется. В худшем случае придется воспользоваться соответствующим пакетным инсталлятором (apt, yum и им подобные).
При первоначальной установке и запуске libvirt по умолчанию создает Linux bridge virbr0 и его минимальную конфигурацию.
Именно поэтому при установке Ubuntu Server, например, вы увидите в выводе команды ifconfig Linux bridge virbr0 — это результат запуска демона libvirtd
Этот Linux bridge не будет подключен ни к одному физическому интерфейсу, однако, может быть использован для связи виртуальных машин внутри одного гипервизора. Libvirt безусловно может быть использован вместе с OVS, однако, для этого пользователь должен самостоятельно создать OVS bridges с помощью соответствующих OVS-команд.
Любой виртуальный ресурс, необходимый для создания виртуальной машины (compute, network, storage) представлен в виде объекта в libvirt. За процесс описания и создания этих объектов отвечает набор различных XML-файлов.
Детально описывать процесс создания виртуальных сетей и виртуальных хранилищ не имеет особого смысла, так как эта прикладная задача хорошо описана в документации libvirt:
Сама виртуальная машина со всеми подключенными PCI-устройствами в терминологии libvirt называется domain. Это тоже объект внутри libvirt, который описывается отдельным XML-файлом.
Этот XML-файл и является, строго говоря, виртуальной машиной со всеми виртуальными ресурсами — оперативная память, процессор, сетевые устройства, диски и прочее. Часто данный XML-файл называют libvirt XML или dump XML.
Вряд ли найдется человек, который понимает все параметры libvirt XML, однако, это и не требуется, когда есть документация.
В общем случае, libvirt XML для Ubuntu Desktop Guest OS будет довольно прост — 40-50 строчек. Поскольку вся оптимизация производительности описывается также в libvirt XML (NUMA-топология, CPU-топологии, CPU pinning и прочее), для сетевых функций libvirt XML может быть очень сложен и содержать несколько сот строк. Любой производитель сетевых устройств, который поставляет свое ПО в виде виртуальных машин, имеет рекомендованные примеры libvirt XML.
virsh CLI
Утилита virsh — «родная» командная строка для управления libvirt. Основное ее предназначение — это управление объектами libvirt, описанными в виде XML-файлов. Типичными примерами являются операции start, stop, define, destroy и так далее. То есть жизненный цикл объектов — life-cycle management.
Описание всех команд и флагов virsh также доступно в документации libvirt.
virt-install
Еще одна утилита, которая используется для взаимодействия с libvirt. Одно из основных преимуществ — можно не разбираться с XML-форматом, а обойтись лишь флагами, доступными в virsh-install. Второй важный момент — море примеров и информации в Сети.
Таким образом какой бы утилитой вы ни пользовались, управлять гипервизором в конечном счете будет именно libvirt, поэтому важно понимать архитектуру и принципы его работы.
Заключение
В данной статье мы рассмотрели минимальный набор теоретических знаний, который необходим для работы с виртуальными машинами. Я намеренно не приводил практических примеров и выводов команд, поскольку таких примеров можно найти сколько угодно в Сети, и я не ставил перед собой задачу написать «step-by-step guide». Если вас заинтересовала какая-то конкретная тема или технология, оставляйте свои комментарии и пишите вопросы.