Тесты

Что такое виртуализация KVM. Введение в основы виртуализации с KVM Настройка виртуальной машины kvm в linux

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

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

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

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

Системные администраторы, работающие вплотную с виртуализацией на предприятии, мастера и виртуозы своего дела, поделились на два лагеря. Одни - приверженцы высокотехнологичной, но безумно дорогой VMware для Windows. Другие - любители open source и бесплатных решений на основе Linux VM. Можно долго перечислять преимущества VMware, но здесь мы остановимся на виртуализации, основанной на Linux VM.

Технологии виртуализации и требования к железу

Сейчас есть две популярные технологии виртуализации: Intel VT и AMD-V. В Intel VT (от Intel Virtualization Technology) реализована виртуализация режима реальной адресации; соответствующая аппаратная виртуализация ввода-вывода называется VT-d. Часто эта технология обозначается аббревиатурой VMX (Virtual Machine eXtension). В AMD создали свои расширения виртуализации и первоначально называли их AMD Secure Virtual Machine (SVM). Когда технология добралась до рынка, она стала называться AMD Virtualization (сокращенно AMD-V).

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

Среди других требований гипервизоров - поддержка аппаратного RAID (1, 5, 10), которая повышает отказоустойчивость гипервизора при выходе жестких дисков из строя. Если поддержки аппаратного RAID нет, то можно использовать программный на крайний случай. Но RAID - это мастхэв!

Решение, описанное в этой статье, несет на себе три виртуальные машины и успешно работает на минимальных требованиях: Core 2 Quad Q6600 / 8 Гбайт DDR2 PC6400 / 2 × 250 Гбайт HDD SATA (хардверный RAID 1).

Установка и настройка гипервизора

Я покажу, как настраивать гипервизор, на примере Debian Linux 9.6.0 - Х64-86. Ты можешь использовать любой дистрибутив Linux, который тебе по душе.

Когда ты определишься с выбором железа и его наконец-то привезут, придет время ставить гипервизор. При установке ОС все делаем, как обычно, за исключением разметки дисков. Неопытные администраторы часто выбирают опцию «Автоматически разбить все дисковое пространство без использования LVM». Тогда все данные будут записаны на один том, что нехорошо по нескольким причинам. Во-первых, если жесткий диск выйдет из строя, ты потеряешь все данные. Во-вторых, изменение файловой системы доставит массу хлопот.

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

Logical Volume Manager

Менеджер логических томов (LVM) - это подсистема, доступная в Linux и OS/2, построенная поверх Device Mapper. Ее задача - представление разных областей с одного жесткого диска или областей с нескольких жестких дисков в виде одного логического тома. LVM создает из физических томов (PV - Phisical Volumes) логическую группу томов (VG - Volumes Group). Она, в свою очередь, состоит из логических томов (LV - Logical Volume).

Сейчас во всех дистрибутивах Linux с ядром 2.6 и выше есть поддержка LVM2. Для использования LVM2 на ОС с ядром 2.4 надо устанавливать патч.

После того как система обнаружила жесткие накопители, запустится менеджер разбивки жестких дисков. Выбираем пункт Guided - use entire disk and set up LVM.

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

Система предложит варианты разметки носителя. Выбираем «Записать все файлы на один раздел» и идем дальше.

После сохранения изменений мы получим одну логическую группу и два тома в ней. Первый - это корневой раздел, а второй - это файл подкачки. Тут многие зададут вопрос: а почему не выбрать разметку вручную и не создать LVM самому?

Я отвечу просто: при создании логической группы VG загрузочный раздел boot не пишется в VG, а создается отдельным разделом с файловой системой ext2. Если этого не учесть, то загрузочный том окажется в логической группе. Это обречет тебя на мучения и страдания при восстановлении загрузочного тома. Именно поэтому загрузочный раздел отправляется на том без LVM.

Переходим к конфигурации логической группы для гипервизора. Выбираем пункт «Конфигурация менеджера логических томов».

Система оповестит о том, что все изменения будут записаны на диск. Соглашаемся.

Создадим новую группу - к примеру, назовем ее vg_sata .

INFO

В серверах используются носители SATA, SSD, SAS, SCSI, NVMe. Хорошим тоном при создании логической группы будет указывать не имя хоста, а тип носителей, которые используются в группе. Советую логическую группу назвать так: vg_sata , vg_ssd , vg_nvme и так далее. Это поможет понять, из каких носителей построена логическая группа.

Создаем наш первый логический том. Это будет том для корневого раздела операционной системы. Выбираем пункт «Создать логический том».

Выбираем группу для нового логического тома. У нас она всего одна.

Присваиваем имя логическому тому. Правильнее всего при назначении имени будет использовать префикс в виде названия логической группы - например, vg_sata_root , vg_ssd_root и так далее.

Указываем объем для нового логического тома. Советую выделить под корень 10 Гбайт, но можно и меньше, благо логический том всегда можно расширить.

По аналогии с примером выше создаем следующие логические тома:

vg_sata_home - 20 Гбайт под каталоги пользователей;
vg_sata_opt - 10 Гбайт для установки прикладного ПО;
vg_sata_var - 10 Гбайт для часто меняющихся данных, к примеру логов системы и других программ;
vg_sata_tmp - 5 Гбайт для временных данных, если объем временных данных велик, можно сделать и больше. В нашем примере этот раздел не создавался за ненадобностью;
vg_sata_swap - равен объему оперативной памяти. Это раздел для свопа, и создаем мы его для подстраховки - на случай, если закончится оперативная память на гипервизоре.

После создания всех томов завершаем работу менеджера.

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

Создаем одноименный раздел под каждый логический том.

Сохраняем и записываем проделанные изменения.

После сохранения изменений разметки диска начнут ставиться базовые компоненты системы, а затем будет предложено выбрать и установить дополнительные компоненты системы. Из всех компонентов нам понадобится ssh-server и стандартные системные утилиты.

После установки будет сформирован и записан на диск загрузчик GRUB. Устанавливаем его на тот физический диск, где сохранен загрузочный раздел, то есть /dev/sda .

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

После перезагрузки системы заходим на гипервизор по SSH. Первым делом под рутом устанавливаем нужные для работы утилиты.

$ sudo apt-get install -y sudo htop screen net-tools dnsutils bind9utils sysstat telnet traceroute tcpdump wget curl gcc rsync

Настраиваем SSH по вкусу. Советую сразу сделать авторизацию по ключам. Перезапускаем и проверяем работоспособность службы.

$ sudo nano /etc/ssh/sshd_config $ sudo systemctl restart sshd; sudo systemctl status sshd

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

$ sudo pvscan $ sudo lvs

Устанавливаем компоненты виртуализации и утилиты для создания сетевого моста на интерфейсе гипервизора.

$ sudo apt-get update; apt-get upgrade -y $ sudo apt install qemu-kvm libvirt-bin libvirt-dev libvirt-daemon-system libvirt-clients virtinst bridge-utils

После установки настраиваем сетевой мост на гипервизоре. Комментируем настройки сетевого интерфейса и задаем новые:

$ sudo nano /etc/network/interfaces

Содержимое будет примерно таким:

Auto br0 iface br0 inet static address 192.168.1.61 netmask 255.255.255.192 gateway 192.168.1.1 broadcast 192.168.0.61 dns-nameserver 127.0.0.1 dns-search сайт bridge_ports enp2s0 bridge_stp off bridge_waitport 0 bridge_fd 0

Добавляем нашего пользователя, под которым будем работать с гипервизором, в группы libvirt и kvm (для RHEL группа называется qemu).

$ sudo gpasswd -a iryzhevtsev kvm $ sudo gpasswd -a iryzhevtsev libvirt

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

$ sudo virsh pool-list $ sudo virsh pool-define-as vg_sata logical --target /dev/vg_sata $ sudo virsh pool-start vg_sata; sudo virsh pool-autostart vg_sata $ sudo virsh pool-list

INFO

Для нормальной работы группы LVM с QEMU-KVM требуется сначала активировать логическую группу через консоль virsh .

Теперь скачиваем дистрибутив для установки на гостевые системы и кладем его в нужную папку.

$ sudo wget https://mirror.yandex.ru/debian-cd/9.5.0/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso $ sudo mv debian-9.5.0-amd64-netinst.iso /var/lib/libvirt/images/; ls -al /var/lib/libvirt/images/

Чтобы подключаться к виртуальным машинам по VNC, отредактируем файл /etc/libvirt/libvirtd.conf:

$ sudo grep "listen_addr = " /etc/libvirt/libvirtd.conf

Раскомментируем и изменим строчку listen_addr = "0.0.0.0" . Сохраняем файл, перезагружаем гипервизор и проверяем, все ли службы запустились и работают.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!

Эту заметку я пишу для того, чтобы продемонстрировать пошаговую установку и настройку виртуальной машины в 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

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

Храню iso образы ОС в каталоге /var/lib/libvirt/boot
Храню образы виртуальных машин в каталоге /var/lib/libvirt/images
Явно задаю каждой новой виртуальной машине свой статичный 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.

Гипервизор KVM

Он дает возможность осуществлять виртуализацию на серверах с операционной системой Linux. Однозначным плюсом является то, что данный гипервизор входит в состав ядра Linux, поэтому он постоянно совершенствуется и обновляется. Использовать его можно только в случае аппаратной виртуализации – с помощью процессоров Intel или Amd. Процессорный модуль KVM дает ему возможность осуществлять доступ непосредственно к ядру. Благодаря этому можно напрямую управлять файлами виртуальных машин и образами дисков. Для каждой ВМ предназначено индивидуальное пространство.

Гипервизор Xen

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

Код этого гипервизора не перегружен лишними функциями. Он оснащен возможностями управления ОЗУ, частотой работы процессора, работы c прямым доступом к памяти, а также таймером. Все остальные функции выполняют подключенные к работе в данный момент ВМ. Перечисленные преимущества делают работу с Xen простой и удобной даже для человека, познания которого не очень глубоки в данной сфере.

Исследование

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

Уточним, что мнения о том, что выбранный нами дистрибутив для ОС – Fedora 20 от Red Hat – лучше подходит для KVM не совсем верны. Мы не рассматриваем борьбу ВМ за ресурсы процессора во время одновременной работы, так как при разной степени конкуренции гипервизоры могут показывать разную производительность. Поэтому мы считаем условия соревнования честными для обеих сторон.

Результаты

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

Первый кандидат – KVM показал производительность в среднем на полтора процента ниже производительности железа. В тесте на 7-ZIP данный гипервизор оказался почти на 3 процента медленнее, а в тесте на PostMark на целых 4 с лишним процента быстрее железа. Результаты Xen оказались хуже, он не превзошел своего конкурента ни в одном из тестов, отстав от железа на 2.5 процента в трех тестах, а в остальных показал себя еще хуже. Самое сильное отклонение выявилось, как и у KVM – в тесте на PostMark, но Xen не обогнал железо, как его конкурент, а отстал практически на 15 процентов. Повторные результаты теста отклонились от предыдущих не более, чем на 2 процента. Более подробно с результатами тестирования вы можете ознакомиться в таблице:

Итог

KVM всегда показывал себя медленнее железа примерно на 2 процента, но не более того. Xen же уступал железу на 2.5-7 процентов в большинстве из тестов. Хорошие результаты KVM в тесте на PostMark могут быть не совсем точными про причине недостаточного количества проведенных тестов. Чтобы принять правильное решение в выборе теста гипервизора, изучите характер нагрузок своего сайта. При необходимости проведите больше тестов для получения более точных результатов.

На днях вышел интересный отчет компании Principled Technologies, специализирующейся, в том числе, на всякого рода тестировании аппаратно-программных сред. В документе " " рассказывается о том, что на одном и том же оборудовании с помощью гипервизора ESXi можно запустить больше виртуальных машин, чем на гипервизоре KVM платформы RHEV.

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

Для тестирования использовался стоечный сервер Lenovo x3650 M5, на котором в виртуальных машинах работала СУБД Microsoft SQL Server 2016 с нагрузкой типа OLTP. В качестве основного показателя производительности использовался OPM (orders per minute), отображающий количественную оценку исполненных транзакций.

Если не использовать техники Memory Overcommit, то результат выполнения на 15 виртуальных машинах одного хоста в числе OPM примерно одинаковый на обоих гипервизорах:

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

Крестиками отмечены машины, которые на RHV просто не запустились, консоль продукта выдала вот такую ошибку:

Несмотря на включение техник оптимизации памяти в Red Hat Virtualization Manager (RHV-M), таких как memory ballooning и kernel shared memory, шестнадцатая виртуальная машина все равно отказывалась запускаться на KVM:

Ну а на vSphere продолжали наращивать число ВМ, пока не уперлись в недостаток ресурсов:

Получилось, что с техниками overcommit на vSphere получилось запустить 24 виртуальных машины, а на RHV - всего 15 штук. По итогу сделали вывод, что на VMware vSphere в 1,6 раза можно запустить больше виртуальных машин:

Не сказать, что это объективное тестирование, но очевидно, что ESXi в данном случае работает лучше KVM с точки зрения всяких оптимизаций памяти и прочих ресурсов ВМ.

Таги: VMware, Red Hat, Performance, RHV, vSphere, ESXi, KVM
Таги: KVM, oVirt, Open Source, Update

Напомним, что RHEV основана на гипервизоре Kernel-based Virtual Machine (KVM) и поддерживает открытую облачную архитектуру OpenStack. Давайте посмотрим, что нового появилось в обновленном RHEV версии 3.4.

Инфраструктура

Сервис настройки SNMP для поддержки сторонних систем мониторинга.
Сохранение настроек облачной инсталляции RHEV для возможности ее восстановления при сбое или для целей тиражирования в других облаках.
Переписаны и улучшены сервисы аутентификации RHEV.
Возможность горячего добавления процессора в ВМ (Hot Plug CPU). Тут нужна поддержка со стороны ОС.
Нерутовые юзеры теперь имеют доступ к логам.
Новый установщик, основанный на TUI (textual user interface).
Поддержка IPv6.
Возможность выбора соединения с консолью ВМ в режиме Native Client или noVNC.
Возможность изменения некоторых настроек запущенной виртуальной машины.
Полная поддержка RHEL 7 в качестве гостевой ОС.
Возможность включения/отключения KSM (Kernel Samepage Merging) на уровне кластера.
Возможность перезагрузки ВМ из RHEVM или консольной командой.

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

Более плотная интеграция с инфраструктурой OpenStack:

Улучшения безопасности и масштабируемости для сетей, развернутых с помощью Neutron .
Поддержка технологии Open vSwitch (расширяемый виртуальный коммутатор) и возможностей SDN -сетей.

Network Labels - метки, которые можно использовать при обращении к устройствам.
Корректный порядок нумерации виртуальных сетевых адаптеров (vNIC).
Поддержка iproute2.
Единая точка конфигурации сетевых настроек множества хостов в указанной сети.

Возможности хранилищ

Смешанные домены хранилищ (mixed storage domains) - возможность одновременного использования дисковых устройств из хранилищ iSCSI, FCP, NFS, Posix и Gluster для организации хранения виртуальных машин.
Multiple Storage Domains - возможность распределить диски одной виртуальной машины по нескольким хранилищам в пределах датацентра.
Возможность указания дисков, которые будут участвовать в создании снапшотов, а также тех, которые не будут.
Улучшен механизм восстановления ВМ из резервной копии - теперь есть возможность указать снапшот состояния, в которое хочется откатиться.
Асинхронное управление задачами Gluster-хранилищ.
Read-Only Disk for Engine - эта функция дает средству управления Red Hat Enterprise Virtualization Manager возможность использовать диски только для чтения.
Доступ по нескольким путям (multipathing) для хранилищ iSCSI.

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

Агенты гостевых ОС (ovirt-guest-agent) для OpenSUSE и Ubuntu.
SPICE Proxy - возможность использовать прокси-серверы для доступа пользователей к своим ВМ (если они, например, находятся за пределами инфраструктурной сети).
SSO (Single Sign-On) Method Control - возможность переключаться между различными механизмами сквозной аутентификации. Пока есть только два варианта: guest agent SSO и без SSO.
Поддержка нескольких версий одного шаблона виртуальной машины.

Улучшения планировщика и средств обеспечения уровня обслуживания

Улучшения планировщика виртуальных машин.
Группы Affinity/Anti-Affinity (правила существования виртуальных машин на хостах - размещать машины вместе или раздельно).
Power-Off Capacity - политика электропитания, позволяющая выключить хост и подготовить его виртуальные машины к миграции в другое место.
Even Virtual Machine Distribution - возможность распределения виртуальных машин по хостам на базе количества ВМ.
High-Availability Virtual Machine Reservation - механизм позволяет гарантировать восстановление виртуальных машин в случае отказа одного или нескольких хост-серверов. Он работает на базе расчета доступной емкости вычислительных ресурсов хостов кластера.

Улучшения интерфейса

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

Скачать Red Hat Enterprise Virtualization 3.4 можно по этой ссылке . Документация доступна .

Таги: Red Hat, RHEV, Update, Linux, KVM

Новая версия ОС RHEL имеет множество новых интересных возможностей, среди которых немало касаются технологий виртуализации. Некоторые основные новые возможности RHEL 7:

Встроенная поддержка упакованных приложений в формате Docker.
Kernel patching utility Technology Preview - патчинг ядра без перезагрузки ОС.
Прямая и непрямая интеграция с Microsoft Active Directory, подробнее описано .
Для разделов boot, root и user data дефолтной файловой системой теперь является XFS.
- Для XFS максимальный размер файловой системы увеличен со 100 ТБ до 500 ТБ.
- Для ext4 этот размер увеличен с 16 ТБ до 50 ТБ.
Улучшенный процесс установки ОС (новый визард).
Возможность управления серверами Linux с использованием Open Linux Management Infrastructure (OpenLMI).
Улучшения файловых систем NFS и GFS2.
Новые возможности технологии виртуализации KVM.
Возможность выполнять RHEL 7 в качестве гостевой OS.
Улучшения NetworkManager и новая утилита командной строки для выполнения сетевых задач NM-CLI.
Поддержка сетевых соединений Ethernet на скорости до 40 Гбит/с.
Поддержка беспроводной технологии WiGig (IEEE 802.11ad) (на скорости до 7 Гбит/с).
Новый механизм Team Driver, который виртуально объединяет сетевые устройства и порты в единый интерфейс на уровне L2.
Новый динамический сервис FirewallD, представляющий собой гибкий сетевой экран, имеющий преимущество перед iptables и поддерживающий несколько трастовых зон (network trust zones).
GNOME 3 в режиме классического рабочего стола.

Более подробно о новых возможностях RHEL 7 рассказано Red Hat.

В плане виртуализации в Red Hat Enterprise Linux 7 появились следующие основные нововведения:

Технологическое превью возможности virtio-blk-data-plane, которая позволяет выполнять команды ввода-вывода QEMU в отдельном оптимизированном потоке.
Появилось технологическое превью технологии PCI Bridge, позволяющей поддерживать более чем 32 PCI-устройства в QEMU.
QEMU Sandboxing - улучшенная изоляция между гостевыми ОС хоста RHEL 7.
Поддержка "горячего" добавления виртуальных процессоров машинам (vCPU Hot Add).
Multiple Queue NICs - каждый vCPU имеет собственные очереди на передачу и получение, что позволяет не задействовать другие vCPU (только для гостевых ОС Linux).
Технология сжатия страниц памяти при горячей миграции (Page Delta Compression) позволяет гипервизору KVM проводить миграцию быстрее.
В KVM появились функции поддержки паравиртуализованных функций ОС Microsoft, например, Memory Management Unit (MMU) и Virtual Interrupt Controller. Это позволяет гостевым ОС Windows работать быстрее (по умолчанию эти функции отключены).
Поддержка технологии EOI Acceleration, основанной на интерфейсе Advanced Programmable Interrupt Controller (APIC) от Intel и AMD.
Технологическое превью поддержки USB 3.0 в гостевых ОС на KVM.
Поддержка гостевых ОС Windows 8, Windows 8.1, Windows Server 2012 и Windows Server 2012 R2 на гипервизоре KVM.
Функции I/O Throttling для гостевых ОС на QEMU.
Поддержка технологий Ballooning и transparent huge pages.
Новое устройство virtio-rng доступно как генератор случайных чисел для гостевых ОС.
Поддержка горячей миграции гостевых ОС с хоста Red Hat Enterprise Linux 6.5 на хост Red Hat Enterprise Linux 7.
Поддержка назначения устройств NVIDIA GRID и Quadro как второго устройства в дополнение к эмулируемому VGA.
Технология Para-Virtualized Ticketlocks, улучшающая производительность, когда виртуальных vCPU больше чем физических на хосте.
Улучшенная обработка ошибок устройств PCIe.
Новый драйвер Virtual Function I/O (VFIO) улучшающий безопасность.
Поддержка технологии Intel VT-d Large Pages, когда используется драйвер VFIO.
Улучшения отдачи точного времени виртуальным машинам на KVM.
Поддержка образов формата QCOW2 version 3.
Улучшенные статистики Live Migration - total time, expected downtime и bandwidth.
Выделенный поток для Live Migration, что позволяет горячей миграции не влиять на производительность гостевых ОС.
Эмуляция процессоров AMD Opteron G5.
Поддержка новых инструкций процессоров Intel для гостевых ОС на KVM.
Поддержка форматов виртуальных дисков VPC и VHDX в режиме "только для чтения".
Новые возможности утилиты libguestfs для работы с виртуальными дисками машин.
Новые драйверы Windows Hardware Quality Labs (WHQL) для гостевых ОС Windows.
Интеграция с VMware vSphere: Open VM Tools, драйверы 3D-графики для OpenGL и X11, а также улучшенный механизм коммуникации между гостевой ОС и гипервизором ESXi.

