Управление kvm из windows

Обновлено: 04.07.2024

Гипервизор KVM идет с отличными утилитами управления для командной строки. Что касается графических программ для управления виртуальными машинами на KVM, то здесь все хуже. Под Linux стандартным средством является Virt-Manager. Давайте посмотрим, как можно использовать его под Windows.

Graphical Management of Guests

The standard utility for graphical management of guests is virt-manager which is comparable to Hyper-V Manager, in that it can manage the specifics of a given virtual machine on either a local or remote server. You can also connect to the console regardless of network connectivity, and create and destroy guests. This is not enterprise management, for that you would need to look at Convirt or RHEV. Now as you will see there is no Windows version of Virt-Manager. So how can we use Windows to graphically manage KVM? X11 Forwarding through SSH. This requires 2 bits of software to be installed on the Windows machine (1) a X Window Server, I used XMing which is freely available (2) a SSH Client, XMing will install PuTTy for you, if you are using a different X Window Server you may or may not need to install PuTTy manually.

When installing XMing simply accept all defaults. Then to initiate the connection, launch XMing which will launch into the background. Then setup your PuTTy connection and under the SSH options enable X11 Forwarding. Then initiate your connection to the server and launch virt-manager.

On the server side the only configuration that needs to take place is the installation of the utility you wish to use (virt-manager, virt-viewer, etc).

Figure 1 – Showing the X Window server (XMing) running in the taskbar.

Figure 2 – Showing the X11 Forwarding configuration for PuTTy connections.

Figure 3 – Showing the PuTTy session where we launch the virt-manager utility which is running in the background.

Figure 4 – Showing the Console view of a VM via virt-manager running in Windows 7 by X11 Forwarding.

Figure 5 – Showing the Details view of a VM via virt-manager running in Windows 7 by X11 Forwarding.

One small caveat that I have noticed with this configuration, when redirecting X, virt-manager does not close all of the processes it is using when you close it, thus when you go to exit the PuTTy session it hangs. If you close your X Window server on Windows (in my case XMing) it will close your PuTTy as well (as long as you have already exited from the session). If you are redirecting X on Linux, a control + c will kill the process.

Управление KVM с помощью Virt-Manager на Windows: 1 комментарий

Гипервизор KVM идет с отличными утилитами управления для командной строки. Что касается графических программ для управления виртуальными машинами на сервер KVM, то здесь дело обстоит хуже. Под Linux стандартным средством является Virt-Manager. Давайте посмотрим, как можно использовать его под Windows.

Стандартная утилита для графического управления гостевыми системами в KVM это virt-manager, который по функционалу сравним с другими управляющими утилитами, например Hyper-V Manager, в части управления виртуальными машины на локальном или удаленном гипервизоре.

Нормальной работоспособной версии Virt-Manager или его аналога под операционную систему Windows я пока не встречал. В связи с этим в Windows необходимо использовать для графического управления KVM утилиты, обеспечивающие X11 Forwarding через протокол SSH.

При установке XMing оставляем все параметры по умолчанию и просто нажимаем далее. В конце установке XMing уведомит о возможности запуска в фоновом режиме. Мы с этим соглашаемся. После чего в системном трее появится значок X Window server (XMing) со следующим контекстным меню (скриншот ниже).

Далее потребуется выполнить настройку подключения по SSH через PuTTy.

В настройках PuTTy переходим в раздел Connection – SSH – X11. Далее необходимо разрешить X11 Forwarding. Скриншот ниже.

Далее можно вернуться в раздел Connection – SSH и в строке “Remote Command” указать команду автоматического запуска:

Далее можно выполнить подключение к серверу нажав кнопку “Open” и запуск virt-manager.

Если не выполнять последнюю настройку выше, то при запуске PuTTy можно ввести название нужной утилиты и нажать Enter (скриншот ниже).

Ниже представлена консоль virt-manager , подключенная к гипервизору KVM на которой развернуты две виртуальные машины на плтавформе Windows и Linux.

Если щелкнуть правой кнопкой мыши по надписи localhost (QEMU) и выбрать пункт Details , то будет отображен информация о гипервизоре. Скриншот ниже.

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

Необходимо учитывать, что при закрытии окна Putty, сессия будет разорвана.

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

Как я писал ранее, на стадии установки и создания сервера виртуальных машин KVM, основной проблемой управления виртуалкой, является полное отсутствие каких либо вменяемых решений для управления виртуальной структурой в случае если сервер KVM установлен на *nix без GUI, а администраторская машина работает под Windows.

Собственно к самой машине можно получить доступ через VNС, который по дефолту запускается для каждой новой виртуальной машины на локальной IP 127.0.0.1 на портах начиная с 5900. То есть можно играться с инкапсулированием VNC в ssh сессию, но проще запаролить доступ к VNC сессии на момент установки и задать серверу слушать подключение на внешнем IP.

Делается это следующим образом.
Изначально при создании виртуальной машины можно было прописать в параметры её создания --graphics vnc,listen=0.0.0.0 --noautoconsole что открывало бы VNС для подключения с любого хоста.

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

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

Под винду для этого можно использовать веб-клиенты:

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

Если вы ставили Cloudmin на голую машину, то просто начинаете создавать с нуля систему. Если же у вас были работающие машины, то их придется проинициализировать, после перезагрузки системы: System Operations -> Find KVM Instances где ввести параметры доступа к серверу.

После инициализации машины появятся в консоли управления, но функционал их управления, надо заметить, будет сильно хуже чем у webvirtmgr. Тем более, что в моем случае, машинки почему то начали дурковать после установки Cloudmin и оказалось проще снести управлялку, чем разбираться из-за чего возникли конфликты.

Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных 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

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

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

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

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

Читайте также: