Управление виртуальными машинами kvm
Управление виртуальными машинами KVM из консоли
В предыдущей статье мы рассмотрели установку гипервизора KVM и создание виртуальной машины. В рамках одной статьи, мы не смогли охватить все нюансы управления виртуальными машинами, а затронули лишь их часть. Сегодня, мы постараемся рассказать все об управлении виртуальными машинами из консоли сервера: как изменить параметры ВМ, добавить дополнительные устройства и рассмотрим основные команды, которые используются для администрирования виртуальных машин KVM.
Virsh: команды управления виртуальной машиной KVM
Первый вопрос, который возникает у начинающего администратора KVM: как увидеть созданные виртуальные машины, как остановить, запустить и удалить их. Для управления ВМ в KVM из консоли можно использовать утилиту virsh (использует libvirt API). С помощью утилиты virsh можно выполнить практически все операции с виртуальными машинами KVM.
# virsh list – показать список запущенных ВМ
Как видно из скриншота, в первом случае отключенная ВМ не была отображена.
# virsh shutdown — выключить виртуальную машину
# virsh start — запустить виртуальную машину
# virsh suspend — приостановить виртуальную машину
# virsh resume — запустить приостановленную виртуальную машину
# virsh reboot — перезапустить виртуальную машину
# virsh destroy — уничтожить виртуальную машину
# virsh undefine — удалить машину из списка и удалить все файлы, принадлежащие ей (обычно применяется после выполнения команды virsh destroy).
# virsh vcpuinfo — информация о процессоре на виртуальной машине (информацию о железе физического Linux сервера можно получить так)
Еще несколько команд по получению различной информации о виртуальной машине:
# virsh domid — получить идентификатор виртуальной машины
# virsh domuuid — получить UUID виртуальной машины
# virsh dominfo — получить сведения о виртуальной машине
# virsh domstate — просмотр состояния виртуальной машины
# virsh dumpxml — вывести файл конфигурации указанной виртуальной машины в XML формате
Добавление памяти и vCPU виртуальной машине KVM
В консоли KVM вы можете добавить или уменьшить ресурсы процессора и памяти, выделенные для ВМ двумя способами:
Если виртуальная машина запущена, ее нужно остановить:
# virsh shutdown test-centos
Теперь с помощью virsh изменим количество виртуальных процессоров до 6 (vCPU):
— количество ядер процессора
Но при применении этой команды, у меня сразу же появилась ошибка:
Мы не можем установить количество ядер процессора, больше, чем максимальное количество. Чтобы увеличить максимальное количество ядер ВМ, выполните команду:
Повторите первую команду и запустите виртуальную машину:
Проверим количество процессоров в настройках ВМ: овленное количество процессоров:
# virsh dumpxml test-centos
Аналогичным образом добавим память виртуальной машине:
Все по той же причине, сразу же вышла ошибка:
Увеличим максимальное значение памяти::
Теперь можно увеличить память ВМ.
Перед всеми изменениями не забывайте останавливать ВМ, а после запускать ее.
Также вы можете изменить ресурсы ВМ KVM через ее конфигурационный XML файл. Можно изменить файл в режиме онлайн или же сделав бэкап XML файла ВМ, изменить его и применить к виртуальной машине.
Отредактируем XML файл ВМ в онлайн режиме:
В открывшемся редакторе vi внесите изменения, нажав кнопку “Insert”.
Например, зададим для ВМ 2 ядра и 1Гб памяти:
Сохраните изменения в файле и перезапустите ВМ:
Проверьте настройки ВМ:
Тоже самое можно сделать, сделав бэкап XML файла:
# virsh dumpxml > /root/test.xml
# vi /root/test.xml
Измените нужные вам параметры, сохраните файл и примените к виртуальной машине:
# virsh shutdown test-centos
# virsh define /root/test.xml
# virsh start test-centos
KVM: добавление диска в виртуальную машину
В одной из наших статей, мы описывали процесс расширения и уменьшения дисков виртуальных машин в KVM. Но мы не описывали вариант по добавлению дополнительного диска.
Сначала нужно создать дополнительный файл диска для виртуальной машины:
Вместо qcow2 вы можете указать нужный формат диска, так же нужно указать путь до файла. У меня хранилище для дисков /vz/disk/.
После этого, можно добавить устройство виртуального диска к самой ВМ:
Остановите и запустите ВМ, проверьте что получилось:
# virsh shutdown test-centos
# virsh start test-centos
# virsh dumpxml test-centos
Как видим, диск добавлен. После данных манипуляций, на виртуальной машине нужно разметить этот диск под ваши нужды.
KVM: добавление сетевой карты для виртуальной машины
Попрьуем добавить дополнительный сетевой интерфейс для ВМ. Сначала проверим, какие сетевые интерфейсы созданы на хосте:
У меня на KVM сервере создана одна виртуальная машина, с одним сетевым интерфейсом. К br0 нам нужно прикрепить еще один виртуальный сетевой интерфейс. Выполните команды:
Проверьте, что у ВМ появился дополнительный сетевой интерфейс:
Также вы можете изменить сетевые настройки виртуальной машины напрямую через XML файл: # virsh edit test-centos
После первого сетевого интерфейса добавьте следующие строки:
Сохраните файл и запустите ВМ. Остальную конфигурацию, KVM добавит сам (mac address и тд).
В данной статье мы затронули основные моменты, которые могут вам понадобиться при управлении виртуальными машинами KVM из консоли Linux сервера. В следующей статье мы рассмотрим управление виртуальными машинами через графический менеджер virt-manager.
Работа с виртуальными машинами KVM. Подготовка хост-машины
Вступление
Как и было обещано в предыдущей статье, сегодня мы поговорим о базовой настройке хост-машины для работы KVM.
Для начала необходимо узнать, есть ли у нашего процессора необходимые инструкции для поддержки виртуализации.
$ egrep ‘(vmx|svm)’ /proc/cpuinfo
Если есть — это замечательно.
Подготовка операционной системы
Установку Debian Squeeze я, пожалуй, описывать не буду: если уж вы добрались до KVM, то установка системы — плёвое дело.
Устанавливать нужно будет 64-битную OS, поскольку необходимые пакеты есть только для этой архитектуры.
В Debian Squeeze «свежесть» пакетов с KVM и сопутствующих программами нас совсем не устраивает, поскольку очень много всяких фиксов и фич попросту пройдут мимо нас. Поэтому мы добавим репозитории Debian Sid и experimental:
deb http://ftp.ru.debian.org/debian sid main contrib non-free
deb-src http://ftp.ru.debian.org/debian sid main contrib non-free
deb http://ftp.ru.debian.org/debian experimental main contrib non-free
deb-src http://ftp.ru.debian.org/debian experimental main contrib non-free
Указываем, что у нас базовый дистрибутив stable, а не то, что подумала система:
# echo ‘APT::Default-Release «stable»;’ > /etc/apt/apt.conf.d/default
Оттуда нам понадобятся пакеты:
Из стабильного репозитория нам будут нужны:
# aptitude install uml-utilities bridge-utils
На вашем рабочем десктопе вы можете поставить virt-manager (GUI-утилита), который позволит удобно создавать нужные конфигурации виртуальных машин.
Ядро чем «свежее» — тем лучше (в известных пределах конечно: из git, например, я бы ставить не рекомендовал). Хорошим вариантом будет 2.6.39, вышедшее недавно.
Следует отметить, что в стандартном ядре отсутствует модуль для поддержки записи в UFS2, и если планируется запускать гостевую FreeBSD, потребуется собрать ядро с этим модулем. Ну и, конечно, в Debian-овском ядре отсутствуют свежие версии cgroups.
Что должно быть включено в ядре для использования максимального объема требуемого функционала:
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NET_CLS_CGROUP=y
Затем идём по ссылке и устанавливаем все deb-пакеты оттуда, копируем insmod.static в /sbin/insmod.static (это нужно, поскольку в работе libguestfs использует статически скомпилированную версию insmod, а в Debian и Ubuntu такого файла просто нет, однако в последней версиии febootstrap эту проблему устранили, insmod.static более не нужно загружать на сервер). libguestfs позволяет нам получать доступ к диску VDS через API libguestfs(C, Perl, Python, PHP) или через утилиту guestfish.
Первый блин
Сейчас мы установили все, необходимое для запуска VDS, их доступа в сеть и установки самой виртуальной машины.
Давайте попробуем что-нибудь поставить, например, тот же самый Debian. Пока без настройки сети, просто, по умолчанию.
Скачиваем установщик netinstall:
Редактируем /etc/libvirt/qemu.conf, чтобы виртуальные машины работали у нас от непривилегированного пользователя:
user = «username»
group = «libvirt»
Поскольку у нас будут использоваться tun-устройства, нужно выставить capability CAP_NET_ADMIN, сделать это можно как для отдельного исполняемого файла, так и для пользователя в целом, или настроить чтобы libvirt не сбрасывал нужные права для qemu/kvm.
Выставляем для отдельного файла:
sudo setcap cap_net_admin=ei /usr/bin/kvm
Или выставляем для пользователя в целом в файле /etc/security/capability.conf:
Или выставляем соответствующую настройку в /etc/libvirt/qemu.conf:
Добавим пользователя в группу libvirt и kvm:
# adduser username libvirt
# adduser username kvm
Запустим установку виртуальной машины:
Подробно разберём параметры, которые мы указали:
Утилиты настройки и управления
Для управления установкой и для клонирования виртуальных машин у нас есть две замечательные утилиты — графическая и консольная: virt-manager и virsh, соответственно. Конечно, консольная версия намного богаче по возможностям, но ничто не сравнится с видом графиков, от которых сердце сисадмина млеет.
Думаю с virt-manager вы и сами разберётесь, давайте попробуем покопаться в консольных внутренностях virsh. Вот несколько команд которые стоит выполнить и посмотреть что из этого получится:
Чтобы тысячу раз не писать —connect qemu:///system, добавьте:
export VIRSH_DEFAULT_CONNECT_URI= qemu:///system
Подготовка сети
В официальной документации предлагается использовать несколько вариантов организации сети: NAT, bridged и прямое использование сетевых карт. И, к сожалению, в различных примерах, которые я нашел в сети и на официальном сайте, рассматриваются только NAT и bridged сети.
В моей конфигурации используются TUN/TAP устройства, на которые с eth0 маршрутизируется трафик. Коротко опишу, почему выбран именно такой способ маршрутизации:
NAT нам не подходит, поскольку каждая VDS должна быть доступна из сети напрямую.
Схема с мостами не очень надёжная, поскольку теоретически есть возможность «захвата» IP адреса чужой виртуальной машины.
Итак:
Данный участок конфигурации нужно указывать непосредственно в конфигурационном файле гостя, расположенного по адресу /etc/libvirt/qemu/debian_guest.xml. Редактировать лучше всего через:
$ virsh edit debian_guest
Тогда конфигурация обновится на лету, при условии, что машина не запущена. В противном случае нужно будет подождать, пока она остановится, и запустить ее снова.
Создадим необходимое нам виртуальное устройство.
Для начала нам нужно дать нашему пользователю возможность беспарольного обращения к системным командам. Для этого добавим в sudoers:
Cmnd_Alias QEMU = /sbin/ifconfig, /sbin/modprobe, /usr/sbin/brctl, /usr/sbin/tunctl, /sbin/sysctl, /bin/ip, /usr/bin/cgcreate, /usr/bin/cgdelete, /sbin/tc
username ALL=(ALL:ALL) NOPASSWD: QEMU
Включим возможность форвардинга и проксирования arp-запросов:
sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv4.conf.all.proxy_arp=1
Также можно добавить эти параметры в /etc/sysctl.conf и применить их:
Создадим виртуальную сетевую карту и поднимем устройство:
Создадим маршрут на нужное нам устройство с нужного IP-адреса:
sudo ip route add 10.10.10.100 dev debian_guest
Теперь можно запустить VDS:
$ virsh start debian_guest
Подключившись к консоли, мы увидим, что сети нет, но у нас появилось устройство eth1, вместо eth0. Это произошло потому, что система при загрузке в /etc/udev/rules.d/70-persistent-net.rules прописывает mac-адрес сетевой карты, и если mac сменился, она создаёт ещё одну запись о сетевой карте, вроде этой:
SUBSYSTEM==»net», ACTION==»add», DRIVERS==»?*», ATTR
==»xx:xx:xx:xx:xx:xx», ATTRНужно удалить этот файл и перезагрузить VDS — после этого сетевая карта определится корректно.
Пропишем новые сетевые настройки в гостевой системе:
# ifconfig eth0 10.10.10.100 netmask 255.255.255.0
# route add default gw 10.10.10.10
10.10.10.10 — это IP-адрес хост-системы. Теперь мы сможем попинговать другие машины.
Добавим DNS-серверы в /etc/resolv.conf, и будет совсем замечательно:
К слову, замечу, что оказалось очень удобно называть сетевые устройства, принадлежащие VDS, также, как и сами VDS — отпадает необходимость искать, кому принадлежит устройство tap0 или vnet0, или как там ещё можно их обозвать.
Если понадобится выдать виртуальной машине ещё один IP-адрес, достаточно будет просто на хост-машине прописать ещё один маршрут:
# ip route add 10.10.10.101 dev debian_guest
А в гостевой системе создать алиас для сетевого устройства:
# ifconfig eth0:1 10.10.10.101
В следующей части
В следующей статье я расскажу о том, как создать образ VDS, что вообще меняется от системы к системе, и как эти параметры можно удобно менять.
Работа с виртуальными машинами KVM. Введение
Как и обещал, начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе KVM.
В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.
Debian
Почему Debian? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.
Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.
Мы же, повторюсь, решили использовать Debian Squeeze с набором пакетов из Sid/Experimental и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
В планах имеется публикация репозитория с пакетами.
При выборе технологии виртуализации рассматривались два варианта — Xen и KVM.
Замечу, что лично я не очень хорошо знаю Xen, его архитектуру и уж тем более мелкие особенности — в основном я знакомился с ним в качестве гостя. Нет повода сказать, что Xen чем-то плох (потому, что он ещё не полностью вошёл в ядро, или у него что-то не так с производительностью, или еще по какой-то причине). Ничего определённого нельзя сказать и в плане производительности: в каких-то тестах KVM на 10-20 процентов опережает Xen по всем показателям, а где-то выигрывает Xen. Фактически, на текущий момент они практически сравнялись по функционалу, производительности, надёжности. И в принципе, не за горами тот день, когда Xen также войдёт в ядро. Уже вошёл в состав ядра virtually-a-machine.blogspot.com/2011/06/xen-support-in-mainline-linux-kernel.html.
Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen — тем интереснее было провести в жизнь решение именно на базе KVM.
Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.
libvirt
Для управления виртуальными машинами оказалось чрезвычайно удобно использовать libvirt и продукты, использующие ее API: virsh, virt-manager, virt-install, пр.
libvirt — это система, которая хранит настройки виртуальных машин, управляет ими, ведёт по ним статистику, следит за тем, чтобы при старте у виртуальной машины поднимался интерфейс, подключает устройства к машине — в общем, выполняет кучу полезной работы и еще немножко сверх того.
Разумеется, решение не идеально. Из минусов libvirt следует назвать:
cgroups
Основной проблемой в реализации услуги в самом начале представлялось лимитирование ресурсов для виртуальных машин. В Xen эта проблема была решена при помощи внутреннего шедулера, распределяющего ресурсы между виртуальными машинами — и что самое прекрасное, была реализована возможность лимитировать и дисковые операции в том числе.
В KVM ничего такого не было до появления механизма распределения ресурсов ядра cgroups. Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup, в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.
Профит в том, что всё это реализуется внутри ядра, и использовать это можно не только для сервера, но и для десктопа (что и использовали в известном «The
200 Line Linux Kernel Patch That Does Wonders»). И на мой взгляд, это одно из самых значительных изменений в ветке 2.6, не считая любимого #12309, а не запиливание очередной файловой системы. Ну, разве что, кроме POHMELFS (но чисто из-за названия).
libguestfs
Отношение к этой библиотеке-утилите у меня весьма неоднозначное.
С одной стороны это выглядит примерно так:
И ещё эту штуку чертовски сложно собрать из исходников и тем более в пакет: иногда мне кажется, что Linux From Scratch собрать с нуля несколько проще.
С другой стороны — очень мощная штука, которая позволяет создавать образы для виртуальных машин, модифицировать их, ужимать, ставить grub, модифицировать таблицу разделов, управлять конфигурационными файлами, переносить «железные» машины в виртуальную среду, переносить виртуальные машины с одного образа на другой, переносить виртуальные машины из образа на железо и, честно говоря, тут меня фантазия немного подводит. Ах, да: ещё можно запустить демон внутри виртуальной машины Linux и получить доступ к данным виртуальной машины вживую, и всё это делать на shell, python, perl, java, ocaml. Это краткий и далеко не полный список того, что можно сделать с libguestfs.
Интересно, что большая часть кода в libguestfs генерируется в момент сборки, равно как и документация к проекту. Очень широко используется ocaml, perl. Сам код пишется на C, который потом оборачивается в OCaml, и повторяющиеся куски кода генерируются сами. Работа с образами осуществляется путём запуска специального сервисного образа (supermin appliance), в который через канал внутрь него отправляются команды. Внутри этого образа содержится некоторый rescue набор утилит, таких как parted, mkfs и прочих полезных в хозяйстве системного администратора.
Я с недавнего времени его даже дома стал использовать, когда выковыривал из образа nandroid нужные мне данные. Но для этого требуется ядро с поддержкой yaffs.
Прочее
Ниже приведено ещё несколько интересных ссылок на описание использованных пограммных средств — почитать и поизучать самостоятельно, если интересно. Например, про утилиту для массовой работы с конфигурационными файлами, KVM best practices от товарищей из IBM. Рекомендую!
В следующей части
Следующая часть будет про установку необходимых программ, и их базовую настройку.
Virsh — управление виртуальными машинами KVM
virsh — утилита для командной строки Linux, предназначенная для управления виртуальными машинами и гипервизорами KVM и Xen.
С помощью virsh вы можете сохранять состояние виртуальных машин, переносить ВМ между гипервизорами и управлять виртуальными сетями.
С virsh вы всегда можете получить список доступных команд или параметров, используя команду «help». «help command» даст вам дополнительную информацию по команде command.
Создание новой виртуальной машины
Перед тем, как вы сможете управлять виртуальной машиной с помощью virsh, вам нужно определить ее:
Указанная команда определяет новую виртуальную машину newvm. Чтобы увидеть ее в списке, вам нужно использовать ‘list —inactive’ или ‘list —all’, поскольку list без параметров покажет только уже запущенные ВМ.
Список ваших виртуальных машин
Virsh позволяет просмотреть виртуальные машины на данном узле командой list:
Создание, запуск, установка и уничтожение ВМ — define, undefine, start, shutdown, destroy
Виртуальные машины, которые вы видите с командой list —all — являются «defined». Каждая виртуальная машина настраивается через XML файл в каталоге /etc/libvirt/qemu. Если вы хотите удалить ВМ из списка определенных в системе виртуальных машин, вам нужно использовать команду undefine:
Чтобы выполнить undefine нужно предварительно остановить виртуальную машину:
Команда shutdown пытается завершить работу гостевой операционной системы, используя ACPI.
Вы также можете использовать destroy. Эта команда мгновенно отключит виртуальную систему, как если вы выключите кабель питания из компьютера.
Если вы изменили файл конфигурации виртуальной машины, вам нужно сообщить об этом KVM перед перезапуском ВМ.
Теперь можно запустить виртуальную машину:
Приостановка и продолжение работы виртуальных машин
Virsh позволяет приостановить и затем продолжить работу виртуальной машины
Изменение параметров виртуальной машины
libvirt stores it’s configuration as xml in ‘/etc/libvirt/qemu’. The xml is easy to understand, and is similar to VMware *.vmx files. While it is possible to edit these files in place and restart libvirt-bin for the changes to take affect, the recommended method for modifying the attributes of a virtual machine is via virsh (or virt-manager, if it supports changing the hardware you want to change). The concept is simple:
For example, to edit the machine named ‘foo’ (you can get a list of your machines with ‘virsh list —all’), do:
Добавление процессоров
KVM allows you to create SMP guests. To allocate two CPUs to a VM, dump the xml as above, then edit your xml to have:
Now define the VM as above.
Добавление памяти
To change the memory allocation in a VM, dump the xml as above, then edit your xml to have:
Now define the VM as above. Keep in mind that the memory allocation is in kilobytes, so to allocate 512MB of memory, use 512 * 1024, or 524288.
Изменение модели сетевой карты
kvm and qemu currently default to using the rtl8139 NIC. Supported NICs in Ubuntu 8.04 LTS are i82551, i82557b, i82559er, ne2k_pci, pcnet, rtl8139, e1000, and virtio. To use an alternate NIC, dump the xml as above, then edit your xml to have:
Now define the VM as above.
Добавление USB устройств
Ограничения для USB устройств в KVM
Изменение Apparmor
Для получения доступа к USB устройствам требуются изменения в настройках apparmor. Отредактируйте /etc/apparmor.d/abstractions/libvirt-qemu и раскомментируйте строки.:
После изменения настроек apparmor нужно перезапустить.:
Добавление USB устройства
Определите Vendor ID и Product ID.:
Получение новых ID
Чтобы получить новый MAC адрес для вставки в файл конфигурации виртуальной машины, используйте команду
Чтобы получить новый uuid для вашего xml файла, используйте: uuidgen