Release Notes новой версии ОС доступны по этой ссылке . О функциях виртуализации в новом релизе RHEL 7 можно почитать (а - на русском). Исходные коды rpm-пакетов Red Hat Enterprise Linux 7 теперь доступны только через Git-репозиторий .

Таги: Linux, QEMU, KVM, Update, RHEL, Red Hat

Компания Ravello нашла интересный способ использовать вложенную виртуализацию в своем продукте Cloud Application Hypervisor , который позволяет универсализовать развертывание ВМ разных платформ виртуализации в публичных облаках различных сервис провайдеров.

Основным компонентом этой системы является технология HVX - собственный гипервизор (на базе Xen), являющийся частью ОС Linux и запускающий вложенные виртуальные машины без их изменения средствами техник бинарной трансляции. Далее эти машины можно разместить в облаках Amazon EC2, HP Cloud, Rackspace и даже частных облаках, управляемых VMware vCloud Director (поддержка последнего ожидается в скором времени).

Продукт Ravello - это SaaS-сервис, а такие матрешки можно просто загружать на любой из поддерживаемых хостингов, вне зависимости от используемого им гипервизора. Виртуальная сеть между машинами создается через L2-оверлей над существующей L3-инфраструктурой хостера с использованием GRE-подобного протокола (только на базе UDP):

Сама механика предлагаемого сервиса Cloud Application Hypervisor такова:

Пользователь загружает виртуальные машины в облако (поддерживаются машины, созданные на платформах ESXi/KVM/Xen).
С помощью специального GUI или средствами API описывает многомашинные приложения.
Публикует свои ВМ в одном или нескольких поддерживаемых облаках.
Получившаяся конфигурация сохраняется в виде снапшота в облаке Ravello (потом в случае чего ее можно восстановить или выгрузить) - это хранилище может быть создано как на базе облачных хранилищ Amazon S3, CloudFiles, так и на базе собственных блочных хранилищ или NFS-томов.
После этого каждый пользователь может получить многомашинную конфигурацию своего приложения по требованию.

Очевидный вопрос, который возникает первым: что с производительностью? Ну, во-первых, решение Cloud Application Hypervisor рассчитано на команды разработки и тестирования, для которых производительность не является критичным фактором.

А во-вторых, результаты тестов производительности таких вложенных матрешек показывают не такие уж и плохие результаты:

Для тех, кто заинтересовался технологией HVX, есть хорошее обзорное видео на рунглише:

Таги: Rovello, Nested Virtualization, Cloud, HVX, VMware, ESXi, KVM, Xen, VMachines, Amazon, Rackspace

Новая версия открытой платформы виртуализации RHEV 3.0 основана на дистрибутиве Red Ha Enterprise Linux версии 6 и, традиционно, гипервизоре KVM.

Новые возможности Red Hat Enterprise Virtualization 3.0:

