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

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

KVM (Kernel-based Virtual Machine) средство виртуализации в среде Linux, которое использует аппаратную виртуализацию на базе Intel VT или AMD SVM. С помощью KVM вы можете создавать изолированные виртуальные машины с собственным виртуальным аппаратным обеспечением: сетевыми картами, дисками, видеокартами и другими устройствами. На виртуальные машины можно уставить любую ОС (не только Linux).

Установка KVM в CentOS

При настройке KVM на сервере, нужно начать с проверки вашего процессора. Нужно узнать, поддерживает ли аппаратную виртуализацию CPU, установленный на вашем сервере. Из консоли сервера, выполните команду:

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

Если ваш процессор поддерживает технологию VT-x, у вас должен быть примерно такой вывод:

Если же команда ничего не выдала, но ваш процессор точно поддерживает виртуализацию, проверьте, вохможно данная опция отключена в BIOS сервера. Ищите параметры “Intel Virtualization Technology” или “SVM MODE”.

На моем сервере поддержка данной технологии включена, поэтому можно приступать к установке необходимых компонентов в CentOS через пакетный менеджер yum/dnf:

# yum install libvirt libvirt-python libguestfs-tools qemu-kvm virt-install –y

• qemu-kvm – сам гипервизор KVM;
• libvirt – библиотеки управления вирилизацией;
• virt-install – команды для управления виртуальными машинами KVM.

На сервер будет установлено большое количество пакетов, следите, чтобы у вас не возникло ошибок в процессе установки.

Теперь нужно добавить сервис libvirtd в автозагрузку и запустить его:

# systemctl enable libvirtd
# systemctl start libvirtd

Проверьте, загрузились ли модули ядра kvm_intel и kvm:

[root@localhost /]# lsmod | grep kvm

Если у вас ничего не выводится, перезагрузите сервер и проверьте повторно.

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

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

Чтобы созданные виртуальные машины имели доступ в интернет, нам нужно настроить сеть через bridge. Для этого потребуется пакет bridge-utils, проверьте установлен ли он в Linux командой:

# rpm -qa | grep bridge-utils

Если нужно, установите его:

# yum install bridge-utils -y

После установки пакетов для KVM, в системе появился сетевой интерфейс virbr0:

Чтобы создать сетевой мост(bridge), нужно настроить файл конфигурации для сетевого интерфейса сервера:

# cp /etc/sysconfig/network-scripts/ifcfg-enp1s0f0 /etc/sysconfig/network-scripts/ifcfg-enp1s0f0_bak – делаем бэкап файла

# nano /etc/sysconfig/network-scripts/ifcfg-enp1s0f0 — открываем для редактирования

Удалите все содержимое и замените на следующее:

В вашем случае, имя интерфейса может отличаться (смотрите через команду ip a).

После чего создайте файл:

Где укажите свои данные: IP-адрес сервера и основной шлюз. После правки конфигурационных файлов сетевых интерфейсов нужно перезапустить есервис:

# service network restart

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

Последним шагом нужно настроить перенаправление сетевого трафика:

# echo -e «net.ipv4.ip_forward=1» >> /etc/sysctl.conf && sysctl -p

Теперь перезапустите сервис libvirtd:

# service libvirtd restart

На этом базовая настройка KVM закончена, можно создать виртуальную машину.

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

Перед созданием виртуальной машины, я скачал образ CentOS 8 с официального зеркала в директорию /vz/iso:

# cd /vz/iso && wget https://mirror.yandex.ru/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-x86_64-dvd1.iso

Чтобы создать новую виртуалную машину KVM, выполните:

virt-install -n test-centos \
—noautoconsole \
—network=bridge:br0 \
—ram 2048 —arch=x86_64 \
—vcpus=4 —cpu host —check-cpu \
—disk path=/vz/disk/test-centos.img,size=32 \
—cdrom /vz/iso/CentOS-8.1.1911-x86_64-dvd1.iso \
—graphics vnc,listen=IP,password=123456789 \
—os-type linux —os-variant=rhel7 —boot cdrom,hd,menu=on

• test-centos — имя ВМ;
• noautoconsole – после создания не нужно подключаться к консоли виртуальной машины автоматически;
• network – тип сети(в нашем случае bridge);
• ram — количество оперативной памяти в ВМ;
• vcpus – количество ядер процессора (настройка vCPU в KVM);
• disk – виртуальный диск, path – путь до диска. size – объем (в дальнейшем его можно расширить/уменьшить);
• сdrom – виртуальный cdrom, в который монтируется iso образ для установки гостевой ОС;
• graphics — параметры подключения к машине с помощью графической консоли. Мы подключаемся через VNC, поэтому в listen указывает IP сервера, где создали ВМ и пароль для подключения в консоли виртуальной машины (password).

Чтобы ВМ загружалась автоматически, выполните:

# virsh autostart test-centos

Подключение к ВМ на KVM через VNC, установка ОС

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

[root@local vz]# virsh vncdisplay test-centos

0 означает, что порт для подключения по VNC 5900, если у вас будет другой результат, просто прибавляйте к 5900 цифру, которую выдаст вам команда.

Для подключения по VNC к серверам, я использую утилиту TightVNC. Запустите ее и укажите IP-адрес сервера и VNC порт, который мы узнали ранее (через двойное двоеточие).

Нажмите “Connect”, в открывшемся окне укажите пароль, который задали при создании ВМ. Если все сделали верно, у вас откроется консоль сервера, на которой запущена установка CentOS (или другой ОС, образ которой вы смонтировали).

Если у вас на сервере установлен файервол, откройте сетевые порты для VNC 5900-5910 в firewalld/iptables, этого количества должно хватить. После установки гостевой ОС на виртуальную машину, запустите ВМ с консоли сервера:

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

# virsh shutdown test-centos

Чтобы вывести список всех зарегистрированных виртуальных машин KVM:

Если вы предпочитаете графической управление, можете испольховат графическую консоль KVM — virt-manager.

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

Установка Windows на KVM

Установка Windows на KVM для опытных системных администраторов не составит труда. Тем не менее, в процессе развертывания ОС и создания под неё виртуальной машины могут встретиться ряд нетривиальных проблем , связанных с особенностями KVM. О них я и расскажу.

Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге

Установка Windows на KVM

К настоящему моменту у меня уже есть сервер с KVM. На нем также сконфигурирована сеть и хранилище гостевых дисков. Все это я подробно расписал в своей предыдущей статье Установка гипервизора KVM.

Для создания виртуальной машины я буду использовать утилиту virt-install.

Конфигурация виртуальной машины

Есть ряд базовых параметров, без указания которых создание виртуальной машины с помощью virt-install невозможно — это имя ВМ, объем оперативной памяти, настройки диска и параметры установки. Тем не менее, для наглядности я укажу и другие опции, которые так или иначе используются не реже обязательных.

Команда для создания виртуальной машины:

• —-os-type windows — Устанавливает более подходящие аппаратные настройки для конкретной ветки ОС;
• —disk pool=guest_images — Создает виртуальные диски в данном хранилище;
• —graphics vnc,listen=0.0.0.0 — Устанавливаем тип графики. Адрес прослушки необходим, чтобы к vnc могли подключаться удаленные админы. По дефолту разрешены только локальные подключения.

Назначение остальных параметров очевидно.

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

Правильная установка Windows XP в KVM или Технонекрофилия на марше

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

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

Поэтому в офисе по сусекам поскребли, по отсекам помели и нашли старую, покрытую пылью лицензию к Windows XP HE. А большего, в принципе, и не нужно. И вот, я стал запихивать её в виртуалку.

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

Понятно, что для этого виртуальное оборудование должно не эмулировать реальное железо, а использовать виртуальное. Скажем, HDD должен быть не на шине IDE, а на virtio. То же касается и сетевой карты. Обычно рекомендуют сначала ставить ОС на виртуальный IDE-HDD, затем добавлять второй виртуальный винт virtio-HDD, ставить на него драйвера, а потом выключать машину, удалять ненужный уже второй винт и менять тип системного HDD с IDE на virtio.

Честно говоря, все эти вытребеньки показались мне какими-то избыточными, поэтому я процитировал одного известного политического деятеля на предмет пути, которым мы пойдём и взялся за дело по своему.

Для начала я убедился, что virt-manager постоянно создаёт образ диска в qcow2-формате, что само по себе неплохо, но в данном случае излишне, так что я руками создал образ диска в raw-формате.

Затем, при создании виртуальной машины выбрал его и слегка поменял параметры (шину на VirtIO, кэширование на none):

Затем сменил модель сетевой карты на всё ту же VirtIO, для простоты поменял модель звуковой карты на AC97, а затем сделал самое интересное — добавил FDD и подключил в него образ дискеты, взятый отсюда: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win_x86.vfd.

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

Проблем в этом нет, достаточно извлечь установочный образ CD и заменить его на ISO с драйверами. Дальше просто открываем диспетчер устройств, выбираем те, что без драйверов и ставим их через автопоиск.

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

Вопрос кому и зачем она может понадобиться в 2017 году оставим за кадром. : )

Тем более, рекомендации вполне подходят и для актуальный версий windows.

Виртуализацией по тарифам. Настраиваем 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 можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.