В жизни сисадмина однажды настает момент, когда приходится с нуля разворачивать инфраструктуру предприятия либо переделывать уже имеющуюся, перешедшую по наследству. В этой статье я расскажу о том, как правильно развернуть гипервизор на основе Linux KVM и libvirt c поддержкой LVM (логических групп).

Мы пройдемся по всем тонкостям управления гипервизором, включая консольные и GUI-утилиты, расширение ресурсов и миграцию виртуальных машин на другой гипервизор.

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

Системные администраторы, работающие вплотную с виртуализацией на предприятии, мастера и виртуозы своего дела, поделились на два лагеря. Одни — приверженцы высокотехнологичной, но безумно дорогой VMware для Windows. Другие — любители open source и бесплатных решений на основе Linux VM. Можно долго перечислять преимущества VMware, но здесь мы остановимся на виртуализации, основанной на Linux VM.

 

Технологии виртуализации и требования к железу

Сейчас есть две популярные технологии виртуализации: Intel VT и AMD-V. В Intel VT (от Intel Virtualization Technology) реализована виртуализация режима реальной адресации; соответствующая аппаратная виртуализация ввода-вывода называется VT-d. Часто эта технология обозначается аббревиатурой VMX (Virtual Machine eXtension). В AMD создали свои расширения виртуализации и первоначально называли их AMD Secure Virtual Machine (SVM). Когда технология добралась до рынка, она стала называться AMD Virtualization (сокращенно AMD-V).

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

WWW

Вот полезный список процессоров с поддержкой технологии виртуализации.

Среди других требований гипервизоров — поддержка аппаратного RAID (1, 5, 10), которая повышает отказоустойчивость гипервизора при выходе жестких дисков из строя. Если поддержки аппаратного RAID нет, то можно использовать программный на крайний случай. Но RAID — это мастхэв!

Решение, описанное в этой статье, несет на себе три виртуальные машины и успешно работает на минимальных требованиях: Core 2 Quad Q6600 / 8 Гбайт DDR2 PC6400 / 2 × 250 Гбайт HDD SATA (хардверный RAID 1).

 

Установка и настройка гипервизора

Я покажу, как настраивать гипервизор, на примере Debian Linux 9.6.0 — Х64-86. Ты можешь использовать любой дистрибутив Linux, который тебе по душе.

Когда ты определишься с выбором железа и его наконец-то привезут, придет время ставить гипервизор. При установке ОС все делаем, как обычно, за исключением разметки дисков. Неопытные администраторы часто выбирают опцию «Автоматически разбить все дисковое пространство без использования LVM». Тогда все данные будут записаны на один том, что нехорошо по нескольким причинам. Во-первых, если жесткий диск выйдет из строя, ты потеряешь все данные. Во-вторых, изменение файловой системы доставит массу хлопот.

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

 

Logical Volume Manager

Менеджер логических томов (LVM) — это подсистема, доступная в Linux и OS/2, построенная поверх Device Mapper. Ее задача — представление разных областей с одного жесткого диска или областей с нескольких жестких дисков в виде одного логического тома. LVM создает из физических томов (PV — Phisical Volumes) логическую группу томов (VG — Volumes Group). Она, в свою очередь, состоит из логических томов (LV — Logical Volume).

Сейчас во всех дистрибутивах Linux с ядром 2.6 и выше есть поддержка LVM2. Для использования LVM2 на ОС с ядром 2.4 надо устанавливать патч.

После того как система обнаружила жесткие накопители, запустится менеджер разбивки жестких дисков. Выбираем пункт Guided — use entire disk and set up LVM.

Guided — use entire disk and set up LVM
Guided — use entire disk and set up LVM

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

Выбор диска для LVM
Выбор диска для LVM

Система предложит варианты разметки носителя. Выбираем «Записать все файлы на один раздел» и идем дальше.

Записать все файлы на один раздел
Записать все файлы на один раздел

Система оповестит о том, что необходимо сохранить созданные изменения при разметке. Смело соглашаемся, выбрав Yes.

Запись сохраненных изменений при разметке
Запись сохраненных изменений при разметке

После сохранения изменений мы получим одну логическую группу и два тома в ней. Первый — это корневой раздел, а второй — это файл подкачки. Тут многие зададут вопрос: а почему не выбрать разметку вручную и не создать LVM самому?

Я отвечу просто: при создании логической группы VG загрузочный раздел boot не пишется в VG, а создается отдельным разделом с файловой системой ext2. Если этого не учесть, то загрузочный том окажется в логической группе. Это обречет тебя на мучения и страдания при восстановлении загрузочного тома. Именно поэтому загрузочный раздел отправляется на том без LVM.

Состояние дисков после разметки
Состояние дисков после разметки

Переходим к конфигурации логической группы для гипервизора. Выбираем пункт «Конфигурация менеджера логических томов».

Конфигурация менеджера логических томов
Конфигурация менеджера логических томов

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

Запись сохраненных изменений при разметке
Запись сохраненных изменений при разметке

Далее в менеджере логических томов удаляем сначала созданные логические тома vg-<hostname>_root и vg-<hostname>_swap. А потом и саму логическую группу vg-<hostname>.

Создадим новую группу — к примеру, назовем ее vg_sata.

Создание новой логической группы
Создание новой логической группы

INFO

В серверах используются носители SATA, SSD, SAS, SCSI, NVMe. Хорошим тоном при создании логической группы будет указывать не имя хоста, а тип носителей, которые используются в группе. Советую логическую группу назвать так: vg_sata, vg_ssd, vg_nvme и так далее. Это поможет понять, из каких носителей построена логическая группа.

Указание имени для новой логической группы
Указание имени для новой логической группы

Далее выберем место на физическом томе, где будет размещена новая логическая группа. В данном случае спутать физический том не получится: загрузочный раздел помечен файловой системой ext2.

Выбор физического тома для размещения логической группы
Выбор физического тома для размещения логической группы

Создаем наш первый логический том. Это будет том для корневого раздела операционной системы. Выбираем пункт «Создать логический том».

Создание логического тома
Создание логического тома

Выбираем группу для нового логического тома. У нас она всего одна.

Выбор логической группы для нового тома
Выбор логической группы для нового тома

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

Задаем название нового тома
Задаем название нового тома

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

Задаем название нового тома
Задаем название нового тома

По аналогии с примером выше создаем следующие логические тома:

  • vg_sata_home — 20 Гбайт под каталоги пользователей;
  • vg_sata_opt — 10 Гбайт для установки прикладного ПО;
  • vg_sata_var — 10 Гбайт для часто меняющихся данных, к примеру логов системы и других программ;
  • vg_sata_tmp — 5 Гбайт для временных данных, если объем временных данных велик, можно сделать и больше. В нашем примере этот раздел не создавался за ненадобностью;
  • vg_sata_swap — равен объему оперативной памяти. Это раздел для свопа, и создаем мы его для подстраховки — на случай, если закончится оперативная память на гипервизоре.

После создания всех томов завершаем работу менеджера.

Завершение работы менеджера логических томов
Завершение работы менеджера логических томов

Теперь имеем несколько томов для создания разделов операционной системы. Нетрудно догадаться, что для каждого раздела есть свой логический том.

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

Создаем одноименный раздел под каждый логический том.

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

Сохраняем и записываем проделанные изменения.

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

После сохранения изменений разметки диска начнут ставиться базовые компоненты системы, а затем будет предложено выбрать и установить дополнительные компоненты системы. Из всех компонентов нам понадобится ssh-server и стандартные системные утилиты.

Выбор дополнительных компонентов
Выбор дополнительных компонентов

После установки будет сформирован и записан на диск загрузчик GRUB. Устанавливаем его на тот физический диск, где сохранен загрузочный раздел, то есть /dev/sda.

Предложение записать загрузчик на диск
Предложение записать загрузчик на диск
Выбор диска для записи загрузчика
Выбор диска для записи загрузчика

Теперь ждем, пока закончится запись загрузчика на диск, и после оповещения перезагружаем гипервизор.

Запись загрузчика
Запись загрузчика
Сообщение об окончании установки системы
Сообщение об окончании установки системы

После перезагрузки системы заходим на гипервизор по SSH. Первым делом под рутом устанавливаем нужные для работы утилиты.

$ sudo apt-get install -y sudo htop screen net-tools dnsutils bind9utils sysstat telnet traceroute tcpdump wget curl gcc rsync

Настраиваем SSH по вкусу. Советую сразу сделать авторизацию по ключам. Перезапускаем и проверяем работоспособность службы.

$ sudo nano /etc/ssh/sshd_config
$ sudo systemctl restart sshd; sudo systemctl status sshd

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

$ sudo pvscan
$ sudo lvs

Устанавливаем компоненты виртуализации и утилиты для создания сетевого моста на интерфейсе гипервизора.

$ sudo apt-get update; apt-get upgrade -y
$ sudo apt install qemu-kvm libvirt-bin libvirt-dev libvirt-daemon-system libvirt-clients virtinst bridge-utils

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

$ sudo nano /etc/network/interfaces

Содержимое будет примерно таким:

auto br0
iface br0 inet static
address 192.168.1.61
netmask 255.255.255.192
gateway 192.168.1.1
broadcast 192.168.0.61
dns-nameserver 127.0.0.1
dns-search xakep.ru
bridge_ports enp2s0
bridge_stp off
bridge_waitport 0
bridge_fd 0

Добавляем нашего пользователя, под которым будем работать с гипервизором, в группы libvirt и kvm (для RHEL группа называется qemu).

$ sudo gpasswd -a iryzhevtsev kvm
$ sudo gpasswd -a iryzhevtsev libvirt

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

$ sudo virsh pool-list
$ sudo virsh pool-define-as vg_sata logical --target /dev/vg_sata
$ sudo virsh pool-start vg_sata; sudo virsh pool-autostart vg_sata
$ sudo virsh pool-list

INFO

Для нормальной работы группы LVM с QEMU-KVM требуется сначала активировать логическую группу через консоль virsh.

Теперь скачиваем дистрибутив для установки на гостевые системы и кладем его в нужную папку.

$ sudo wget https://mirror.yandex.ru/debian-cd/9.5.0/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso
$ sudo mv debian-9.5.0-amd64-netinst.iso /var/lib/libvirt/images/; ls -al /var/lib/libvirt/images/

Чтобы подключаться к виртуальным машинам по VNC, отредактируем файл /etc/libvirt/libvirtd.conf:

$ sudo grep "listen_addr = " /etc/libvirt/libvirtd.conf

Раскомментируем и изменим строчку listen_addr = "0.0.0.0". Сохраняем файл, перезагружаем гипервизор и проверяем, все ли службы запустились и работают.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Дырявые диски. Эксплуатируем уязвимости в сетевых хранилищах Synology

Защита данных, приватность и соответствие нормам безопасного хранения информации — то, над…

8 комментариев

  1. Аватар

    zebrik

    13.12.2018 at 22:31

    Просто буря негодования. Кто-нибудь статью читал перед публикацией? Это ж статья в номер, а не просто новость!?

    Сначала речь о 2 винтах в аппаратном рейде (откуда на десктопной материнке аппаратный рейд? Аппаратный рейд будет стоить больше, чем весь этот конфиг) потом их раздельно добавляют в лвм отдельными томами.

    Почему рейд — мастхэв? Эта безапелляционная бравада глупа. Рейд — это инструмент. Не всегда ко всему подходящий.

    Если уже и собирать из г.на и палок, то mdadm будет поинформативнее интел рейда.

    Почему rsync, который оперирует файлами заявлен как отстой, а dd, который будет лить в том числе свободные участки файловой системы — как спасение?

    Чем определен выбор пакета в dd в 16м? Jumbo mtu? У вас диски с сектором в 16м? Вот эти 250ки? (Чудо, если не IDEшные)

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

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

    Виртуализация на таком слабом железе не имеет вообще практического смысла.

    Не знаю, какие медные трубы прошел автор, имхо это копипаста инструкции к lvm и kvm. Причем с большим количеством спорных вещей.

    P.S. я не против kvm и lvm, но всему свое место. Не надо тянуть enterprise идеи в soho сегмент, да еще в виде мануала из очень непонятных решений!

  2. Аватар

    axel_verse

    14.12.2018 at 11:31

    Добавлю свои 5 копеек. Во первых, GRUB2 ещё в 2014 году научился встраиваться в LVM и MD. Так что если использовать схему «всё на одном разделе», выносить boot в отдельный раздел нет необходимости. Во вторых, в статье много букв про raid, но фактически он нигде не используется.

  3. Иван Рыжевцев

    Иван Рыжевцев

    14.12.2018 at 12:15

    Привет zebrik! Не ругай пианиста, он играет как может! Эта статья родилась у меня в голове, после того как очень людей которые заняты в сфере ИТ спрашивали меня про Linux KVM. Мол расскажи, как ставить, управлять и как модернизировать в случае если ресурсы заканчиваются.
    По поводу RAID могу сказать следующее, он должен быть — эта одна из гарантий твоего спокойствия. Представь что будет если у тебя на гипервизоре стоит всего один винт, и он посыпется? Страшно, правда? Поэтому надо использовать RAID, аппаратный или программный — это уже решать тебе. Задача одна — быстро устранить последствия аварии при выходе диска из строя (а главное, чтоб никто не заметил).
    Утилита dd выбрана не случайно, мы копируем блочное устройство. Попробуй записать его на другую машину в точности с помощью rsync и увидишь разницу. Плюс при передаче больших файлов rsync тратить на 30% больше времени. А время в нашей профессии слишком дорогой ресурс, чтобы его тратить в пустую.
    Дублировать вырезки команд из статьи не надо. Ее внимательно прочитать, сделать выводы, и попытаться реализовать решение. Это надо сделать хотя бы ради опыта и расширения своего кругозора. Кто стремится развиваться, меня поймет.
    По поводу железа скажу тебе, диски SATA :))) IDE в наше время ты уже днем с огнем не найдешь. Да, железка для реализации слабая, но ведь решение работает и на нем для примера. Понятное дело, что для предприятия никто не даст тебе использовать домашний десктоп. У тебя будет мощный сервер, а может и не один.

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

    • Аватар

      zebrik

      14.12.2018 at 18:35

      Насчет raid:
      1. Это не панацея.
      2. Он не отменяет бекап на случай смерти диска
      3. Не всякий рейд даёт мониторить смарт
      4. Зеркальный рейд не даст увидеть, что винт сыпет бэдами — они будут друг друга вытягивать. Массив развалится, когда оба диска будут вхлам. Без рейда на первом же бэде сервер будет колом вставать, посыпятся жалобы, диск заменят вовремя.
      5. Никто в маленьких-средних фирмах не меняет диски в рейдах по регламенту, как положено.
      6. Винты одномоментно почти не мрут. Гораздо чаще инфа умирает из-за бэдов.
      Рейд нужен там, где приостановка сервера на полчаса днем или вечером после работы основного персонала невозможна. Но им и эта статья ни к чему.

      Rsync:
      1. если устройство содержит только файлы, переносить rsync’ом пофайлово быстрее, чем блочным устройством.
      2. Чем rsync медленнее dd over nc? Где у rsync оверхед вырастет? Оверхед у ssh может, но rsync — это не только ssh. rsync тоже надо уметь готовить.

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

  4. Иван Рыжевцев

    Иван Рыжевцев

    15.12.2018 at 01:59

    Привет zebrik! Ты прав, резервное копирование никто не отменял. По поводу железа могу сказать, что перед тем как внедрять какое-то решение — надо хорошо ознакомиться с предложениями по железу на рынке и убедиться что железка многофункциональная и точно подойдет. Я писал об этом в начале статьи.
    Про RAID можно вообще написать отдельную статью. Мониторинг RAID это сложная задача и больная мазоль, на которую наверное наступал каждый администратор. Кстати ты подал мне идею, как нибудь напишу статейку наверное.
    По вопросу RSYNC vs DD скажу так, ты можешь пользоваться любым удобным для тебя инструментом, главное чтобы на выходе получился правильный результат. В моем случае копирование rsync немного тормозило, чем у dd. И главное, я должен быть уверен, что блочное устройство точно перенеслось на другую железку. Вот и все. Если у тебя еще есть вопросы можешь смело задавать.

  5. Аватар

    rnd77

    12.01.2019 at 20:17

    Добрый вечер. Это выглядит как какой-то чудовищный велосипед:) Почему бы не сделать гостевой диск как qcow2 image? Один или несколько, для всех нужных гостевых разделов если душа желает. Кончилось место, сделал ресайз средствами qemu. Да, в этом случае нужно стопать вмку и делать внутри гостя свой ресайз после рестарта (как и в вашем случае). Недостаточно гибко? Ок, давайте поднимем lvm внутри гостя, будем подсовывать ему новые образы без рестарта, гость внутри сам будет свою группу расширять. Мы получаем все плюшки qcow (sparsed disk, например) и возможность миграции гостей, в том числе «живой», средствами либвирта, а это гораздо быстрее и приятнее, чем указанный в статье набор приседаний и прыжков. Непременно хочется странного? Поднять SAN и засунуть его луны с хоста внутрь гостя, как скази диски, а еще лучше поставить инициатор внутрь гостя, мигрячиться это все будет с космической скоростью.:)

    • Иван Рыжевцев

      Иван Рыжевцев

      23.01.2019 at 22:29

      Добрый вечер rnd77!
      Моя статья, показывает один из примеров совместного использования технологий виртуализации и LVM на Linux. Написана она прежде всего для начинающий системных администраторов.
      С одной стороны я соглашусь с вами по поводу велосипеда. Можно использовать и qcow2. Это тоже хорошее решение и имеет свои преимущества. С другой стороны набор приседаний и прыжков требуется для практики и расширения кругозора администратора по KVM и libvirt. Каждый администратор должен перепробовать несколько решений и выбрать удобное для себя. По поводу SAN полностью согласен. Одна печаль — не во всех конторах есть деньги на такое удобное решение.

Оставить мнение