Интерес пользователей к виртуализации в последнее время стал пропадать. С одной стороны, есть понятные десктопные решения под любую ось. С другой — стоимость VDS не так уж и высока, а сервер доступен всем, можно демонстрировать разработки с любой точки. Но если с Linux все более-менее ясно и выбор есть, то 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. Проверить их наличие можно вручную или при помощи утилит:

$ sudo apt-get install cpu-checker
$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

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

$ egrep -c "svm|vmx" /proc/cpuinfo

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

$ lsmod | grep kvm
kvm_intel 28703 3
kvm 29690 1 kvm_intel
Проверяем поддержку KVM
Проверяем поддержку KVM

Накладные расходы чуть выше, чем при использовании 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.

$ sudo apt install virt-manager

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

$ sudo apt install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

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

$ qemu-system-x86_64 -monitor stdio -machine type=pc,accel=kvm
(qemu) info kvm
kvm support: enabled

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

$ sudo apt install libosinfo-bin
$ osinfo-query os

Или так:

$ sudo apt install virtinst
$ sudo virt-install --os-variant list
Список поддерживаемых ОС и их названия
Список поддерживаемых ОС и их названия

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

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

$ virsh --help

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

$ virsh list --all

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

$ virsh net-info default
Name:    default
UUID:    9a423010-a969-4e82-b91f-4b24da839c14
Active:    yes
Persistent:    yes
Autostart:    yes
Bridge:    virbr0

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

$ sudo ls -la /var/run/libvirt/libvirt-sock

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

$ sudo rmmod kvm
$ sudo modprobe -a kvm

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

$ wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

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

$ qemu-img create -f qcow2 -o preallocation=metadata winserv2012.qcow2 25G
Formatting 'winserv2012.qcow2', fmt=qcow2 size=26843545600 encryption=off cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16

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

$ qemu-img resize winserv2012.qcow2 +10G

Ставим ОС:

$ virt-install --connect qemu:///system --name WinServ2012 --ram 6048 --vcpus 4 --disk path=winserv2012.qcow2,format=qcow2,bus=virtio,cache=none --disk path=virtio-win.iso,device=cdrom --cdrom win2012.iso --network=bridge:virbr0,model=e1000 --vnc --os-type=windows --os-variant=win2k12r2 --noautoconsole --accelerate --noapic --keymap=en-us

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

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

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

$ virsh --connect qemu:///system start WinServ2012

или удаленно:

$ virt-viewer -c qemu+ssh://example.org/system WinServ2012

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

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

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

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

$ virt-install --connect qemu:///system --name WinServ2012R2 --ram 6048 --vcpus 4 --disk path=win2012r2.qcow2,format=qcow2,bus=virtio,cache=none --network=bridge:virbr0,model==virtio --vnc --os-type=windows --os-variant=win2k12r2 --noautoconsole --accelerate --noapic --keymap=en-us --import

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

$ virsh suspend WinServ2012R2

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

$ virsh edit WinServ2012R2
<interface type='network'>
...
<model type='virtio' />
</interface>

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

$ virsh dumpxml WinServ2012R2 > WinServ2012R2-clone.xml

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

$ virt-clone -o WinServ2012R2 -n WinServ2012R2-clone --file /var/lib/libvirt/images/WinServ2012R2-clone.qcow2
Настройки виртуальной машины
Настройки виртуальной машины
 

Сеть в KVM

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

$ sudo iptables -n -t nat -L
Правила iptables после установки KVM
Правила iptables после установки KVM

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

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

$ sudo virsh net-edit default

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

<dhcp>
  <range start='192.168.122.2' end='192.168.122.254'/>
  <host mac='52:54:00:68:27:72' name='WinServ2012R2' ip='192.168.122.2'/>
</dhcp>
Редактируем сетевые настройки для виртуального хоста
Редактируем сетевые настройки для виртуального хоста

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

$ sudo virsh net-destroy default
$ sudo virsh net-start default

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

iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 --dport 3389 -j DNAT --to-destination 192.168.122.2

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

$ ssh user@example.org -L 5900:127.0.0.1:5900

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

$ netstat -ant | grep 5900
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN

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

<graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'>

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

$ sudo nano /etc/libvirt/qemu.conf
vnc_listen = "0.0.0.0"
# Пароль не более восьми символов
vnc_password = "password"
 

Заключение

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

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • 2 комментария к записи Виртуализацией по тарифам. Настраиваем Windows в KVM
    Подписаться
    Уведомить о
    2 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии