При выборе тарифа, человек выбирает также и способ виртуализации для сервера. Предлагаем на выбор виртуализации на уровне операционной системы OpenVZ и аппаратную виртуализацию KVM.

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

Сравнение типов виртуализаций

OpenVZ	KVM
ОС из ряда предложенных: Debian, CentOS, Ubuntu	Linux, Windows, FreeBSD, установка собственного дистрибутива
Изменение ресурсов без перезагрузки (жёсткий диск, память, процессор)	Память и процессор изменятся после перезагрузки, жёсткий диск - только после обращения в поддержку (на готовых тарифах память изменить нельзя)
Смена тарифного плана без перезагрузки	Смена тарифного плана . Сервер будет недоступен 1-2 часа.
Мягкие лимиты: максимальная производительность сервера может отклоняться в большую или меньшую сторону	Жёсткие лимиты: каждый сервер получает заявленные ресурсы
Ограничение на запуск высоконагруженных проектов. Запрещено запускать Java-приложения, массовые рассылки и проксировать трафик. TUN/TAP выключен.	Возможность запуска любых проектов (кроме систем распределённых вычислений)

Виртуализация OpenVZ

OpenVZ - виртуализация уровня операционной системы. Технология базируется на ядре ОС Linux и позволяет на одном физическом сервере создавать и запускать изолированные друг от друга копии выбранной операционной системы (Debian, CentOS, Ubuntu). Установка другой ОС невозможна, так как виртуальные серверы используют общее ядро Linux.

Технология отличается легкостью управления сервером: пользователь может в личном кабинете самостоятельно добавить количество ресурсов (память, процессор, жесткий диск) или перейти на другой тариф с той же виртуализацией. Изменения ресурсов применяются автоматически, без перезагрузки сервера.

На серверах с виртуализацией OpenVZ запрещается запускать:

• сервисы для организации проксирования любого вида трафика
• сервисы потокового вещания
• игровые серверы
• системы или элементы систем распределённых вычислений (например, bitcoin mining)
• сервисы массовой рассылки почтовых сообщений, даже если они используются в легальных целях
• Java-приложения
• иные ресурсоёмкие приложения

Такие проекты создают неравномерную нагрузку на родительском сервере и могут мешать соседним виртуальным машинам.

Виртуализация KVM

KVM (Kernel-based Virtual Machine) - технология аппаратной виртуализации, позволяющая создать на хост-машине полный виртуальный аналог физического сервера . KVM позволяет создать полностью изолированный от «соседей» виртуальный сервер с собственным ядром ОС, который пользователь может настраивать и модифицировать под собственные нужды без ограничений. Каждому такому серверу выделяется своя область в оперативной памяти и пространство на жестком диске, что повышает общую надежность работы такого сервера.

Возможна установка любой операционной системы на выбор (Debian, CentOS, Ubuntu, FreeBSD, Windows Server), либо установка собственного дистрибутива (в панели VMmanager в разделе ISO-образы нажмите кнопку Создать и добавьте свой ISO-образ системы).

Смена тарифного плана возможна только в большую сторону и только в рамках базовой линейки тарифов (Старт, Разгон, Отрыв, Улёт). Если ваш проект «вырастет» из тарифа, напишите запрос в поддержку из Личного кабинета - администраторы сменят тариф на требуемый бесплатно. Изменить тариф в меньшую сторону можно только переносом на новый сервер. Закажите новый сервер и перенесите данные самостоятельно, либо специалисты технической поддержки помогут с переносом за 1 обращение по пакету администрирования или 250 руб.

Помните, что на тарифах VDS-Форсаж и VDS-Атлант , вы можете изменять ресурсы вместо смены тарифа : количество доступных ядер процессора и оперативной памяти самостоятельно в панели управления, а размер жёсткого диска - после обращения в поддержку (в рамках администрирования или за 250 руб.).

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

На серверах с виртуализацией KVM Абоненту запрещается размещать системы или элементы систем распределённых вычислений (например, bitcoin mining ).

Смена виртуализации на сервере

В рамках одного сервера сменить виртуализацию с OpenVZ на KVM и обратно невозможно.

1. Закажите второй сервер с нужной виртуализацией в панели BILLmanager, раздел Виртуальные серверы → Заказать

2. Перенесите на него данные.

3. После переноса и проверки старый сервер можно удалить (Виртуальные серверы → Удалить).

А вы задавались вопросом как устроено облако? Самый быстрорастущий ИТ-тренд, в развитие которого инвестируются миллиарды долларов ежегодно, перед тем как стать готовым продуктом или сервисом, который можно использовать, проходит свой технологический процесс производства. Детализировать этот процесс можно до бесконечности, поэтому мы рассмотрим только завершающий этап – виртуализацию, а именно программные продукты, или аппаратные составляющие, с помощью которых и выполняется виртуализация.

Первый материал, из серии «технологии VPS/VDS», посвящен программному продукту KVM (Kernel-based Virtual Machine). Начинаем с него, так как именно этот гипервизор мы используем в облаке Tucha и, конечно же, наше отношение к нему особенное.

Гипервизор KVM: особенности и принцип работы

Технологии виртуализации все чаще стали применяться в современных системах. Виртуальные машины – самый простой способ иметь несколько разных операционных систем с сопутствующей программной средой для выполнения различных задач – тестирования или разработки ПО, организации хостинга с использованием VPS, распространения цифровой продукции, обучения и т.д. Для упрощения управления виртуальными машинами используются гипервизоры - программные решения, которые позволяют быстро запускать, останавливать, развертывать новые виртуальные машины в пределах одного хоста. Одним из наиболее популярных гипервизоров для UNIX-подобных систем является KVM.

Гипервизор KVM: архитектура

KVM (аббревиатура от Kernel-based Virtual Machine) – это программное обеспечение, которое дает возможность реализовать виртуализацию на базе компьютеров под управлением ОС Linux и подобных. С некоторых пор KVM является частью Linux-ядра, потому развивается вместе с ним. Работает только в системах с аппаратной поддержкой виртуализации – на процессорах Intel и AMD.

Для организации работы KVM использует прямой доступ к ядру с помощью процессор-специфичного модуля (kvm-intel или kvm-amd). Кроме того, в состав комплекса входит главное ядро – kvm.ko и элементы UI, в том числе и популярный QEMU. Гипервизор позволяет работать напрямую с файлами виртуальных машин и образами дисков из других программ. Для каждой машины создается изолированное пространство со своей памятью, диском, сетевым доступом, видеокартой и другими устройствами.

Преимущества и недостатки KVM

Как и любое программное решение, KVM имеет как плюсы, так и минусы, исходя из которых, хостеры и конечные потребители принимают решение об использовании этого ПО.

Основные преимущества гипервизора таковы:

• независимо распределяемые ресурсы . Каждая работающая под управлением KVM виртуальная машина получает свой объем оперативной и постоянной памяти и не может «залезть» в другие области, что повышает стабильность работы;
• широкая поддержка гостевых ОС . Кроме полной поддержки UNIX-дистрибутивов, в том числе *BSD, Solaris, Linux, есть возможность устанавливать Windows и даже MacOS;
• взаимодействие с ядром позволяет напрямую обращаться к оборудованию рабочей станции, что делает работу более быстрой ;
• поддержка грандов софтверного рынка (RedHat Linux, HP, Intel, IBM) позволяет проекту быстро развиваться, охватывая все большее количество оборудования и OS, в том числе новейших;
• простое администрирование – возможность удаленного управления через VNC и большое количество стороннего ПО и надстроек.

Без недостатков также не обошлось:

• относительная молодость гипервизора (например, по сравнению с Xen) и соответственно взрывной рост приводят к различным проблемам, особенно при добавлении поддержки нового оборудования и программного окружения;
• сложность настроек, особенно для неискушенного пользователя. Правда, большинство опций можно не менять – они настроены оптимально «из коробки».

Функциональные возможности и свойства гипервизора

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

Безопасность

В KVM каждая машина представляет собой Linux-процесс, потому на нее автоматически распространяются стандартные политики безопасности, а также изоляция от других процессов. Специальные надстройки (такие как SELinux) добавляют и другие элементы безопасности – контроль доступа, шифрование и т.д.

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

Хранение данных

Для хранения образов машин и их данных KVM может использовать любые носители, которые поддерживаются родительной операционной системой – жесткие диски, NAS, съемные накопители, в том числе с многопоточным вводом-выводом для ускорения работы. Кроме того, гипервизор может работать с распределёнными файловыми системами – например, GFS2. Диски для KVM имеют собственный уникальный формат, который поддерживает динамическое создание снимков разного уровня, шифрование и сжатие.

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

Производительность и масштабируемость

Масштабируемость и производительности комплекса благодаря плотной интеграции с Linux, полностью унаследованы от этой ОС. Таким образом, гипервизор поддерживает до 16 процессоров (виртуальных или физических) и до 256 ГБ ОЗУ в каждой виртуальной машине. Это позволяет использовать гипервизор даже в наиболее высоконагруженных системах.

Стабильность

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

Допустим ты молодой, но всё ещё бедный студент, А значит из всех возможных платформ ты имеешь лишь ПК на Windows и PS4. В один прекрасный день ты решаешься взяться за ум и стать программистом, но мудрые люди в интернете сообщили тебе, что нормальным инженером без Linux не стать. Установить Fedora своей основной и единственной системой ты не можешь, потому что Windows всё ещё нужен для игр и вконтактика, а установить Linux второй системой на жёсткий диск тебе мешает страх или отсутствие опыта.

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

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

А, может, ты и вовсе архитектор, который спроектировал новую сложную систему для обработки бизнес аналитики. В систему твою входят такие вещи, как ElasticSearch, Kafka, Spark и много чего ещё, и каждый компонент должен жить отдельно, настраиваться по уму и общаться с другими компонентами. Как хороший инженер, ты понимаешь, что недостаточно просто установить весь этот зоопарк прямо себе на систему. Нужно попробовать развернуть максимально близкое к будущему production окружение, и желательно так, чтобы твои наработки потом бесшовно заработали на production серверах.

И что же делать во всех этих непростых ситуациях? Правильно: использовать виртуализацию.

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

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

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

Подходы к виртуализации

Независимо от подхода и технологии, при использовании виртуализации всегда существует host-машина и установленный на ней гипервизор, управляющий guest-машинами.

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

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

Существует три способа взаимодействия виртуальных машин с железом:

Динамическая трансляция

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

Паравиртуализация

В случае с паравиртуализацией исходный код гостевой ОС специально изменяется так, чтобы все инструкции выполнялись максимально эффективно и безопасно. При этом виртуалка всегда в курсе, что она - виртуалка. Из плюсов - улучшенная производительность. Из минусов - таким образом нельзя виртуализовать, например, MacOS или Windows, или любой другую ОС, к исходникам которой нет доступа. Паравиртуализация в той или иной форме используется, например, в Xen и KVM.

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

Разработчики процессоров вовремя осознали, что архитектура x86 плохо подходит для виртуализации, так как изначально была заточена под одну ОС за раз. Поэтому, уже после того как появились динамическая трансляция от VMWare и паравиртуализация от Xen, Intel и AMD начали выпускать процессоры с аппаратной поддержкой виртуализации.

Особого прироста производительности это поначалу не дало,так как главным фокусом первых релизов было улучшение архитектуры процессоров. Однако, теперь, спустя больше 10 лет после появления Intel VT-x и AMD-V, аппаратная виртуализация ничем не уступает и даже в чём-то превосходит другие решения.

Аппаратную виртуализацию использует и требует KVM (Kernel-based Virtual Machine), которую мы и будем использовать в дальнейшем.

Kernel-based Virtual Machine

KVM - это решение для виртуализации, встроенное прямо в ядро Linux, не уступающее остальным решениям в функциональности и превосходящее их в удобстве использования. Более того, KVM - open source технология, которую, тем не менее, на всех парах двигает вперёд (как в плане написания кода, так и в плане маркетинга) и внедряет в свои продукты Red Hat.

Это, кстати, одна из многих причин, почему мы настаиваем на Red Hat дистрибутивах.

Создатели KVM изначально сфокусировались на поддержке аппаратной виртуализации и не стали переизобретать многие вещи. Гипервизор, по сути, это маленькая операционная система, которая должна уметь работать с памятью, с сетью и т.п. Linux уже отлично умеет всё это делать, поэтому использование ядра Linux в качестве гипервизора - логичное и красивое техническое решение. Каждая виртуальная машина KVM -это всего лишь отдельный Linux процесс, безопасность обеспечивается при помощи SELinux/sVirt, ресурсы управляются при помощи CGroups.

Мы ещё поговорим о SELinux и CGroups в другой статье, не пугайся, если не знаешь таких слов.

KVM не просто работает как часть ядра Linux: начиная с версии ядра 2.6.20 KVM является основной составляющей Linux. Иными словами, если у вас стоит Linux, то у вас уже есть KVM. Удобно, правда?

Стоит сказать, что в сфере публичных облачных платформ Xen доминирует чуть больше, чем полностью. Например, AWS EC2 и Rackspace используют именно Xen. Обусловлено это тем, что Xen появился раньше всех и первый достиг достаточного уровня производительности. Но есть и хорошие новости: в ноябре 2017 , который постепенно заменит Xen для крупнейшего облачного провайдера.

Несмотря на то, что KVM использует аппаратную виртуализацию, для некоторых драйверов I/O устройств KVM может использовать паравиртуализацию, что обеспечивает прирост производительности для определённых сценариев использования.

libvirt

Мы уже почти дошли до практической части статьи, осталось только рассмотреть ещё один open source инструмент: libvirt.

libvirt - это набор инструментов, предоставляющий единый API к множеству различных технологий виртуализации. Используя libvirt вам впринципе без разницы, что там за “бакенд”: Xen, KVM, VirtualBox или что-то ещё. Более того, можно использовать libvirt внутри Ruby (а ещё Python, C++ и много чего ещё) программ. Ещё можно удалённо по защищённым каналам подключаться к виртуальным машинам.

Разработкой libvirt, кстати, занимается Red Hat. Ты уже установил себе Fedora Workstation основной системой?

Создадим виртуалку

libvirt - это просто API, а вот как с ним взаимодействовать решать пользователю. Вариантов куча . Мы воспользуемся несколькими стандартными утилитами. Напоминаем: мы настаиваем на использовании Red Hat дистрибутивов (CentOS, Fedora, RHEL) и команды ниже были протестированы именно на одной из этих систем. Для других дистрибутивов Linux возможны небольшие отличия.

Сначала проверим, поддерживается ли аппаратная виртуализация. На самом деле, работать будет и без её поддержки, только гораздо медленнее.

egrep --color = auto "vmx|svm|0xc0f" /proc/cpuinfo # если не выведется ничего, значит поддержки нет:(

Так как KVM то модуль ядра Linux, то нужно проверить, загружен ли он уже, и если нет, то загрузить.

lsmod | grep kvm # kvm, kvm_intel, kvm_amd. Если ничего не выводит, значит, нужно загрузить нужные модули # Если модуль не загружен modprobe kvm modprobe kvm_intel # или modprobe kvm_amd

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

Теперь установим необходимые пакеты. Проще всего сделать это, установив сразу группу пакетов:

yum group list "Virtual*"

Список групп зависит от используемой ОС. У меня группа называлась Virtualization . Для управления виртуальными машинами из командой строки используется утилита virsh . Проверь, есть ли у тебя хотя бы одна виртуалка командой virsh list . Скорее всего нет.

Если не нравится командная строка, то ещё есть virt-manager - весьма удобный GUI для виртуалок.

virsh умеет создавать виртуалки только из XML файлов, формат которых можно изучить в документации libvirt . К счастью, ещё есть virt-manager и команда virt-install . С GUI ты и сам разберёшься, а вот пример использования virt-install:

sudo virt-install --name mkdev-vm-0 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --memory = 1024 --vcpus = 1 \ --disk size = 8

Вместо указания размера диска, можно создать его заранее через virt-manager, или через virsh и XML файл. Я использовал выше образ с Centos 7 minimal, который легко найти на сайте Centos .

Теперь остаётся один важный вопрос: как подсоединиться к созданной машине? Проще всего это сделать через virt-manager - достаточно дважды кликнуть по созданной машине и откроется окно с SPICE соединением. Там тебя ждёт экран установки ОС.

Кстати, KVM умеет nested virtualization: виртуалки внутри виртуалку. We need to go deeper!

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

Но где взять такой файл? Не писать же его с нуля? Разумеется, нет: так как мы уже установили внутри нашей виртуалки Centos 7, то нам нужно просто подсоединиться к ней и найти файл /root/anaconda-ks.cfg - это Kickstart конфиг для того, чтобы создать копию уже созданной ОС. Нужно просто скопировать его и отредактировать содержимое.

Но просто скопировать файл скучно, поэтому мы добавим в него ещё кое-что. Дело в том, что по умолчанию у нас не получится подсоединиться к консоли созданной виртуалки из командой строки host-машины. Чтобы сделать это, нужно отредактировать конфиг загрузчика GRUB. Поэтому в самый конец Kickstart файла добавим следующую секцию:

%post --log = /root/grubby.log /sbin/grubby --update-kernel = ALL --args = "console=ttyS0" %end

%post , как не сложно догадаться, выполнится после установки ОС. Команда grubby обновит конфиг GRUB, добавив возможность подключаться к консоли.

Кстати, ещё можно указать возможность подключения через консоль прямо во время создания виртуалки. Для этого в команду virt-install нужно передать ещё один аргумент: --extra-args="console=ttyS0" . После этого можно устанавливать саму ОС в интерактивном текстовом режиме из терминала твоей host машины, подключившись к виртуалке через virsh console сразу после её создания. Это особенно удобно, когда создаёшь виртуалки на железном удалённом сервере.

Теперь можно применить созданный конфиг! virt-install позволяет при создании виртуалки передавать дополнительные аргументы, в том числе путь к Kickstart файлу.

sudo virt-install --name mkdev-vm-1 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --initrd-inject /path/to/ks.cfg \ --extra-args ks = file:/ks.cfg \ --memory = 1024 --vcpus = 1 --disk size = 8

После того, как вторая виртуалка будет создана (полностью автоматически), ты сможешь подключиться к ней из командой строки командой virsh console vm_id . vm_id можно узнать из списка всех виртуалок командой virsh list .

Одно из преимуществ использования KVM/libvirt - потрясающая документация, в том числе создаваемая компанией Red Hat . Дорогому читателю предлагается с должной любознательностью изучить её.

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

Что дальше?

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

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

Каким бы мощным и богатым на сервисы не был AWS, его основа - это виртуальные машины поверх Xen. Каждый раз, когда ты создаёшь новый дроплет на DigitalOcean , ты создаёшь виртуалку. Практически все сайты, которыми ты пользуешься, размещены на виртуальных машинах. Простота и гибкость виртуалок позволяет не только строить production-системы, но и в десятки раз облегчает локальную разработку и тестирование, особенно когда в системе задействовано множество компонентов.

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

Сегодня сложно представить мир без компьютеризированных устройств. Лет этак 20 назад почти все бытовые приборы были электро-механические, об использовании компьютерных схем повсеместно не было даже и речи. Самые первые компьютеры занимали значительные объемы пространства, и могли относительно не много. Компьютерно-вычислительные комплексы за последнее время прошли достаточно большой путь развития. Хотя, принципиально компьютеры ничем не изменились, но вычислительные мощности стремительно возросли. Наличие компьютера в простой семье теперь не является чем-то особенным.

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

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

Собственно видов виртуализации существует несколько:

• Программная виртуализация;
• Аппаратная виртуализация;
• Виртуализация уровня операционной системы.

Виртуализация в свою очередь бывает полной и частичной .

Программная виртуализация – вид виртуализации, который задействует различные библиотеки ОС, транслируя вызовы виртуальной машины в вызовы ОС. (DOSBox, Virtualbox, VirtualPC)

Аппаратная виртуализация – такой вид, который предусматривает специализированную инструкцию аппаратной части, а конкретно инструкций процессора. Позволяет исполнять запросы в обход гостевой ОС, и исполнять прямо на аппаратном обеспечении. (виртуализация KVM,виртуализация XEN, Parallels, VMware, Virtualbox)

Виртуализация уровня операционной системы – виртуализация только части платформы, без полной виртуализации аппаратной части. Подразумевает работы нескольких экземпляров среды ОС. (Docker, LXC)

Данная статья будет рассматривать Аппаратную виртуализацию, а конкретно виртуализацию KVM.

Схема 1. – Взаимодействие компонентов виртуальной машины с аппаратной частью

Особенности виртуализации для ядра Linux

Для исполнения прямых аппаратных запросов в ОС должна иметься библиотека, которая направляла бы эти запросы аппаратной части напрямую. На платформах базы Linux долгое время никакой встроенной системы виртуализации (встроенного гипервизора), просто не существовало. Каждый производитель ПО для виртуализации, который поддерживало технологию аппаратной виртуализации, вынуждены были создавать собственные модули для ядра Linux (vboxdrv в Virtualbox, vmware-service в VMWare и пр.) Естественно, это не могло продолжаться вечно, и компания Qumranet, Inc, выкупленая затем Radhat создала ассоциацию Open Virtualization Alliance, которая была признана решить проблему отсутствия базового гипервизора для ядра Linux. Так и был создан гипервизор KVM или Kernel-based Virtual Machine.

Реализация

Гипервизор KVM представляет из себя загружаемый модуль ядра Linux, который предназначен для обеспечения виртуализации на платформе Linux x86. Сам модуль содержит компонент собственно виртуализации(kvm.ko), и процессорно-специфический загружаемый модуль kvm-amd.ko либо kvm-intel.ko.

Необходимым условием для использования KVM является поддержка инструкций виртуализации - Intel VT либо AMD , и ядро Linux версии 2.6.20 и выше. Существует также порт KVM под Free-BSD. Для вызова KVM традиционно используется QEMU, но также ведутся попытки добавить поддержку KVM в Virtualbox.

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

KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и других, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другие устройства.

Использование

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

Для наглядности рассматривается виртуализация KVM на базе библиотеку virt-manager.

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

Схема 2. – Взаимодействие компонентов libvirt

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

Существуют кроме того несколько графических оболочек, таких как Gnome-Boxes .

Вывод

Виртуализация – неотъемлемая часть современных корпоративных систем, она позволяет сэкономить колоссальные денежные и энергетические ресурсы. Развитие технологий виртуализации является приоритетным направлением многих организаций. Развиваются такие технологии как как VGAPassthrough (технология "проброса" видеокарты хост-устройства в виртуальную машину) и PCIPassthrough ("проброс" PCI устройства).

Заметка пригодится всем, кому интересно использовать виртуализацию в своей работе. Мое решение вполне может претендовать на промышленное применение и пригодится тем, кто захочет сократить расходы на аппаратную часть при необходимости иметь в наличии разветвленную сетевую инфраструктуру. На подобном варианте базируется некоторые решения от IBM, к примеру. Но эти решения далеко не бюджетные и востребованы лишь в исключительных случаях.
Итак, однажды мне понадобилось в домашних условиях воспроизвести разветвленную сетевую инфраструктуру, состоящую из различных программных платформ. Путь начинался от VMWare Workstation и завершился KVM… Почему именно KVM и как все было, читайте ниже.

1. Немного истории или с чего все началось.
Работая в банке, я вживую столкнулся с виртуализацией. Это была операционная система AIX от IBM, работающая на майнфреймах. С самого начала меня поразила мощь и гибкость подобного подхода. И когда мне понадобилось воспроизвести в тестовых целях дома разветвленную программную инфраструктуру, то сразу базировал все это на принципах виртуализации. Это позволило избежать как значительных затрат на аппаратную часть, так и уместить все весьма компактно в плане пространства.
Для читателя следует учесть, что на самом деле инструментов виртуализации великое множество. Каждый из них имеет свои тонкости и нюансы. Я же ставлю цель рассказать об одном варианте, с которыми работаю лично, описывая по возможности недостатки и особенности остальных.
2. Мой выбор называется KVM (или Kernel-based Virtual Machine).
Подробнее об этом варианте можно почитать .
Но лучше все по порядку излагать. Начну с условий отбора и какие из известных мне вариантов этим условиям неудовлетворяют:
— основная система должна быть бюджетной и мощной.

В аппаратном плане я выбрал вариант AMD Phenom X4 9550 / Asus M3A78 / 2x2Gb DDR-II / 1x160Gb IDE + 2x1Tb SATA-II. Видео здесь совершенно не приципиально, кроме того, что в случае встроенной придется учитывать, что она под себя забирает часть оперативной памяти, соответственно для виртуальных машин ее останется меньше. Скажу сразу — выбор материнки с встроенным RAID-контроллером был не совсем корректным. Как выяснилось, RAID этот работает только в программном режиме, т.е. нужны драйвера для Windows систем, ну а в Linux такого же эффекта можно было достичь гораздо проще, используя стандартные средства.
Использование программной платформы для основной системы было однозначно в пользу GNU/Linux, т.к. позволяло получить среду виртуализации без лишних затрат на лицензирование, а также более облегченную в плане нагрузки (вот никогда я не пойму, почему в Windows Server без графики ничего нельзя поставить и сделать…. бессмысленная нагрузка, ИМХО). Изначально планировалось использовать вариант Ubuntu Server Hardy LTS, но почти сразу была произведена миграция на Debian Lenny (он к тому времени как раз вышел).Ни в коем случае не принижаю достоинства Ubuntu, но субьективно Debian стабильнее и быстрее работает.

— система виртуализации должна быть стабильной, общедоступной и нетребовательной к ресурсам.

От выбора разбегаются глаза, но после изучения отзывов в интернете и попыток использования сложилось субьективное мнение.
Продукты VMWare не подходят. Workstation платная, ESXi не удалось поставить на мою систему из-за неподдерживаемого чипсета (он у меня оказался более современным). Неплохим выбором был бы VMWare Server, но судя по отзывав она тяжеловата и периодически падает, сам я не стал пробовать после неудачи с ESXi. Не подошли они еще по одной причине — компания все таки продает свои продукты и только часть из них доступна в свободном доступе.
VirtualBox оказался весьма удачным вариантом. Существует в двух вариантах — OSE и Freeware. В открытом доступе исходников Freeware-версии нет, зато компенсируется это функциональностью. Из известных мне различий — это отсутствие в OSE версии поддержки USB, ограничения при работе с сетью, неподдерживается графическая акселерация (кстати, дающая весьма приличный прирост скорости работы виртуальной машины). VirtualBox идеально подходит для простейшей реализации, т.к. позволяет быстро получить работоспособную виртуальную машину без лишних телодвижений и внимательного изучения руководства. Приятной особенностью оказалась поддержка работы из консоли, что позволяет не использовать графических надстроек и соответственно снимается дополнительная нагрузка на хост-машину. Для начинающих «домашних виртуализаторов» я бы посоветовал именно такой вариант. Лично я до сих пор его использую на личном ноутбуке для быстрого поднимания тестовой среды, а также для работы в Windows (там уже давно и стабильно обосновалась Ubuntu в качестве основной системы). По субьективным ощущениям работает VirtualBox гораздо шустрее VMWare Workstation, занимает меньше места как на диске, так и в памяти. Для каждой машины выделяется отдельное окно, а также при установленных драйвера в гостевой системе (есть «из коробки») есть возможность интегрировать в рабочий стол хоста, что очень удобно и позволяет разнести задачи на разные виртуальные столы.
QEMU — очень мощная штука. Но когда вспомнил про нее, уже обратил внимание на виртуализацию на базе ядра и информацию про Xen и KVM, потому близко знакомится с чистым QEMU не стал.
Xen — идеальная система для виртуализации. Но имеет весьма существенный недостаток — гостевая система должна быть заранее подготовленна.
KVM, базируется на QEMU, по скорости почти не уступает Xen, зато обладает более гибкой функциональностью, всей мощью настроек QEMU (хотя основная часть необходимых мне была и в VirtualBOX). Оба варианта, Xen и KVM реализованы во всех современных дистрибутивах и для использования не надо прилагать серьезных усилий. Но есть между ними принципиальное отличие, о котором пойдет речь дальше.

— необходимо иметь возможность воспроизвести на виртуальных машинах различные программные платформы.

Несмотря на доступность в этом плане продуктов VMWare и VirtualBOX, от их использования я отказался еще ранее, так что рассматривать не буду… А вот применительно к Xen и KVM опишу чуток подробнее, т.к. сам искал информацию весьма долго.
Xen не позволяет запускать системы отличные от хостовой!!!, а точнее не подготовленные заранее для работы в виртуальной среде. И к сожалению (а может к счастью), подобной обработке не поддаются дистрибутивы Windows. Что меня не устраивало, потому в итоге выбор пал на варианте использования KVM, для которого заранее подготавливать гостевую систему не надо.

Итак причины выбора KVM кратко:

1. Реализация доступна из коробки в любом большом дистрибутиве;
2. Реализовано на базе ядра Linux, соответственно обладает большой скоростью;
3. Используется такими гигантами, как RedHat и Ubuntu, что говорит о высокой стабильности и гибкости;
4. Не требуется дополнительных махинаций с гостевой системой для установки в виртуальную машину.

3. Как я сделал это на Debian.
Дальше пойдет больше техническое описание, описывающее по шагам, как я сделал свой сервер, свободно тянущий с десяток виртуальных серверов.
Несмотря на то, что мой любимый дистрибутив Ubuntu, в итоге под базовую системы был выбран Debian. В рамках статьи объяснять тонкостей не буду, что да как, но на десктопе я все также предпочитаю использовать Ubuntu. Большинство инструкций для Ubuntu и Debian актуальны для обоих вариантов, потому при настройке я использовал и это и то и другое .
Итак, начнем ставить сервер.
Берем дистрибутив Debian. Чтобы не качать лишнего потом и сразу получить свежую систему, я брал вариант netinstall, при помощи которого устанавливал только вариант «Стандартная система», большего нам и не надо. Кстати, я использую 64-битный выпуск, чтобы получить поддержку большего количества оперативной памяти (>3Гб) без обходных путей и выкрутасов (к примеру, 32-битное серверное ядро дистрибутива Ubuntu поддерживает больше, чем 3Гб, но только при наличии такой возможности в чипсете).
Я использую под системные разделы («/», «/home», swap) жесткий диск IDE, дабы не иметь проблем при работе системы при установке на RAID-массив (а они есть). При установке сразу создаю RAID-1 на основе двух жестких дисков SATA для достижения большей сохранности данных (основная информация будет храниться на нем). В дальнейшем для работы с софтовым RAID-массивом следует использовать утилиту mdadm .
Свежеустановленную систему я немного ретуширую. Для начала устанавливаю ssh, чтобы можно было сразу засунуть системник подальше и отключить от него уже ненужный монитор: sudo apt-get install ssh Многие советуют переключить порт с стандартного 22 на другой. Но это следует делать только в том случае, если вы уверены в своих действиях и ваш сервер подключен напрямую к интернету. Кстати, следует упомянуть, что если будет использоватся нестандартный порт, то потом возникнут сложности с удаленным управлением KVM-виртуализацией. Поэтому я оставил стандартный порт, но через аппаратный маршрутизатор сделал переброску на нестандартный, доступный снаружи.

Затем включаем синхронизацию времени через интернет (настоятельно советую, пригодится).
sudo apt-get install ntp ntpdate
Для контроля температуры чипсетов, процессора и жестких дисков:
sudo apt-get install lm-sensors hddtemp
Утилита hddtemp работает сразу, для настройки lm-sensors запускаем после установки: sudo sensors-detect отвечаем на все вопросы утвердительно.
Использовать очень просто:
— узнать температуру процессора, чипсета и других характеристик sudo sensors получаем что-то вроде:

it8712-isa-0290
Adapter: ISA adapter
VCore 1: +1.33 V (min = +3.54 V, max = +3.30 V) ALARM
VCore 2: +3.76 V (min = +1.39 V, max = +1.01 V) ALARM
+3.3V: +3.28 V (min = +4.00 V, max = +0.91 V) ALARM
+5V: +6.69 V (min = +3.04 V, max = +6.10 V) ALARM
+12V: +12.67 V (min = +15.23 V, max = +5.57 V) ALARM
-12V: -15.33 V (min = -0.85 V, max = -12.39 V) ALARM
-5V: +2.85 V (min = +3.06 V, max = +3.47 V) ALARM
Stdby: +5.99 V (min = +0.11 V, max = +6.37 V)
VBat: +3.31 V
fan1: 2922 RPM (min = 3260 RPM, div = 2)
fan2: 0 RPM (min = 5400 RPM, div = 2) ALARM
fan3: 0 RPM (min = 2732 RPM, div = 2) ALARM
M/B Temp: +44.0°C (low = -73.0°C, high = -49.0°C) sensor = transistor
CPU Temp: +32.0°C (low = -65.0°C, high = -9.0°C) sensor = transistor
Temp3: +128.0°C (low = +23.0°C, high = -66.0°C) sensor = disabled
cpu0_vid: +0.000 V

— узнать температуру 1 жесткого диска SATA — sudo hddtemp /dev/sda получаем что-то вроде:

/dev/sda: WDC WD1001FALS-00J7B0: 33°C

Для дальнейшей работы рекомендую обзавестись сторонним DHCP-сервером и на нашем сервере виртуализации настроить bridge-интерфейс.
Установим нужные утилиты: sudo apt-get install bridge-utils
Я использую в качестве DHCP-сервера свой роутер, а bridge-интерфейс создавал по инструкции . По той же инструкции рассказано, как сделать, чтобы виртуальная машина в KVM создавалась по умолчанию с использованием этого способа подключения. Для ускорения перезагрузки (совершенно не критичная ситуация, если сервер будет включен круглосуточно) советую заранее указать статический адрес на интерфейс даже при условии доступности DHCP.

И самое вкусное, устанавливаем KVM модули и полезные утилиты. Сразу добавим текущего пользователя в соответствующую группу для доступности использования KVM. Описание использования утилит можно найти по уже указанным руководствам. sudo aptitude install kvm libvirt-bin virtinst virt-top python-virtinst
sudo adduser softovick libvirt Фактически сразу можно использовать. Описывать все команды смысла не вижу, для этого есть man. Но покажу, как я создаю виртуальную машину:
для Linux virt-install -n linux -r 512 -f linux.img -s 15 -c образ.iso --accelerate --vnc --vncport=5900 --noautoconsole --os-type=linux --os-variant=generic26
для Windows virt-install -n windows -r 512 -f windows.img -s 15 -c образ.iso --accelerate --vnc --vncport=5901 --noautoconsole --os-type=windows --os-variant=win2k3 --noacpi После этого дальнейший ход установки и экран гостевой машины можно контролировать, подключившись при помощи VNC-клиента к серверу по порту 5900 и 5901(рекомендую для каждой машины заранее определять порт VNC, чтобы было удобно подключаться). Есть еще несколько полезных опций, я их не использую лишь потому, что не столкнулся с их необходимостью.

И еще один штрих, но не последний. Как подключить к гостевой системе возможность что-то писать напрямую на физический раздел или папку на рейде, я пока не понял, хотя и старался. Поэтому в случае Linux я подключаюсь к данным на сервере при помощи nfs, а в случае Windows — при помощи Samba. Настройка Samba достаточно тривиальна, устанавливаем sudo aptitude install samba и правим конфигурационный файл /etc/samba/smb.conf под свои задачи. А вот установка и настройка nfs не совсем тривиальна. Я использую такой вариант установки, позволяющий подключаться к нужным папкам с любого ip-адреса локальной сети (вида 192.168.10.*): sudo aptitude install nfs-kernel-server portmap
perl -pi -e "s/^OPTIONS/#OPTIONS/" /etc/default/portmap
echo "portmap: 192.168.10." >> /etc/hosts.allow
/etc/init.d/portmap restart
echo "/media/raid 192.168.10.0/255.255.255.0(rw,no_root_squash,subtree_check)" >> /etc/exports
/etc/init.d/nfs-kernel-server reload
После приведенных действий достаточно на гостевой системе сделать так:
sudo mount сервер:/media/raid локальная_папка
При необходимости можно включить автоматическое монтирование при загрузке, поправив конфигурационный файл /etc/fstab, добавив туда строку типа:
virtual:/media/raid /media/raid nfs defaults 0 2
Ну вот, в целом настройка нашего сервера виртуализации завершена. Управлять им можно как в консоли, так и при помощи графических инструментов virsh или virtual manager .

P.S.:
Некоторые полезные советы:
1. Если вы указали конкретный порт VNC для гостевой машины, то через Virtual Manager вы не сможете автоматически запустить графическую консоль.
2. Virtual Manager не сможет подключиться, если у вас переопределен порт ssh. Точнее для этого придется долго и нудно разбираться.
3. Обязательно используйте для гостевой Windows Server режим —noacpi, чтобы она нормально установилась.
4. Аккуратно настраивайте режим сбережения энергии на гостевых системах, ни в коем случае не отключайте экран, иначе не сможете потом подключится по VNC.
5. Если вы хотите удаленно выключать и перезагружать машины через Virtual Manager, то отключайте хранитель экрана, т.к. он блокирует управление питанием.