Настройка KVM на Ubuntu Server

Инструкция написана на примере Linux Ubuntu Server 18.04.3 LTS. Она подойдет для большинства дистрибутивов на основе Debian.

Проверка поддержки гипервизора

Проверяем, что сервер поддерживает технологии виртуализации:

cat /proc/cpuinfo | egrep «(vmx|svm)»

В ответ должны получить что-то наподобие:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat

В противном случае, заходим в БИОС, находим опцию для включения технологии виртуализации (имеет разные названия, например, Intel Virtualization Technology или Virtualization) и включаем ее — задаем значение Enable.

Также проверить совместимость можно командой:

* если команда вернет ошибку «kvm-ok command not found», установите соответствующий пакет: apt-get install cpu-checker.

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

значит поддержка со стороны аппаратной части есть.

Подготовка сервера

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

* будет создано два каталога: /kvm/vhdd (для виртуальных жестких дисков) и /kvm/iso (для iso-образов).

timedatectl set-timezone Europe/Moscow

* данная команда задает зону в соответствии с московским временем.

apt-get install chrony

systemctl enable chrony

* устанавливаем и запускаем утилиту для синхронизации времени.

Установка и запуск

Устанавливаем KVM и необходимые утилиты управления.

а) Ubuntu после версии 18.10

apt-get install qemu qemu-kvm libvirt-daemon-system virtinst libosinfo-bin

б) Ubuntu до 18.10:

apt-get install qemu-kvm libvirt-bin virtinst libosinfo-bin

* где qemu-kvm — гипервизор; libvirt-bin — библиотека управления гипервизором; virtinst — утилита управления виртуальными машинами; libosinfo-bin — утилита для просмотра списка вариантов операционных систем, которые могут быть в качестве гостевых.

Настроим автоматический запуск сервиса:

systemctl enable libvirtd

Настройка сети

Виртуальные машины могут работать за NAT (в качестве которого выступает сервер KVM) или получать IP-адреса из локальной сети — для этого необходимо настроить сетевой мост. Мы настроим последний.

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

apt-get install bridge-utils

а) настройка сети в старых версиях Ubuntu (/etc/network/interfaces).

Открываем конфигурационный файл для настройки сетевых интерфейсов:

И приведем его к виду:

#iface eth0 inet static
# address 192.168.1.24
# netmask 255.255.255.0
# gateway 192.168.1.1
# dns-nameservers 192.168.1.1 192.168.1.2

auto br0
iface br0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 192.168.1.2
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

* где все, что закомментировано — старые настройки моей сети; br0 — название интерфейса создаваемого моста; eth0 — существующий сетевой интерфейс, через который будет работать мост.

Перезапускаем службу сети:

systemctl restart networking

б) настройка сети в новых версиях Ubuntu (netplan).

* в зависимости от версии системы, конфигурационной файл yaml может иметь другое название.

Приводим его к виду:

network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: false
dhcp6: false
wakeonlan: true

bridges:
br0:
macaddress: 2c:6d:45:c3:55:a7
interfaces:
— eth0
addresses:
— 192.168.1.24/24
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses:
— 192.168.1.2
— 192.168.1.3
parameters:
stp: true
forward-delay: 4
dhcp4: false
dhcp6: false

* в данном примере мы создаем виртуальный бридж-интерфейс br0; в качестве физического интерфейса используем eth0. 2c:6d:45:c3:55:a7 — физический адрес интерфейса, через который мы будем настраивать бридж; 192.168.1.24 — IP-адрес нашего сервера KVM; 192.168.1.1 — адрес шлюза; 192.168.1.2 и 192.168.1.3 — адреса серверов DNS.

Применяем сетевые настройки:

Настаиваем перенаправления сетевого трафика (чтобы виртуальные машины с сетевым интерфейсом NAT могли выходить в интернет):

sysctl -p /etc/sysctl.d/99-sysctl.conf

Создание виртуальной машины

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

virt-install -n VM1 \
—autostart \
—noautoconsole \
—network=bridge:br0 \
—ram 2048 —arch=x86_64 \
—vcpus=2 —cpu host —check-cpu \
—disk path=/kvm/vhdd/VM1-disk1.img,size=16 \
—cdrom /kvm/iso/ubuntu-18.04.3-server-amd64.iso \
—graphics vnc,listen=0.0.0.0,password=vnc_password \
—os-type linux —os-variant=ubuntu18.04 —boot cdrom,hd,menu=on

• VM1 — имя создаваемой машины;
• autostart — разрешить виртуальной машине автоматически запускаться вместе с сервером KVM;
• noautoconsole — не подключается к консоли виртуальной машины;
• network — тип сети. В данном примере мы создаем виртуальную машину с интерфейсом типа «сетевой мост». Для создания внутреннего интерфейса с типом NAT вводим —network=network:default,model=virtio;
• ram — объем оперативной памяти;
• vcpus — количество виртуальных процессоров;
• disk — виртуальный диск: path — путь до диска; size — его объем;
• cdrom — виртуальный привод с образом системы;
• graphics — параметры подключения к виртуальной машины с помощью графической консоли (в данном примере используем vnc); listen — на какой адресе принимает запросы vnc (в нашем примере на всех); password — пароль для подключения при помощи vnc;
• os-variant — гостевая операционная система (весь список мы получали командой osinfo-query os, в данном примере устанавливаем Ubuntu 18.04).

Подключение к виртуальной машине

На компьютер, с которого планируем работать с виртуальными машинами, скачиваем VNC-клиент, например, TightVNC и устанавливаем его.

На сервере вводим:

virsh vncdisplay VM1

команда покажет, на каком порту работает VNC для машины VM1. У меня было:

* :1 значит, что нужно к 5900 прибавить 1 — 5900 + 1 = 5901.

Запускаем TightVNC Viewer, который мы установили и вводим данные для подключения:

Кликаем по Connect. На запрос пароля вводим тот, что указали при создании ВМ, (vnc_password). Мы подключимся к виртуальной машине удаленной консолью.

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

И находим строку:

* в данном примере для доступа к виртуальной машине используется пароль 12345678.

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

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

1. Получить список созданных машин:

2. Включить виртуальную машину:

virsh start VMname

* где VMname — имя созданной машины.

3. Выключить виртуальную машину:

virsh shutdown VMname

4. Включить автозапуск виртуальной машины:

virsh autostart VMname

5. Редактирование конфигурации виртуальной машины:

virsh edit VMname

6. Работа с сетевыми интерфейсами.

Добавить обычный сетевой интерфейс (default или NAT) виртуальной машине:

virsh attach-interface —domain VMname —type network —source default —model virtio —config —live

Добавить интерфейс типа bridge:

virsh attach-interface —domain VMname —type bridge —source br0 —model rtl8139 —config —live

Удалить сетевой интерфейс:

virsh detach-interface VMname —type bridge —mac 52:54:00:2e:a9:4d

* где bridge — тип сетевого интерфейса (также может быть network); 52:54:00:2e:a9:4d — MAC-адрес сетевого адаптера (узнать данный адрес можно в конфигурации виртуальной машины или в самой гостевой операционной системы).

7. Посмотреть IP-адреса, выданные виртуальным машинам автоматически:

virsh net-dhcp-leases default

* где default — виртуальная сеть, создаваемая по умолчанию при установке KVM.

Увеличение размера виртуального диска

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

virsh domblklist VMname

* в данном примере путь до диска — /data/kvm/vhdd/VMname-disk1.img.

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

virsh shutdown VMname

* или завершаем работу в самой операционной системе.

Увеличиваем размер диска:

qemu-img resize /data/kvm/vhdd/VMname-disk1.img +100G

* данной командой мы расширим дисковое пространство виртуального диска /data/kvm/vhdd/VMname-disk1.img на 100 Гигабайт.

Мы должны увидеть:

Получаем информацию о виртуальном диске:

qemu-img info /data/kvm/vhdd/VMname-disk1.img

Запускаем виртуальную машину:

virsh start VMname

Меняем размер блочного устройства:

virsh blockresize UBU /data/kvm/vhdd/VMname-disk1.img 200G

* где 200G — общий размер виртуального диска после расширения.

После необходимо поменять размер диска в самой операционной системе. Пример того, как это можно сделать можно прочитать в инструкции Добавление дискового пространства виртуальной машине в VMware (раздел «Настройка операционной системы»).

Дополнительные средства управления

Virt-Manager

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

Установить на Linux Ubuntu:

apt-get install virt-manager

ubuntu-vm-builder

ubuntu-vm-builder — пакет, разработанный компанией Canonical для упрощения создания новых виртуальных машин.

Виртуализацией по тарифам. Настраиваем Windows в KVM

Содержание статьи

Плюсы и минусы KVM

Проект KVM (Kernel-based Virtual Machine) в этом году празднует десятилетие. Официально он включен в ядро с версии 2.6.20, выложенное на kernel.org 4 февраля 2007 года. Изначально разрабатывался компанией Qumranet, выкупленной Red Hat в 2008 году. После сделки KVM и библиотека управления виртуализацией oVirt стала основой платформы виртуализации RHEV, поэтому Red Hat на сегодня ключевой разработчик KVM.

Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных LXC и OpenVZ, KVM может запускать в принципе любую ОС, не только Linux (Windows, FreeBSD. ), и Linux, отличающийся от конфигурации основной системы. Если нужна виртуальная машина, не совпадающая параметрами с основным хостом, то выбора особо нет. Включение в ядро было большим прорывом. Теперь поддержка виртуализации в ОС не требовала установки гипервизора (как Xen) и могла быть реализована в любом дистрибутиве, включая настольный. Из коробки доступен VNC, дающий возможность управлять виртуальным сервером с момента загрузки (то есть когда еще не работает SSH), как будто из локальной консоли. Проект активно сотрудничает с другим подобным решением QEMU, задействованы некоторые утилиты и общий формат файла образа Qcow2.

Минусы, конечно, тоже есть. Куда же без них. Главный — процессор должен иметь аппаратную поддержку виртуализации Intel VT-x или AMD-V. Проверить их наличие можно вручную или при помощи утилит:

Также о поддержке технологий говорят флаги в CPU:

В зависимости от производителя процессора будет загружен свой модуль ядра (kvm-amd.ko либо kvm-intel.ko).

Проверяем поддержку KVM

Xakep #216. Копаем BitLocker

Накладные расходы чуть выше, чем при использовании LXC и OpenVZ. Причин тому две.

KVM-контейнер запускает свою копию ядра и окружения, и под них требуется память. LXC и OpenVZ же используют ядро и системные вызовы сервера. Поэтому при одинаковых характеристиках на хостинге у них совершенно разные возможности. При создании KVM-контейнера под него сразу резервируются все ресурсы согласно установкам. Это хорошо видно в htop. Стоит добавить ОЗУ в KVM, как сразу на это значение увеличивается объем занятой памяти. Выйти за лимиты VM не может, они устанавливаются жестко. В этом даже и плюс, можно сразу рассчитать будущую нагрузку на своем сервере, а ресурсы никто не позаимствует.

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

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сети контейнеров отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС. В том же OpenVZ это можно сделать на лету. Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту virsh, реализующую все необходимые функции. Но, поискав в Сети, можно найти несколько интерфейсов, хотя для индивидуального использования одной или нескольких VM их обычно ставить нет смысла. К тому же много open source проектов, активно развивавшихся во время большого интереса к виртуальным машинам, сегодня стали коммерческими, хотя некоторые по-прежнему предлагают обрезанную free-версию. В репозитории пакетов есть virt-manager, предлагающий графический интерфейс для управления KVM и другими типами VM, поддерживающими virtlib, как установленных локально, так и удаленно через SSH.

В качестве веб-интерфейсов можно порекомендовать старенький, но еще рабочий WebVirtMgr, бесплатный UVMM UCS Core Edition, openQRM Free Community Edition и другие. Кроме того, существуют специальные дистрибутивы вроде Proxmox VE, в котором все необходимые инструменты для создания и управления VM на базе KVM и LXC уже есть (правда, он подходит для bare metal установки, а не на удаленный VDS).

Установка KVM

Плюсы KVM в том, что она работает из коробки и что процессоры серверов хостеров однозначно поддерживают эту технологию. Поэтому вполне реально при наличии свободных ресурсов подгрузить в VDS еще одну виртуальную машину (или несколько). Конечно, под фактически двойной виртуализацией они будут работать не так быстро, как на железе, но если большая нагрузка не планируется, то этого вполне должно хватить. Более того, у некоторых хостингов есть rescue-инструменты, дающие возможность подмонтировать другую файловую систему (в hetzner это rescue/LARA ), подменить имеющуюся и даже установить свою ОС. При некотором умении можно по тарифам Linux абсолютно легально использовать Windows.

Наша задача — установить под KVM Win и настроить доступ. KVM работает со всеми версиями Win, включая и последние. Но Win капризней к ресурсам, поэтому тариф следует подбирать с учетом минимальных системных требований и накладных расходов на ОС и виртуализацию. На Digital Ocean, например, Win2012R2 при 4 Гбайт ОЗУ сильно тормозит, а если выделить 6+ Гбайт, то уже вполне нормальный отклик. В различных дистрибутивах и даже версиях процесс немного отличается, но в основном это касается названий пакетов. Мы будем использовать Ubuntu 16.06. Ставим пакеты.

Проверяем поддержку KVM.

Если такой ответ получен, значит, все нормально. Список поддерживаемых ОС и их правильное название можно получить при помощи osinfo-query .

Список поддерживаемых ОС и их названия

Конфигурационные файлы libvirt находятся в каталоге /etc/libvirt , журналы, в которых нужно искать ответы на проблемы, размещаются в /var/log/libvirt . В /var/lib/libvirt несколько каталогов: в boot система, если не указан путь, будет искать образ для установки гостевой системы, а в images размещать жесткие диски.

Управление виртуальными машинами из консоли производится при помощи утилиты virsh . Параметров много, их все можно узнать, введя:

Вначале просто стоит пройтись и познакомиться, чтобы понять суть. Список ОС пока пуст:

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

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

И перезагружаем модули:

Еще один момент. Для работы Win потребуются паравиртуальные драйверы virtio, которые реализуют работу основных устройств в виртуальном окружении. Они не обязательны, но их использование позволяет достичь большей производительности и отзывчивости в работе виртуальных окружений. Они должны поддерживаться как хостом, так и гостевой ОС. В ядре Linux драйвер поддерживается с 2.6.25, но модуль по умолчанию не ставится. Если вызов /sbin/lsmod | grep virtio и cat «/boot/config- uname -r » | grep -i virtio ничего не показал, следует установить пакет qemu-guest-agent. Для гостевой ОС ISO-образ доступен на fedoraproject.org.

Далее два варианта. Можно самостоятельно установить операционную систему или взять уже готовый образ с установленной ОС. Первый шаг в общем отличается тем, что нужно подготовить диск, запустить VM и установить ОС стандартным способом. Создадим диск размером 25 Гбайт.

Если в будущем нужно изменить размер диска, то используется команда resize:

Некоторые параметры очевидны, поэтому кратко:

• name — имя, по которому можно обращаться к VM;
• ram и vcpus — количество памяти и vCPU, выделяемых VM;
• disk — имя диска, формат и драйвер;
• cdrom — виртуальный CD-ROM, здесь указан ISO-образ, с которого будет загружаться система;
• network — сетевое подключение, тип и модель (можно использовать virtio, но бывают проблемы, потом можно сменить);
• os-type и os-variant — тип ОС.

Параметр —vnc имеет смысл только на сервере без GUI, при наличии интерфейса KVM сразу откроет окно через SDL. Также можно подключиться локально при помощи virsh:

Удаленно также можно зайти с использованием любого VNC-клиента, при необходимости используя port forwarding (см. ниже).

Коннектимся к Windows, запущенной под KVM

После установки ОС можно приступать к работе. Второй вариант позволяет использовать уже готовый диск с установленной ОС. Его можно скопировать с готовой системы, сконвертировать при помощи qemu-img convert, которая поддерживает форматы дисков практически всех систем виртуализации. Или взять с сайта проекта Cloudbase.

Запуск почти не отличается от предыдущего, убираем, если не нужен, cdrom и добавляем —import .

В дальнейшем можно управлять поведением VM при помощи virsh start|reboot|shutdown|suspend|resume|destroy|undefine|edit|autostart|info и так далее.

Настройки VM хранятся в отдельных XML-файлах в каталоге /etc/libvirt/qemu , имя соответствует параметру —name . Можно их просмотреть, отредактировать при необходимости, скопировать при помощи virsh. Например, нужно изменить настройки сетевого адаптера.

Скопируем настройки в файл.

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

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

Сеть в KVM

Настройка сети — самый важный момент при работе с KVM. По умолчанию используется Usermode или default, когда базовая система работает как маршрутизатор между внешней и гостевой сетью. Гостевая ОС может получать доступ к внешним сетевым сервисам, но не видна из сети. IP выбирается автоматически при помощи DHCP из диапазона 192.168.122.0/24 , интерфейс основной ОС всегда имеет IP 192.168.122.1 . Для доступа к сервисам нужно самостоятельно настроить маршрутизацию. После установки libvirtd должен создать ряд NAT-правил iptables .

Правила iptables после установки KVM

Второй вариант — Bridged, когда интерфейс гостевой ОС привязывается к физическому интерфейсу и VM доступна извне без допнастроек. Этот вариант чуть сложнее в настройках, так как из-за перестроек можно потерять SSH-подключение. Поэтому при отсутствии локальной консоли (Java/веб-аплета у провайдера) пользоваться им нужно только после тщательного тестирования, и мы его рассматривать не будем.

В первом варианте удобнее настроить KVM так, чтобы она назначала гостевой системе один и тот же IP-адрес. Это можно сделать прямо в конфигурационном файле /etc/libvirt/qemu/networks/default.xml или вызвав

Далее добавляем параметр host в секции dhcp :

Редактируем сетевые настройки для виртуального хоста

И так для каждого узла. После чего перезапускаем сеть.

Теперь можем указать маршрут к сервису в основной системе:

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

Изменить эту ситуацию можно несколькими способами: добавив параметр —vnc,listen=0.0.0.0 и при необходимости указав другой порт —vncport 5901 .

Аналогичные настройки есть в сетевых установках хоста.

Чтобы не менять установки для каждой VM, проще изменить это поведение глобально:

Заключение

Ну вот, собственно, мы имеем Windows, запущенную внутри Linux. Конечно, рассматривать KVM для локальной установки, где сильны позиции у VirtualBox и VMware Workstation, не стоит, но при наличии свободных ресурсов на VDS можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.