Средство управления Red Hat Enterprise Virtualization Manager теперь построен на базе Java, запущенной на платформе JBoss (ранее использовался.NET, и, соответственно, была привязка к Windows, теперь же можно использовать Linux для управляющего сервера).
Портал самообслуживания пользователей, позволяющий им самостоятельно развертывать виртуальные машины, создавать шаблоны и администрировать собственные окружения.
Новый RESTful API, позволяющиий получить доступ ко всем компонентам решения из сторонних приложений.
Расширенный механизм администрирования, предоставляющий возможность гранулированного назначения пермиссий, делегирования полномочий на базе ролей пользователей и иерархическое управление привилегиями.
Поддержка локальных дисков серверов в качестве хранилищ виртуальных машин (но для них не поддерживается Live Migration).
Интегрированный механизм отчетности, позволяющий анализировать исторические данные о производительности и строить прогнозы по развитию виртуальной инфраструктуры.
Оптимизация для WAN-соединений, включая технологии dynamic compression (сжатие картинки) и автоматической настройки эффектов рабочего стола и глубины цветности. Кроме того, новая версия SPICE имеет расширенную поддержку десктопов с гостевыми ОС Linux.
Обновленный гипервизор KVM на основе последнего Red Hat Enterprise Linux 6.1, вышедшего в мае 2011 года.
Поддержка до 160 логических CPU и 2 ТБ памяти для хост-серверов, 64 vCPU и 512 ГБ памяти - для виртуальных машин.
Новые возможности по администрированию больших инсталляций RHEV 3.0.
Поддержка больших страниц памяти (Transparant Huge Pages, 2 МБ вместо 4 КБ) в гостевых ОС, что увеличивает производительность за счет меньшего количества чтений.
Оптимизация компонента vhost-net. Теперь сетевой стек KVM перемещён из пользовательского режима в режим ядра, что существенно увеличивает производительность и уменьшает задержки в сети.
Использование функций библиотеки sVirt, обеспечивающей безопасность гипервизора.
Появился паравиртуализованный контроллер x2paic, который уменьшает overhead на содержание ВМ (особенно эффективен для интенсивных нагрузок).
Технология Async-IO для оптимизации ввода-вывода и повышения производительности.

Скачать финальный релиз Red Hat Enterprise Virtualization 3.0 можно по этой ссылке .

Ну и, напоследок, небольшой видео-обзор Red Hat Enterprise Virtualization Manager 3.0 (RHEV-M):

Таги: Red Hat, Enterprise, Update, KVM, Linux

Молодцы NetApp! Роман, ждем перевода на русский язык)

Таги: Red Hat, KVM, NetApp, Storage, NFS

Продукт ConVirt 2.0 Open Source позволяет управлять гипервизорами Xen и KVM, входящими в бесплатные и коммерческие издания дистрибутивов Linux, развертывать виртуальные серверы из шаблонов, осуществлять мониторинг производительности, автоматизировать задачи администратора и настраивать все аспекты виртуальной инфраструктуры. ConVirt 2.0 поддерживает функции горячей миграции виртуальных машин, "тонкие" виртуальные диски (растущие по мере наполнения данными), контроль ресурсов виртуальных машин (в т.ч. запущенных), обширные функции мониторинга и средства интеллектуального размещения виртуальных машин на хост-серверах (ручная балансировка нагрузки).

ConVirt 2.0 пока существует только в издании Open Source, однако разработчики обещают в скором времени выпустить издание ConVirt 2.0 Enteprise, которое будет отличаться от бесплатного следующими возможностями:

Feature	ConVirt 2.0 Open Source	ConVirt 2.0 Enterprise
Architecture
Multi-platform Support
Agent-less Architecture
Universal Web Access
Datacenter-wide Console
Administration
Start, Stop, Pause, Resume
Maintanence Mode
Snapshot
Change Resource Allocation on a Running VM
Monitoring
Real-time Data
Historical Information
Server Pools
Storage Pools
Alerts and Notifications
Provisioning
Templates-based Provisioning
Template Library
Integrated Virtual Appliance Catalogues
Thin Provisioning
Scheduled Provisioning
Automation
Intelligent Virtual Machine Placement
Live Migration
Host Private Networking
SAN, NAS Storage Support
Advanced Automation
High Availability
Backup and Recovery
VLAN Setup
Storage Automation
Dynamic Resource Allocation
Power Saving Mode
Security
SSH Access
Multi-user Administration
Auditing
Fine Grained Access Control
Integration
Open Repository
Command Line Interface
Programmatic API

Таги: Xen, KVM, Convirt, Citrix, Red Hat, Бесплатно, Open Source,

Компания Convirture, занимавшаяся в 2007 году проектом XenMan, представлявшим собой GUI для управления гипервизором XEN, выпустила недавно релиз бесплатного продукта Convirture ConVirt 1.0, на который изменил свое название XenMan.