Управление kvm qemu через web. KVM – Какое управление через веб-интерфейс нужно использовать? Создание виртуальных машин KVM

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

Vagrant

Виртуальная машина VirtualBox заслуженно пользуется популярностью среди админов и разработчиков, позволяя быстро создавать нужные окружения при помощи графического интерфейса либо интерфейса командной строки. Если количество VM не превышает трех, никаких трудностей в развертывании и управлении не возникает, но современные проекты имеют свойство обрастать конфигурациями, и в итоге получается весьма сложная инфраструктура, справиться с которой становится непросто. Вот эту проблему и призван решить менеджер виртуальных окружений Vagrant , позволяющий создавать копии виртуальных машин с заранее определенной конфигурацией и динамически перераспределять ресурсы VM (Provisioning) по мере необходимости. В базовой поставке Vagrant работает с VirtualBox, но система плагинов позволяет подключить другую систему виртуализации. На сегодня открыт код плагинов для AWS и Rackspace Cloud , по коммерческой подписке доступен плагин для поддержки VMware Fusion/Workstation.

Vagrant не создает виртуальную машину с нуля. Для удобства проект предлагает несколько базовых образов (boxes), которые импортируются и впоследствии используются для быстрого развертывания системы, уже на основе boxes собирается гостевая ОС с нужной конфигурацией.

Для упрощения развертывания приложений в boxes предустанавливаются Chef и Puppet. Кроме того, нужные установки можно задавать при помощи shell. В состав окружений включается полный комплект для запуска и разработки приложений на Ruby. Для доступа к VM используется SSH, возможен обмен файлами через расшаренную директорию.

Написан Vagrant с использованием Ruby, установить его можно на любую платформу, для которой есть компоненты VirtualBox и Ruby. На странице загрузки доступны пакеты для Windows, Linux (deb и rpm) и OS X.

Процесс установки и использования в Ubuntu прост. Скачиваем пакеты VirtualBox и Vagrant и ставим:

$ sudo dpkg -i virtualbox-4.2.10_amd64.deb $ sudo dpkg -i vagrant_1.2.2_x86_64.deb

На момент написания статьи с последней актуальной версией VirtualBox 4.2.14 были проблемы при запуске Vagrant, поэтому пока лучше использовать 4.2.12 или тестовую 4.2.15. Как вариант, можно выполнить:

$ cd ~/.vagrant.d/boxes/BoxName/virtualbox $ openssl sha1 *.vmdk *.ovf > box.mf

Приведу альтернативный вариант установки Vagrant - с использованием Ruby:

$ sudo apt-get install ruby1.8 ruby1.8-dev rubygems1.8 $ sudo gem install vagrant

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

$ mkdir project $ cd project $ vagrant init

Теперь можно заглянуть в созданный файл настроек и заполнить: установки VM (config.vm.), опции подключения по SSH (config.ssh. ), параметры самого Vagrant (config.vagrant). Все они хорошо документированы, значение некоторых понятно и без пояснений.

На самом деле при запуске используется несколько таких файлов, каждый последующий переопределяет предыдущий: встроенный в Vagrant (его изменить нельзя), поставляемый с boxes (упаковывается при помощи ключа "--vagrantfile"), расположенный в ~/.vagrant.d и файл проекта. Такой подход позволяет использовать установки по умолчанию, переопределяя в конкретном проекте только то, что необходимо.

Все установки производятся при помощи команды vagrant, список доступных ключей можно просмотреть при помощи "-h". После установки мы не имеем ни одного образа, запуск vagrant box list выведет пустой список. Готовый box может находиться в локальной ФС или на удаленном сервере, в качестве параметра задается его имя, по которому будем обращаться в проектах. Например, используем официальный Box Ubuntu 12.04 LTS, предлагаемый разработчиками Vagrant.

$ vagrant box add precise64 http://files.vagrantup.com/precise64.box

Теперь к нему можно обращаться из Vagrantfile:

Config.vm.box = "precise64"

Хотя проще сразу его указать при инициализации проекта:

$ vagrant init precise64

Самый простой способ, не требующий изучения Chef и Puppet, - это использовать для конфигурирования VM стандартные команды оболочки, которые можно прописать прямо в Vagrantfile или, что еще лучше, объединить в скрипт, который подключается так:

Vagrant.configure("2") do |config| config.vm.provision:shell, :inline => "script.sh" end

Теперь все команды, указанные в script.sh, будут выполнены при запуске VM. При старте проекта создается ovf-файл, его установки можно просмотреть при помощи графического интерфейса VirtualBox или команды VBoxManage:

$ VBoxManage import /home/user/.vagrant.d/boxes/precise64/virtualbox/box.ovf Virtual system 0: 0: Suggested OS type: "Ubuntu_64" (change with "--vsys 0 --ostype "; use "list ostypes" to list all possible values) 1: Suggested VM name "precise64" (change with "--vsys 0 --vmname ") 2: Number of CPUs: 2 (change with "--vsys 0 --cpus ") 3: Guest memory: 384 MB (change with "--vsys 0 --memory ")

Не всегда они удовлетворяют заданным условиям, но, используя настройки провайдера, можно легко изменить установки конкретной VM (см. подсказки «change with ...»):

Config.vm.provider:virtualbox do |vb| vb.customize ["modifyvm", :id, "--memory", "1024"] end

Запускаем и подключаемся к системе по SSH:

$ vagrant up $ vagrant ssh

Чтобы остановить VM, используется параметр halt или destroy (второй - с очисткой всех файлов, в следующий раз все операции будут выполнены с начала), если нужно отправить ее в спячку - vagrant suspend , вернуть - vagrant resume . Для примера работы с Chef можно использовать готовый рецепт, при помощи которого настроить APT и Apache2:

Config.vm.provision:chef_solo do |chef| chef.recipe_url = "http://files.vagrantup.com/getting_started/cookbooks.tar.gz" chef.add_recipe("vagrant_main") end

Чтобы обращаться к VM «извне», потребуется настроить проброс портов. По умолчанию производится проброс 22 -> 2222, позволяющий подключаться по SSH. Добавляем в Vagrantfile:

Vagrant::Config.run do |config| config.vm.forward_port 80, 1111 end

Теперь к веб-серверу можно обратиться, перейдя по адресу http://127.0.0.1:1111/. Чтобы не настраивать окружение каждый раз, лучше собрать на его основе готовый пакет.

$ vagrant package --vagrantfile Vagrantfile --output project.box

Теперь файл project.box можно распространить среди остальных администраторов, разработчиков или простых пользователей, которые подключат его при помощи команды vagrant box add project.box .

ConVirt

Системы виртуализации Xen/KVM, выпускаемые под свободными лицензиями, не имеют удобного интерфейса, что часто трактуется не в их пользу. Однако этот недостаток легко восполнить. ConVirt позволяет развертывать виртуальные машины на нескольких серверах Xen и KVM буквально одной кнопкой, при помощи простого в использовании интерфейса. Доступны все необходимые операции с виртуальными машинами: запуск, останов, создание снимков, контроль и перераспределение ресурсов, подключение к VM по VNC, автоматизация задач администрирования. Технология Ajax делает интерфейс интерактивным и похожим на настольное приложение. Например, VM с одного сервера на другой можно просто перетащить. Интерфейс нелокализован, но управление интуитивно понятное.

Объединение серверов в пулы дает возможность настраивать и контролировать виртуальные машины и ресурсы на уровне серверного пула, а не отдельного сервера. На виртуальных системах не устанавливаются агенты, необходим лишь пакет convirt-tool на физическом сервере. Это упрощает администрирование и развертывание.

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

Для создания виртуальных машин используются шаблоны - описания настроек виртуальной машины, содержащие данные о выделяемых ресурсах, путь к файлам ОС и дополнительные настройки. После установки доступно несколько готовых шаблонов, но при необходимости их легко создать самому.

Поддерживаются все технологии: балансировка нагрузки, горячая миграция, виртуальные диски с растущей емкостью, позволяющие задействовать ресурсы по мере необходимости, и многие другие возможности, реализованные в Xen и KVM. Чтобы перераспределить ресурсы, остановка VM не требуется.

Реализована возможность управления виртуальной средой нескольким администраторам с возможностью аудита и контроля над их действиями.

Разработку ConVirt ведет компания Convirture, при этом используется концепция open core (открытая основа), когда вместе с исходными текстами свободно распространяется только базовый набор функций, остальное доступно в коммерческой версии. В open source варианте отсутствует поддержка High Availability, интеграция с VLAN, резервирование и восстановление, возможность управления из командной строки, уведомления и официальная поддержка.

При разработке использовались фреймворк TurboGears2, библиотеки ExtJs и FLOT, для хранения информации - MySQL, в качестве DHCP- и DNS-сервера задействован dnsmasq. Нужный пакет можно найти в репозиториях популярных дистрибутивов Linux.

Karesansui

