Допустим ты молодой, но всё ещё бедный студент, А значит из всех возможных платформ ты имеешь лишь ПК на 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-системы, но и в десятки раз облегчает локальную разработку и тестирование, особенно когда в системе задействовано множество компонентов.

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

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

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

Все современные облачные хостинги работают по такому же принципу, т.е. хостер на хорошем железе поднимает кучу виртуальных серверов, которые мы привыкли называть VPS/VDS, и раздаёт их пользователям, либо автоматизирует этот процесс (привет, DigitalOcean).

KVM (kernel-based virtual machine) это программное обеспечения для Linux, использующее аппаратные средства x86-совместимых процессоров для работы с технологией виртуализации Intel VT/AMD SVM.

Установка KVM

Все махинации по созданию виртуальной машины я буду проводить на ОС Ubuntu 16.04.1 LTS. Чтобы проверить поддерживает ли ваш процессов аппаратную виртуализацию на базе Intel VT/AMD SVM, выполняем:

Grep -E "(vmx|svm)" /proc/cpuinfo

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

Проверить поддержку аппаратной виртуализации в Ubuntu также можно через команду:

В случае успеха, вы увидите что-то вроде этого:

INFO: /dev/kvm exists KVM acceleration can be used

Устанавливаем пакеты для работы с KVM:

Sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Если у вас есть доступ к графической оболочке системы, то можно установить GUI менеджер libvirt:

Sudo apt-get install virt-manager

Пользоваться virt-manager достаточно просто (не сложнее VirtualBox), поэтому в этой заметке речь пойдёт про консольный вариант установки и настройки виртуального сервера.

Установка и настройка виртуального сервера

В консольном варианте установки, настройки и управлением системой, незаменимым инструментом является утилита virsh (надстройка над библиотекой libvirt). У неё большое количество опций и параметров, подробное описание можно получить так:

Man virsh

или вызвать стандартный "help":

Virsh help

Я всегда придерживаюсь следующих правил при работе с виртуальными серверами:

1. Храню iso образы ОС в каталоге /var/lib/libvirt/boot
2. Храню образы виртуальных машин в каталоге /var/lib/libvirt/images
3. Явно задаю каждой новой виртуальной машине свой статичный IP адрес через DHCP сервер гипервизора.

Приступим к установке первой виртуалки (64-битной серверной убунте 16.04 LTS):

Cd /var/lib/libvirt/boot sudo wget http://releases.ubuntu.com/16.04/ubuntu-16.04.1-desktop-amd64.iso

Скачав образ запускаем установку:

Sudo virt-install \ --virt-type=kvm \ --name ubuntu1604\ --ram 1024 \ --vcpus=1 \ --os-variant=ubuntu16.04 \ --hvm \ --cdrom=/var/lib/libvirt/boot/ubuntu-16.04.1-server-amd64.iso \ --network network=default,model=virtio \ --graphics vnc \ --disk path=/var/lib/libvirt/images/ubuntu1604.img,size=20,bus=virtio

Переводя все эти параметры на "человеческий язык", то получается, что мы создаём виртуальную машину с ОС Ubuntu 16.04, 1024 МБ ОЗУ, 1 процессором, стандартной сетевой картой (виртуальная машина будет ходить в интернет как-будто из-за NAT), 20 ГБ HDD.

Стоит обратить внимание на параметр --os-variant , он указывает гипервизору под какую именно ОС следует адаптировать настройки.
Список доступных вариантов ОС можно получить, выполнив команду:

Osinfo-query os

Если такой утилиты нет в вашей системе, то устанавливаем:

Sudo apt-get install libosinfo-bin

После запуска установки, в консоли появится вот такая надпись:

Domain installation still in progress. You can reconnect to the console to complete the installation process.

Это нормальная ситуация, продолжать установку мы будем через VNC.
Смотрим на каком порту он был поднят у нашей виртуалки (в соседнем терминале, например):

Virsh dumpxml ubuntu1604 ... ...

Порт 5900, на локальном адресе 127.0.0.1. Чтобы подключиться к VNC, необходимо использовать Port Forwarding через ssh. Перед тем как это сделать, убедитесь, что tcp forwarding разрешён у демона ssh. Для этого идём в настройки sshd:

Cat /etc/ssh/sshd_config | grep AllowTcpForwarding

Если ничего не нашлось или вы видите:

AllowTcpForwarding no

То правим конфиг на

AllowTcpForwarding yes

и перезагружаем sshd.

Настройка Port forwarding

Выполняем команду на локальной машине:

Ssh -fN -l login -L 127.0.0.1:5900:localhost:5900 server_ip

Здесь мы настроили ssh port forwarding с локального порта 5900 на серверный порт 5900. Теперь уже можно подключиться к VNC, используя любой VNC-клиент. Я предпочитаю UltraVNC из-за простоты и удобства.

После успешного подключения, на экране отобразится стандартное окно приветствия начала установки Ubuntu:

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

Ifconfig

Запоминаем и идём на хост машину. Вытаскиваем mac-адрес "сетевой" карты виртуалки:

Virsh dumpxml ubuntu1604 | grep "mac address"

Запоминаем наш mac адрес:

Редактируем сетевые настройки гипервизора:

Sudo virsh net-edit default

Ищем DHCP, и добавляем вот это:

Должно получиться что-то вроде этого:

Для того, чтобы настройки вступили в силу, необходимо перезагрузить DHCP сервер гипервизора:

Sudo virsh net-destroy default sudo virsh net-start default sudo service libvirt-bin restart

После этого перегружаем виртуальную машину, теперь она всегда будет иметь заданный ей IP адрес - 192.168.122.131.

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

Чтобы подключиться к терминалу виртуальной машины, выполняем:

Ssh 192.168.122.131

Машина готова к бою.

Virsh: список команд

Чтобы посмотреть запущенные виртуальные хосты (все доступные можно получить добавив --all):

Sudo virsh list

Перезагрузить хост можно:

Sudo virsh reboot $VM_NAME

Остановить виртуальную машину:

Sudo virsh stop $VM_NAME

Выполнить halt:

Sudo virsh destroy $VM_NAME

Sudo virsh start $VM_NAME

Отключение:

Sudo virsh shutdown $VM_NAME

Добавить в автозапуск:

Sudo virsh autostart $VM_NAME

Очень часто требуется склонировать систему, чтобы в будущем использовать её как каркас для других виртуальных ОС, для этого используют утилиту virt-clone.

Virt-clone --help

Она клонирует существующую виртуалку и изменяет host-sensitive данные, например, mac address. Пароли, файлы и прочая user-specific информация в клоне остаётся прежней. Если на клонируемой виртуалке IP адрес был прописан вручную, то могут возникнуть проблемы с доступом по SSH на клон из-за конфликта (2 хоста с одинаковым IP).

Помимо установки виртуалки через VNC, также возможен вариант с X11Forwarding через утилиту virt-manager. В Windows, например, для этого можно использовать Xming и PuTTY.

Гипервизоры, виртуализация и облако

Анализ гипервизора KVM

Серия контента:

Об этом цикле статей

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

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

Что нужно знать для начала

Kernel-based Virtual Machine (KVM) – это полное решение платформенно-зависимой виртуализации для Linux на процессорах x86 с расширениями виртуализации (Intel VT или AMD-V). Для гостевых систем доступна также ограниченная поддержка паравиртуализации для Linux и Windows в форме паравиртуального сетевого драйвера.

В настоящее время KVM взаимодействует с ядром через загружаемый модуль ядра. Поддерживаются разнообразные гостевые операционные системы, такие как Linux, BSD, Solaris, Windows, Haiku, ReactOS и AROS Research Operating System. Модифицированная версия KVM (qemu) может работать на Mac OS X.

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

Архитектура KVM показана на рисунке 1.

Рисунок 1. Архитектура KVM

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

Паравиртуализация ― это метод виртуализации, который предоставляет виртуальным машинам программный интерфейс, подобный, но не идентичный базовым аппаратным средствам. Задачей этого модифицированного интерфейса является сокращение времени, затрачиваемого гостевой операционной системой на выполнение операций, которые в виртуальной среде выполнить значительно труднее, чем в невиртуализированной.

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

В архитектуре KVM, виртуальная машина выполняется как обычный Linux-процесс, запланированный стандартным планировщиком Linux. На самом деле каждый виртуальный процессор представляется как обычный Linux-процесс. Это позволяет KVM пользоваться всеми возможностями ядра Linux.

Эмуляцией устройств управляет модифицированная версия qemu, которая обеспечивает эмуляцию BIOS, шины PCI, шины USB, а также стандартный набор устройств, таких как дисковые контроллеры IDE и SCSI, сетевые карты и т.д.

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

Ниже перечислены основные функции KVM.

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

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

