Главная > Работа > Управление kvm qemu через web. Обзор полезного софта для управления виртуализацией

Управление kvm qemu через web. Обзор полезного софта для управления виртуализацией

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

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.

Заключение

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

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

В Ubuntu рекомендуется использовать гипервизор (менеджер виртуальных машин) KVM и библиотеку libvirt в качестве инструментария управления им. Libvirt включает в себя набор программного API и пользовательских приложений управления виртуальными машинами (ВМ) virt-manager (графический интерфейс, GUI) или virsh (командная строка, CLI). В качестве альтернативных менеджеров можно использовать convirt (GUI) или convirt2 (WEB интерфейс).

В настоящее время в Ubuntu офицально поддерживается только гипервизор KVM. Этот гипервизор является частью кода ядра операционной системы Linux. В отличие от Xen, KVM не поддерживает паравиртуализацию, то есть, для того, чтобы его использовать, ваш CPU должен подерживать технологии VT. Вы можете проверить, поддерживает ли ваш процессор эту технологию, выполнив команду в терминале:

Если в результате получили сообщение:

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

значит KVM будет работать без проблем.

Если же на выходе получили сообщение:

Your CPU does not support KVM extensions KVM acceleration can NOT be used

то вы всё равно сможете использовать виртуальную машину, но работать она будет намного медленнее.

    Устанавливать в качестве гостевых 64-битные системы

    Выделять гостевым системам более 2 Гбайт ОЗУ

Установка

Sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Это установка на сервер без X-ов, т. е. не включает в себя графический интерфейс. Установить его можно командой

Sudo apt-get install virt-manager

После этого в меню появится пункт «Менеджер виртуальных машин» и, с большой долей вероятности, всё заработает. Если какие-то проблемы всё же возникнут, то нужно будет почитать инструкцию в англоязычной вики.

Создание гостевой системы

Процедура создания гостевой системы с помощью графического интерфейса достаточно проста.

А вот текстовый режим можно и описать.

qcow2

При создании системы с помощью графического интерфейса в качестве жёсткого диска предлагается либо выбрать уже существующий файл-образ или блочное устройсво, либо создать новый файл с сырыми (RAW) данными. Однако, это далеко не единственный доступный формат файлов. Из всех перечисленных в man qemu-img типов дисков наиболее гибким и современным является qcow2 . Он поддерживает снапшоты, шифрование и сжатие. Его необходимо создавать до того, как создать новую гостевую систему.

Qemu-img create -o preallocation=metadata -f qcow2 qcow2.img 20G

Согласно тому же man qemu-img , предварительное размещение метаданных (-o preallocation=metadata) делает диск изначально немного больше, но обеспечивает лучшую производительность в те моменты, когда образу нужно расти. На самом деле, в данном случае эта опция позволяет избежать неприятного бага. Создаваемый образ изначально занимает меньше мегабайта места и по мере необходимости растёт до указанного размера. Гостевая система сразу должна видеть этот окончательный указанный размер, тем не менее, на этапе установки она может увидеть реальный размер файла. Естественно, устанавливаться на жёсткий диск размером 200 кбайт она откажется. Баг не специфичен для Ubuntu, проявляется ещё в RHEL, как минимум.

Кроме типа образа впоследствии можно будет выбрать способ его подключения - IDE, SCSI или Virtio Disk. От этого выбора будет зависеть производительность дисковой подсистемы. Однозначно правильного ответа нет, выбирать нужно исходя из задачи, которая будет возложена на гостевую систему. Если гостевая система создаётся «на посмотреть», то сойдёт любой способ. Вообще, обычно именно I/O является узким местом виртуальной машины, поэтому при создании высоконагруженной системы к этому вопросу нужно отнестись максимально ответственно.

С обычными 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 точек.

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

Требование к оборудованию (удаленный клиент) Pentium III 1Ghz
Интерфейсы Локальная консоль Клавиатура 1 × Mini-DIN-6 F(Purple)
Видео 1 × HDB-15 F(Blue)
Мышь 1 × HDB-15 F(green)
Системный (KVM) 1 × SPHD-15 F(Yellow)
LAN-порт 1 × RJ-45(F)
Power on the net (reserved) 1 × DB9(M)
Интерфейс питания 1
Кнопки/переключатели KVM Reset 1 × полускрытый,спереди
Индикаторы питания 1 × orange
подключение удаленного пользователя 1 × green
LAN 10/100 Mbps 1 × green / orange
Поддерживаемые протоколы 10baseT Ethernet and 100baseTX Fast Ethernet. TCP/IP
Разрешения видео Up to 1600×1200 60Hz
Корпус металлический
Размеры (длина × ширина × высота) 200 × 80 × 25mm

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

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

  • 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.

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


Рекомендуем также