Реализованы все возможности для управления виртуальными окружениями: установка ОС, создание конфигураций дисковой подсистемы и виртуальных сетевых карт, управление квотами, репликация, заморозка VM, создание снапшотов, просмотр подробной статистики и данных журналов, мониторинг загрузки. С одной консоли можно управлять несколькими физическими серверами и размещенными на них виртуальными машинами. Возможна многопользовательская работа с разделением прав. В итоге разработчикам удалось в браузере реализовать виртуальное окружение, позволяющее полноценно управлять системами.

Написан Karesansui на языке Python, в качестве СУБД для одноузловой системы используется SQLite. Если планируется управлять установками Karesansui, размещенными на нескольких физических серверах, следует использовать MySQL или PostgreSQL.

Развернуть Karesansui можно в любом Linux. Сами разработчики отдают предпочтение CentOS (для которого на сайте есть подробная инструкция), хотя Karesansui неплохо себя чувствует и на Debian и Ubuntu. Перед установкой необходимо выполнить все зависимости, указанные в документации. Далее запускается установочный скрипт и инициализируется БД. Если используется многосерверная конфигурация, то нужно просто указать внешнюю БД.

Последующая работа полностью компенсирует неудобства установки. Все настройки разделены по семи вкладкам, назначение которых понятно из названия: Guest, Settings, Job, Network, Storage, Report и Log. В зависимости от роли пользователя ему будут доступны не все из них.

Создать новую VM можно из локального ISO-файла или указав HTTP/FTP-ресурс с установочными образами. Также потребуется задать остальные атрибуты: имя системы, которое будет отображаться в списке, сетевое имя (hostname), технология виртуализации (Xen или KVM), размер ОЗУ и жесткого диска (Memory Size и Disk Size) - и выбрать картинку, которая будет соответствовать виртуальной ОС, упрощая ее быстрый визуальный выбор в консоли.

WebVirtMgr

Возможности описанных решений зачастую избыточны, а их установка не всегда понятна администратору с небольшим опытом. Но и здесь есть выход. Сервис централизованного управления виртуальными машинами WebVirtMgr создавался как простая замена virt-manager, которая обеспечит комфортную работу с VM при помощи браузера с установленным Java-плагином. Поддерживается управление настройками KVM: создание, установка, настройка, запуск VM, снапшоты и резервное копирование виртуальных машин. Обеспечивается управление сетевым пулом и пулом хранилища, работа с ISO, клонирование образов, просмотр загрузки ЦПУ и ОЗУ. Доступ к виртуальной машине осуществляется через VNC. Все операции фиксируются в журналах. При помощи одной установки WebVirtMgr можно управлять несколькими серверами KVM. Для подключения к ним используется RPC libvirt (TCP/16509) или SSH.

Интерфейс написан на Python/Django. Для установки понадобится сервер под управлением Linux. Распространяется в исходных текстах и RPM-пакетах для CentOS, RHEL, Fedora и Oracle Linux 6. Сам процесс развертывания несложен и хорошо описан в документации проекта (на русском), необходимо лишь настроить libvirt и установить webvirtmgr. Весь процесс занимает пять минут. После подключения к Dashboard выбираем Add Connection и указываем параметры узла, далее можем настраивать VM.

Скриптуем создание VM

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

#!/bin/bash vmname="debian01" VBoxManage createvm --name ${vmname} --ostype "Debian" --register VBoxManage modifyvm ${vmname} --memory 512 --acpi on --boot1 dvd VBoxManage createhd --filename "${vmname}.vdi" --size 10000 --variant Fixed VBoxManage storagectl ${vmname} --name "IDE Controller" --add ide --controller PIIX4 VBoxManage storageattach ${vmname} --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium "${vmname}.vdi" VBoxManage storageattach ${vmname} --storagectl "IDE Controller" --port 0 --device 1 --type dvddrive --medium /iso/debian-7.1.0-i386-netinst.iso VBoxManage modifyvm ${vmname} --nic1 bridged --bridgeadapter1 eth0 --cableconnected1 on VBoxManage modifyvm ${vmname} --vrde on screen VBoxHeadless --startvm ${vmname}

Proxmox VE

Предыдущие решения хороши для тех ситуаций, когда уже есть некоторая инфраструктура. Но если ее предстоит только разворачивать, стоит задуматься о специализированных платформах, позволяющих быстро получить нужный результат. Примером здесь может служить Proxmox Virtual Environment , представляющий собой дистрибутив Linux (на базе Debian 7.0 Wheezy), который позволяет быстро построить инфраструктуру виртуальных серверов с использованием OpenVZ и KVM и практически не уступает таким продуктам, как VMware vSphere, MS Hyper-V и Citrix XenServer.

По сути, систему следует только установить (пара простых шагов), все остальное уже работает из коробки. Затем при помощи веб-интерфейса можно создавать VM. Для этой цели проще всего использовать шаблоны и контейнеры OpenVZ, которые загружаются с внешних ресурсов прямо из интерфейса одним щелчком (если вручную, то копируем в каталог /var/lib/vz/template). Но шаблоны можно создавать в том числе и путем клонирования уже созданных систем в режиме связывания. Этот вариант позволяет экономить дисковое пространство, так как все связанные окружения используют только одну общую копию данных эталонного шаблона без дублирования информации. Интерфейс локализован и понятен, особых неудобств при работе с ним не испытываешь.

Имеется поддержка кластеров, инструменты для резервного копирования виртуальных окружений, возможна миграция VM между узлами без остановки работы. Управление доступом к имеющимся объектам (VM, хранилище, узлы) реализовано на основе ролей, поддерживаются различные механизмы аутентификации (AD, LDAP, Linux PAM, встроенная Proxmox VE). Веб-интерфейс предоставляет возможность доступа к VM при помощи VNC- и SSH-консолей, можно просматривать статус заданий, журналы, данные мониторинга и многое другое. Правда, некоторые операции, специфические для HA-систем, придется все же выполнять по старинке в консоли, например создавать авторизованное iSCSI-подключение, настраивать кластер, создавать multipath и некоторые другие операции.

Системные требования невелики: CPU x64 (желательно с Intel VT/AMD-V), 1+ Гб ОЗУ. Проект предлагает готовый ISO-образ и репозиторий для Debian.

Заключение

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

С обычными KVM-переключателями, полагаю, сталкивались многие. Аббревиатура "KVM" расшифровывается как "Keyboard Video Mouse". KVM-устройство позволяет, имея только один комплект клавиатура+монитор+мышь (К.М.М.), управлять несколькими компьютерами (системными блоками). Другими словами, берем N системных блоков, подключаем их выходы от К.М.М. в KVM-устройство, а уже к самому устройству подключаем реальный монитор, клавиатуру и манипулятор-мышь. Переключаясь с помощью KVM между компьютерами, мы можем видеть происходящее на экране выбранного компьютера, а так же управлять им, как будто мы подключены к нему напрямую.

Это удобно, если для работы нам нужно несколько машин, но доступ к ним одновременно не обязателен. К тому же, сильно экономится место - мониторы, даже жидкокристаллические, занимают довольно большой объем места на столе. Да и стоят не мало. А в куче клавиатур и мышек на столе можно быстро запутаться…

Продвинутые читатели возразят - а зачем такие сложности, если компьютеры, скорее всего, подключены к одной локальной сети и можно воспользоваться встроенными в операционную систему (или внешними) программами удаленного доступа, например Terminal Services или Radmin под Windows, VNC, ssh под *nix-like операционные системы. Все правильно, но что делать, если потребуется, к примеру, войти в биос компьютера или операционная система перестала загружаться, потому что мы поставили какой то неправильный драйвер или программу? Или же у нас установлено несколько ОС на компьютере и нам понадобилось выбрать не ту, что стартует по умолчанию? В общем, все эти программы действительно хороши, но до определенных пределов - пока ОС компьютера работоспособна и нам требуется лишь доступ к компьютеру после того, как эта ОС загрузится.

Для примера, рассмотрим несколько характерных KVM-переключателей на примере устройств, выпускаемых компанией .

Спецификации устройства

CN-6000 поддерживает разделение полномочий между пользователями и позволяет завести до 64 административных или пользовательских аккаунтов, из них одновременно работать с устройством могут до 16 аккаунтов. Устройство имеет встроенный WEB-интерфейс администрирования, а его небольшие размеры позволяют разместить его на столе или смонтировать (с помощью спец.планки, идущей в комплекте) его на боковой ферме стойки (0U rack mountable). CN-6000 поддерживает обновление прошивки через Ethernet-соединение (с веб-интерфейса или родной утилитой). Максимальное разрешение видео, которое поддерживает устройство, составляет 1600x1200 точек.

Сводная таблица спецификаций:

Переходим к тестам.

На компакт диске, идущим в комплекте, можно найти четыре утилиты:

• CN6000 Client - программа-клиент под Windows, с помощью которой можно подключится к удаленному компьютеру
• аналогичная программа-клиент, написанная на Java (в формате jar)
• CN6000 Admin Tool - менеджер конфигурирования устройства (под Windows)
• лог-сервер - программа, которую можно настроить на получение и хранение лог файлов с CN-6000

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

Конфигурирование CN-6000 через утилиту Admin Tool.

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

При ее запуске не обошлось без курьеза:

При первом запуске всех утилит с прилагаемого диска, требуется ввести серийный номер. В документации (даже последней версии, что лежит на сайте производителя) сказано, что серийник напечатан в нижней части корпуса CN-6000. И там действительно напечатан какой-то серийный номер, только он намного короче, чем требуется программам. В общем, немного помучавшись, вводя найденный серийник так и эдак, прибавляя к нему нули или пробелы и не достигнув ничего более, чем окошка "Invalid Serial Number", я уже хотел было закончить в тот день тестирование устройства. Достав компакт диск из CD-ROM-а (его я вставил в CD-привод в первую очередь - надо же было инсталлировать ПО), я обнаружил странную наклейку на диске - это и оказался заветный серийник.

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

Утилита администрирования CN-6000 полезна тем, что позволяет найти устройство в сети, даже если его IP-адрес не принадлежит той подсети, в которой мы находимся, достаточно лишь, что бы мы (компьютер, с которого мы пытаемся получить доступ к CN-6000) находились в том же сегменте локальной сети, что и KVM-переключатель.

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

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

В разделе Network настраивается IP адресация устройства, задаются порты для удаленного доступа к управляемым посредством CN-6000 компьютерам. А так же тут можно указать MAC-адрес машины, на котором расположена программа "Log Server", которая хранит лог файлы (события), отсылаемые с KVM-переключателя (если ее не задать, логи будут хранится на самом KVM и посмотреть их можно будет с веб-интерфейса). Этой машиной (для Log-сервера) может являться любой компьютер, на котором стоит Windows и запущена обсуждаемая программа. Проблема лишь в том, что компьютер должен находится в том же сетевом сегменте (грубо говоря, подключен к тому же коммутатору), что и сам KVM CN-6000, поэтому полезность данной "фичи" вызывает сомнение.

В закладке Security настраиваются фильтры (по MAC и/или IP адресам) доступа к удаленному экрану администрируемых компьютеров, а так же фильтр на администрирование самого CN-6000.

В следующей закладке задаются имена и пароли пользователей, а так же их права. Что примечательно, можно ограничить логины на конфигурирование CN-6000 и использования JAVA-клиента. Минимальная длина пароля, которую принимает утилита конфигурации, равен восьми символам. Жаль конечно, что пароль не проверяется на "простоту", но даже проверка длины пароля говорит о том, что безопасности ATEN уделяет внимание.

Последняя закладка позволяет обновить прошивку устройства, включить возможность одновременного коннекта к удаленному компьютеру нескольким людям (правда мышка и клавиатура все равно одна, с точки зрения управляемого компьютера, поэтому один управляет, остальные - смотрят… или мешают друг другу, перетягивая мышь в разные стороны). Тут же настраивается реакция на неправильный процесс аутентификации, а так же включение различных режимов "скрытия" CN-6000 (отсутствие реации на ping и запрет на показ себя при автоматическом поиске устройств в локальной сети через клиентскую утилиту или утилиту администрирования).

В этой же закладке есть еще один пункт - Reset on Exit . Я бы предположил, что это сброс настроек на умолчательные, но в данном случае это подразумевает перезагрузку устройства при выходе из утилиты конфигурирования. В противном случае (если его не перезагрузить), новые настройки хоть и запомнятся, но применяться не будут (до перезагрузки).

На этом рассмотрение утилиты конфигурирование можно считать законченным (еще один аспект будет рассмотрен в разделе про Java-client).

Переходим к веб-интерфейсу.

Конфигурирование через WEB-интерфейс

Для того, что бы попасть в веб-интерфейс устройства, достаточно в любом браузере набрать IP-адрес, который установлен на CN-6000.

Примечательно, что браузер сразу перебрасывает клиента на коннект по HTTPS://, т.е. вся дальнейшая работа происходит через защищенное SSL-соединение.

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

Верхние иконки открывают разделы, связанные с конфигурированием CN-6000. По большей части, все опции там повторяют опции интерфейса Windows-утилиты Admin Tool , но есть некоторые отличия. К примеру, в данном окне (конфигурирование сетевых адресов) мы можем задать только IP-адрес устройства, но не можем указать маску подсети и шлюз. К тому же, задание IP-адреса работает как то криво - мне так и не удалось сменить IP-адрес устройства с веб-интерфейса (с помощью утилиты Admin Tools он менялся без проблем).

Вот что можно наблюдать в утилите Admin Tool при попытке смены адреса через веб-интерфейс с 10.0.0.9 на 192.168.0.1. Маска подсети почему то сменилась со стандартной 255.255.255.0 на 10.0.0.9, а устройство (после перезагрузки) секунд 5 отвечает по адресу 192.168.0.1, а потом начинает отвечать по 10.0.0.9 (про 192.168.0.1 забывает напрочь). Возможно, это баг текущей версии прошивки (1.5.141), но эта версия, на момент тестирования, являлось самой новой из тех, что можно было найти на веб-сайте компании.

Больше багов, связанных с веб-интерфейсом, в процессе тестирования обнаружено не было.

Раздел Security повторяет аналогичный раздел в утилите Admin Tool.

Аналогичная ситуация с разделом User Manager …

… и разделом Customization .

Иконка Log , расположенная в левой части веб-интерфейса, позволяет посмотреть события, происходившие при работе устройства. В данном случае скриншот отражает логи, которые появились в момент тестирования устройства программой Nessus.

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

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

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

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

Я попробовал много веб-интерфейса управления, а не из них был достаточно хорош, как virt-manager.

Вы знаете, я один из тех ребят, у которых раньше была VMware, где 90% управления щелкают.

Мои вопросы:

1) Есть ли какая-либо «интерактивная» утилита CLI, например, mc (командир полуночи) или что-то, как управлять KVM? (ВКЛ / ВЫКЛ VM, увеличение memmory, перезапуск виртуальных машин, добавление виртуального оборудования, добавление новых дисков и т. Д.)

2) Могли бы вы порекомендовать мне какой-то интерфейс управления веб-интерфейсом для KVM на debian squeeze? Вы видели сервер VMware 2? Существует веб-управление. Я знаю, что это было медленно, но это нормально, когда вы где-то без терминала. (например, на Android с веб-браузером) Я пробовал много из них, но ничего, что я пытался, работал.

5) Как повысить безопасность KVM? Может ли решить эту проблему некоторый веб-интерфейс? (например, учет, управление пользователями?)

Я знаю, что есть google, wiki, есть длинный список пользовательского интерфейса для kvm, но мне нужны мнения, опыт экспертов или пользователей, которые используют KVM. Надеюсь, это не какой-то глупый вопрос. Спасибо всем за ответы на мои вопросы.

5 Solutions collect form web for “KVM – Какое управление через веб-интерфейс нужно использовать?”

Для веб-менеджера KVM вы можете попробовать Proxmox . Инструкция для Debian Squeeze здесь.

Он имеет инструменты командной строки, но не текстовое базовое меню.

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

Для этого нет точного ответа / учебника. Насколько перестраиваемый сервер / клиент KVM действительно зависит от того, сколько ресурсов (cpu / ram / storage) доступно.

Опять же, это зависит от вашей среды, и это многослойные / устройства, например. маршрутизаторы, брандмауэр, ip-таблицы, политику паролей, политику доступа и т. д. Я не знаю ни одной gui, веб-базы или нет, которая может обрабатывать все из них, включая KVM. (ОК, есть облако, но у меня нет опыта с этим вообще)

Вы пробовали Кимчи ? является самым удобным для пользователей открытым исходным кодом на KVM, и его спонсирует IBM.

Отказ от ответственности: Я вообще не являюсь аффилированным лицом с Кимчи. Мне просто нравится его дружелюбие.

Эксперты используют CLI. Не GUI. Это даже верно для опытных администраторов Windows.

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

Повысить производительность в KVM? Выброси это.

Это всего лишь намек эксперта XEN-PV. Только LXC (или другие контейнеры) или chroot-based решения быстрее.

Руководство по установке KVM может быть не очень подробным, но, по крайней мере, дать или предоставить идеи относительно процесса установки и настройки.

Есть новое KVM на уровне предприятия и управление системой AV / IT под названием Boxilla, в котором есть комплексный и централизованный командный центр, который обеспечивает максимальную производительность, простоту использования и безопасность.

Он обеспечивает возможность управления высокопроизводительными KVM, KVM через IP, виртуализованными конечными точками и различными AV / IT-устройствами в одном централизованном командном центре, позволяет администраторам управлять многоуровневыми KVM и развертываниями AV / IT с использованием мощного веб- и общий пользовательский интерфейс. Об этом вы можете найти здесь: https://www.blackbox.co.uk/gb-gb/page/37929/Solutions-Industries/Technology-Products/KVM-Switching-and-Extension/Centralised-KVM-AV- Менеджер-Boxilla

Мне лично проще всего думать о KVM (Kernel-based Virtual Machine), как о таком уровне абстракции над технологиями хардверной виртуализации Intel VT-x и AMD-V. Берем машину с процессором, поддерживающим одну из этих технологий, ставим на эту машину Linux, в Linux’е устанавливаем KVM, в результате получаем возможность создавать виртуалки. Так примерно и работают облачные хостинги, например, Amazon Web Services . Наряду с KVM иногда также используется и Xen, но обсуждение этой технологии уже выходит за рамки данного поста. В отличие от технологий контейнерной виртуализации, например, того же Docker , KVM позволяет запускать в качестве гостевой системы любую ОС, но при этом имеет и бо льшие накладные расходы на виртуализацию.

Примечание: Описанные ниже действия были проверены мной на Ubuntu Linux 14.04, но по идее будут во многом справедливы как для других версий Ubuntu, так и других дистрибутивов Linux. Все должно работать как на десктопе, так и на сервере, доступ к которому осуществляется по SSH.

Установка KVM

Проверяем, поддерживается ли Intel VT-x или AMD-V нашим процессором:

grep -E "(vmx|svm)" / proc/ cpuinfo

Если что-то нагреполось, значит поддерживается, и можно действовать дальше.

Устанавливаем KVM:

sudo apt-get update
sudo apt-get install qemu-kvm libvirt-bin virtinst bridge-utils

Что где принято хранить:

• /var/lib/libvirt/boot/ — ISO-образы для установки гостевых систем;
• /var/lib/libvirt/images/ — образы жестких дисков гостевых систем;
• /var/log/libvirt/ — тут следует искать все логи;
• /etc/libvirt/ — каталог с файлами конфигурации;

Теперь, когда KVM установлен, создадим нашу первую виртуалку.

Создание первой виртуалки

В качестве гостевой системы я выбрал FreeBSD. Качаем ISO-образ системы:

cd / var/ lib/ libvirt/ boot/
sudo wget http:// ftp.freebsd.org/ path/ to/ some-freebsd-disk.iso

Управление виртуальными машинами в большинстве случаев производится при помощи утилиты virsh:

sudo virsh --help

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

Смотрим список доступных сетей:

sudo virsh net-list

Просмотр информации о конкретной сети (с именем default):

sudo virsh net-info default

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

sudo virt-install --os-variant list

Итак, теперь создаем виртуальную машину с 1 CPU, 1 Гб RAM и 32 Гб места на диске, подключенную к сети default:

sudo virt-install \
--virt-type =kvm \
--name freebsd10 \
--ram 1024 \
--vcpus =1 \
--os-variant =freebsd8 \
--hvm \
--cdrom =/ var/ lib/ libvirt/ boot/ FreeBSD-10.2 -RELEASE-amd64-disc1.iso \
--network network =default,model =virtio \
--graphics vnc \
--disk path =/ var/ lib/ libvirt/ images/ freebsd10.img,size =32 ,bus =virtio

Вы можете увидеть:

WARNING Unable to connect to graphical console: virt-viewer not
installed. Please install the "virt-viewer" package.

Domain installation still in progress. You can reconnect to the console
to complete the installation process.

Это нормально, так и должно быть.

Затем смотрим свойства виртуалки в формате XML:

sudo virsh dumpxml freebsd10

Тут приводится наиболее полная информация. В том числе есть, к примеру, и MAC-адрес, который понадобятся нам далее. Пока что находим информацию о VNC. В моем случае:

С помощью любимого клиента (я лично пользуюсь Rammina) заходим по VNC , при необходимости используя SSH port forwarding. Попадаем прямо в инстялятор FreeBSD. Дальше все как обычно — Next, Next, Next, получаем установленную систему.

Основные команды

Давайте теперь рассмотрим основные команды для работы с KVM.

Получение списка всех виртуалок:

sudo virsh list --all

Получение информации о конкретной виртуалке:

sudo virsh dominfo freebsd10

Запустить виртуалку:

sudo virsh start freebsd10

Остановить виртуалку:

sudo virsh shutdown freebsd10

Жестко прибить виртуалку (несмотря на название, это не удаление):

sudo virsh destroy freebsd10

Ребутнуть виртуалку:

sudo virsh reboot freebsd10

Склонировать виртуалку:

sudo virt-clone -o freebsd10 -n freebsd10-clone \
--file / var/ lib/ libvirt/ images/ freebsd10-clone.img

Включить/выключить автозапуск:

sudo virsh autostart freebsd10
sudo virsh autostart --disable freebsd10

Запуск virsh в диалоговом режиме (все команды в диалоговом режиме — как описано выше):

sudo virsh

Редактирование свойств виртуалки в XML, в том числе здесь можно изменить ограничение на количество памяти и тд:

sudo virsh edit freebsd10

Важно! Комментарии из отредактированного XML, к сожалению, удаляются.

Когда виртуалка остановлена, диск тоже можно ресайзить:

sudo qemu-img resize / var/ lib/ libvirt/ images/ freebsd10.img -2G
sudo qemu-img info / var/ lib/ libvirt/ images/ freebsd10.img

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

Резервное копирование и восстановление производятся довольно просто. Достаточно сохранить куда-то вывод dumpxml, а также образ диска, а потом восстановить их. На YouTube удалось найти видео с демонстрацией этого процесса, все и вправду несложно.

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

Интересный вопрос — как определить, какой IP-адрес получила виртуалка после загрузки? В KVM это делается хитро. Я в итоге написал такой скрипт на Python :

#!/usr/bin/env python3

# virt-ip.py script
# (c) 2016 Aleksander Alekseev
# http://сайт/

import sys
import re
import os
import subprocess
from xml .etree import ElementTree

def eprint(str ) :
print (str , file = sys .stderr )

if len (sys .argv ) < 2 :
eprint("USAGE: " + sys .argv [ 0 ] + " " )
eprint("Example: " + sys .argv [ 0 ] + " freebsd10" )
sys .exit (1 )

if os .geteuid () != 0 :
eprint("ERROR: you shold be root" )
eprint("Hint: run `sudo " + sys .argv [ 0 ] + " ...`" ) ;
sys .exit (1 )

if subprocess .call ("which arping 2>&1 >/dev/null" , shell = True ) != 0 :
eprint("ERROR: arping not found" )
eprint("Hint: run `sudo apt-get install arping`" )
sys .exit (1 )

Domain = sys .argv [ 1 ]

if not re .match ("^*$" , domain) :
eprint("ERROR: invalid characters in domain name" )
sys .exit (1 )

Domout = subprocess .check_output ("virsh dumpxml " +domain+" || true" ,
shell = True )
domout = domout.decode ("utf-8" ) .strip ()

if domout == "" :
# error message already printed by dumpxml
sys .exit (1 )

Doc = ElementTree.fromstring (domout)

# 1. list all network interfaces
# 2. run `arping` on every interface in parallel
# 3. grep replies
cmd = "(ifconfig | cut -d " " -f 1 | grep -E "." | " + \
"xargs -P0 -I IFACE arping -i IFACE -c 1 {} 2>&1 | " + \
"grep "bytes from") || true"

for child in doc.iter () :
if child.tag == "mac" :
macaddr = child.attrib [ "address" ]
macout = subprocess .check_output (cmd .format (macaddr) ,
shell = True )
print (macout.decode ("utf-8" ) )

Скрипт работает как с default сетью, так и с bridged сетью, настройку которой мы рассмотрим далее. Однако на практике куда удобнее настроить KVM так, чтобы он всегда назначал гостевым системам одни и те же IP-адреса. Для этого правим настройки сети:

sudo virsh net-edit default

… примерно таким образом:

>



>

После внесения этих правок


>

… и заменяем на что-то вроде:

>

Перезагружаем гостевую систему и проверяем, что она получила IP по DHCP от роутера. Если же вы хотите, чтобы гостевая система имела статический IP-адрес, это настраивается как обычно внутри самой гостевой системы.

Программа virt-manager

Вас также может заинтересовать программа virt-manager:

sudo apt-get install virt-manager
sudo usermod -a -G libvirtd USERNAME

Так выглядит ее главное окно:

Как видите, virt-manager представляет собой не только GUI для виртуалок, запущенных локально. С его помощью можно управлять виртуальными машинами, работающими и на других хостах, а также смотреть на красивые графички в реальном времени. Я лично нахожу особенно удобным в virt-manager то, что не нужно искать по конфигам, на каком порту крутится VNC конкретной гостевой системы. Просто находишь виртуалку в списке, делаешь двойной клик, и получаешь доступ к монитору.

Еще при помощи virt-manager очень удобно делать вещи, которые иначе потребовали бы трудоемкого редактирования XML-файлов и в некоторых случаях выполнения дополнительных команд. Например, переименование виртуальных машин, настройку CPU affinity и подобные вещи. Кстати, использование CPU affinity существенно снижает эффект шумных соседей и влияние виртуальных машин на хост-систему. По возможности используйте его всегда.

Если вы решите использовать KVM в качестве замены VirtualBox, примите во внимание, что хардверную виртуализацию они между собой поделить не смогут. Чтобы KVM заработал у вас на десктопе, вам не только придется остановить все виртуалки в VirtualBox и Vagrant , но и перезагрузить систему. Я лично нахожу KVM намного удобнее VirtualBox, как минимум, потому что он не требует выполнять команду sudo / sbin/ rcvboxdrv setup после каждого обновления ядра, адекватно работает c Unity , и вообще позволяет спрятать все окошки.