Проект SVirt – попытка усилиями сообщества интегрировать функции безопасности Mandatory Access Control (MAC) и виртуализацию на базе Linux (KVM) - основывается на SELinux, чтобы обеспечить инфраструктуру, которая позволит администратору определять политику изоляции виртуальных машин. SVirt призван гарантировать, что ресурсы виртуальных машин не будут доступны ни для каких других процессов (или виртуальных машин); администратор может дополнить эту политику, определив детальные разрешения; например, чтобы группа виртуальных машин совместно использовала одни и те же ресурсы.

Управление памятью

KVM наследует мощные функции управления памятью от Linux. Память виртуальной машины хранится так же, как память любого другого Linux-процесса, и может заменяться, копироваться большими страницами для повышения производительности, обобщаться или сохраняться в файле на диске. Поддержка технологии NUMA (Non-Uniform Memory Access, архитектура памяти для многопроцессорных систем) позволяет виртуальным машинам эффективно обращаться к памяти большого объема.

KVM поддерживает новейшие функции виртуализации памяти от производителей процессоров, в частности, Intel Extended Page Table (EPT) и AMD Rapid Virtualization Indexing (RVI), для минимизации загрузки процессора и достижения высокой пропускной способности.

Обобщение страниц памяти поддерживается с помощью функции ядра Kernel Same-page Merging (KSM). KSM сканирует память каждой виртуальной машины, и если какие-то страницы памяти виртуальных машин идентичны, объединяет их в одну страницу, которая становится общей для этих виртуальных машин и хранится в единственной копии. Если гостевая система пытается изменить эту общую страницу, ей предоставляется собственная копия.

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

KVM может использовать любой носитель, поддерживаемый Linux, для хранения образов виртуальных машин, в том числе локальные диски с интерфейсами IDE, SCSI и SATA, Network Attached Storage (NAS), включая NFS и SAMBA/CIFS, или SAN с поддержкой iSCSI и Fibre Channel. Для улучшения пропускной способности системы хранения данных и резервирования может использоваться многопоточный ввод/вывод.

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

KVM поддерживает образы виртуальных машин в распределенных файловых системах, таких как Global File System (GFS2), так что они могут разделяться несколькими хостами или обобщаться с использованием логических томов. Поддержка тонкой настройки (thin provisioning) образов дисков позволяет оптимизировать использование ресурсов хранения данных, выделяя их не сразу все наперед, а только тогда, когда этого требует виртуальная машина. Собственный формат дисков для KVM ― QCOW2 ― обеспечивает поддержку снимков текущего состояния и обеспечивает несколько уровней таких снимков, а также сжатие и шифрование.

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

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

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

Драйверы устройств

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

Гипервизор KVM использует стандарт VirtIO, разработанный IBM и Red Hat совместно с Linux-сообществом для паравиртуализированных драйверов; это независимый от гипервизора интерфейс для создания драйверов устройств, позволяющий нескольким гипервизорам использовать один и тот же набор драйверов устройств, что улучшает взаимодействие между гостевыми системами.

Драйверы VirtIO входят в современные версии Linux-ядра (наиболее поздняя ― 2.6.25), включены в Red Hat Enterprise Linux 4.8+ и 5.3+, а также доступны для Red Hat Enterprise Linux 3. Red Hat разработала драйверы VirtIO для гостевых ОС Microsoft Windows, оптимизирующие сетевые и дисковые операции ввода/вывода; эти драйверы сертифицированы по программе сертификации Microsoft Windows Hardware Quality Labs (WHQL).

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

KVM унаследовал производительность и масштабируемость Linux, поддерживая виртуальные машины с 16 виртуальными процессорами и 256 ГБ оперативной памяти, а также хост-системы с 256 ядрами и более 1 ТБ ОЗУ. Он может обеспечить:

• производительность в 95-135% по сравнению с "голым железом" в реальных корпоративных приложениях, таких как SAP, Oracle, LAMP и Microsoft Exchange;
• свыше миллиона сообщений в секунду и менее чем 200-мкс задержку в виртуальных машинах, работающих на стандартном сервере;
• максимальные уровни консолидации более чем с 600 виртуальными машинами, выполняющими корпоративные приложения, на одном сервере.

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

Развертывание виртуализации

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

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

Существует несколько менеджеров виртуальных машин. Среди них:

• Univention Virtual Manager;
• qemu/KVM: запускается прямо из командной строки в машине KVM;
• Virsh: минимальная оболочка для управления виртуальными машинами;
• Virtual Machine Manager: иначе - virt-manager, пользовательский интерфейс для управления виртуальными машинами.

Выбор KVM

Доводы "за":

• несмотря на то что KVM - относительно молодой гипервизор, это компактный модуль, который в сочетании с ядром Linux обеспечивает простоту реализации, сохраняя поддержку Linux-тяжеловесов;
• KVM гибок; так как гостевые операционные системы взаимодействуют с гипервизором, интегрированным в ядро Linux, они могут во всех случаях обращаться непосредственно к оборудованию без необходимости изменения виртуализированной операционной системы. Это делает KVM более быстрым решением для виртуальных машин;
• исправления для KVM совместимы с ядром Linux. KVM реализован в самом ядре Linux, что облегчает управление процессами виртуализации.

Доводы "против":

• мощных инструментов для управления сервером и виртуальными машинами KVM не существует;
• KVM нуждается в совершенствовании поддержки виртуальных сетей и виртуальных систем хранения данных, усилении защиты, в улучшении надежности и отказоустойчивости, управления питанием, поддержки HPC/систем реального времени, масштабируемости виртуальных процессоров, совместимости между поставщиками, портативности ВМ, а также в создании экосистемы облачных сервисов.

Сегодня сложно представить мир без компьютеризированных устройств. Лет этак 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 устройства).

В Ubuntu рекомендуется использовать гипервизор (менеджер виртуальных машин) KVM и библиотеку libvirt в качестве инструментария управления им. Libvirt включает в себя набор программного API и пользовательских приложений управления виртуальными машинами (ВМ) virt-manager (графический интерфейс, GUI) или virsh (командная строка, CLI). В качестве альтернативных менеджеров можно использовать convirt (GUI) или convirt2 (WEB интерфейс).

В настоящее время в Ubuntu офицально поддерживается только гипервизор KVM. Этот гипервизор является частью кода ядра операционной системы Linux. В отличие от Xen, KVM не поддерживает паравиртуализацию, то есть, для того, чтобы его использовать, ваш CPU должен подерживать технологии VT. Вы можете проверить, поддерживает ли ваш процессор эту технологию, выполнив команду в терминале:

Если в результате получили сообщение:

INFO: /dev/kvm exists KVM acceleration can be used

значит KVM будет работать без проблем.

Если же на выходе получили сообщение:

Your CPU does not support KVM extensions KVM acceleration can NOT be used

то вы всё равно сможете использовать виртуальную машину, но работать она будет намного медленнее.

Устанавливать в качестве гостевых 64-битные системы

Выделять гостевым системам более 2 Гбайт ОЗУ

Установка

Sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Это установка на сервер без X-ов, т. е. не включает в себя графический интерфейс. Установить его можно командой

Sudo apt-get install virt-manager

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

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

Процедура создания гостевой системы с помощью графического интерфейса достаточно проста.

А вот текстовый режим можно и описать.

qcow2

При создании системы с помощью графического интерфейса в качестве жёсткого диска предлагается либо выбрать уже существующий файл-образ или блочное устройсво, либо создать новый файл с сырыми (RAW) данными. Однако, это далеко не единственный доступный формат файлов. Из всех перечисленных в man qemu-img типов дисков наиболее гибким и современным является qcow2 . Он поддерживает снапшоты, шифрование и сжатие. Его необходимо создавать до того, как создать новую гостевую систему.

Qemu-img create -o preallocation=metadata -f qcow2 qcow2.img 20G

Согласно тому же man qemu-img , предварительное размещение метаданных (-o preallocation=metadata) делает диск изначально немного больше, но обеспечивает лучшую производительность в те моменты, когда образу нужно расти. На самом деле, в данном случае эта опция позволяет избежать неприятного бага. Создаваемый образ изначально занимает меньше мегабайта места и по мере необходимости растёт до указанного размера. Гостевая система сразу должна видеть этот окончательный указанный размер, тем не менее, на этапе установки она может увидеть реальный размер файла. Естественно, устанавливаться на жёсткий диск размером 200 кбайт она откажется. Баг не специфичен для Ubuntu, проявляется ещё в RHEL, как минимум.

Кроме типа образа впоследствии можно будет выбрать способ его подключения - IDE, SCSI или Virtio Disk. От этого выбора будет зависеть производительность дисковой подсистемы. Однозначно правильного ответа нет, выбирать нужно исходя из задачи, которая будет возложена на гостевую систему. Если гостевая система создаётся «на посмотреть», то сойдёт любой способ. Вообще, обычно именно I/O является узким местом виртуальной машины, поэтому при создании высоконагруженной системы к этому вопросу нужно отнестись максимально ответственно.