Product SiteDocumentation Site

Альт Сервер Виртуализации 9.2

Документация

Руководство пользователя

Редакция июль, 2021

Аннотация

Добро пожаловать в документацию дистрибутива Альт Сервер Виртуализации. Данное руководство предназначено как для начинающих, так и для опытных пользователей. Руководство описывает подготовку системы для установки, процесс установки дистрибутива, а также процедуру настройки и использования системы.
Названия компаний и продуктов, встречающихся в руководстве, могут являться торговыми знаками соответствующих компаний.
Данное руководство соответствует текущему состоянию сведений, но какие-либо окончательные правки могли не попасть в него. В случае обнаружения ошибок и неточностей в руководство вносятся изменения.
I. Что такое Альт Сервер Виртуализации?
1. Что такое Альт Сервер Виртуализации
2. Что такое Linux
2.1. Свободные программы
2.2. Разработка Linux
2.3. Защищённость
2.4. Дистрибутивы Linux
2.5. Новичку
3. Что такое системы Альт
3.1. ALT Linux Team
3.2. Сизиф
3.3. Что такое девятая платформа
II. Установка дистрибутива
4. Подготовка установочного диска
4.1. Запись ISO-образа дистрибутива на DVD
4.2. Запись установочного образа на USB Flash
5. Сохранение данных и меры предосторожности
6. Начало установки: загрузка системы
6.1. Способы первоначальной загрузки
6.2. Загрузка системы
7. Последовательность установки
8. Язык
9. Лицензионный договор
10. Дата и время
11. Подготовка диска
11.1. Выбор профиля разбиения диска
11.2. Автоматический профиль разбиения диска
11.3. Ручной профиль разбиения диска
11.4. Дополнительные возможности разбиения диска
12. Установка системы
12.1. Дополнительные приложения
12.2. Установка пакетов
13. Сохранение настроек
14. Установка загрузчика
15. Настройка сети
16. Администратор системы
17. Системный пользователь
18. Установка пароля на шифрованные разделы
19. Завершение установки
20. Обновление системы до актуального состояния
III. Начало использования Альт Сервер Виртуализации
21. Загрузка системы
22. Получение доступа к зашифрованным разделам
23. Вход в систему
IV. OpenNebula
24. Планирование ресурсов
24.1. Сервер управления
24.2. Серверы виртуализации
24.3. Хранилище данных
24.4. Сетевая инфраструктура
25. Запуск сервера управления OpenNebula
25.1. Установка пароля для пользователя oneadmin
25.2. Настройка MySQL (MariaDB) для хранения конфигурации
25.3. Запуск OpenNebula
25.4. Проверка установки
25.5. Ключи для доступа по SSH
25.6. Конфигурация сети
26. Добавление узлов в OpenNebula
26.1. Добавление узла в OpenNebula-Sunstone
26.2. Работа с узлами в командной строке
27. Управление пользователями
28. Работа с хранилищами в OpenNebula
29. Работа с образами в OpenNebula
29.1. Создание образа ОС в среде OpenNebula
29.2. Использование магазина приложений OpenNebula
30. Установка и настройка LXD
30.1. Настройка узла OpenNebula LXD
30.2. Добавление узла типа LXD в OpenNebula
30.3. Скачивание шаблона контейнера из магазина приложений
31. Настройка отказоустойчивого кластера
31.1. Первоначальная конфигурация Leader
31.2. Добавление дополнительных серверов
31.3. Добавление и удаление серверов
31.4. Восстановление сервера
31.5. Sunstone
V. Средство управления виртуальными окружениями PVE
32. Краткое описание возможностей
32.1. Веб-интерфейс
32.2. Хранилище данных
32.3. Сетевая подсистема
33. Установка и настройка PVE
33.1. Установка PVE
33.2. Настройка сетевой подсистемы
34. Создание кластера PVE
34.1. Настройка узлов кластера
34.2. Создание кластера в веб-интерфейсе
34.3. Создание кластера в консоли
34.4. Удаление узла из кластера
34.5. Кластерная файловая система PVE (pmxcfs)
35. Системы хранения PVE
35.1. Типы хранилищ в PVE
35.2. Конфигурация хранилища
35.3. Работа с хранилищами в PVE
36. Управление ISO образами и шаблонами LXC
37. Виртуальные машины на базе KVM
37.1. Создание виртуальной машины на базе KVM
37.2. Внесение изменений в ВМ
37.3. Управление ВМ с помощью qm
37.4. Файлы конфигурации ВМ
37.5. Запуск и останов ВМ
37.6. Автоматический запуск ВМ
37.7. Управление образами виртуальных дисков
38. Создание и настройка контейнера LXC
38.1. Создание контейнера в графическом интерфейсе
38.2. Создание контейнера из шаблона в командной строке
38.3. Изменение настроек контейнера
38.4. Запуск и останов контейнеров
38.5. Доступ к LXC контейнеру
39. Миграция ВМ и контейнеров
39.1. Миграция с применением графического интерфейса
39.2. Миграция с применением командной строки
39.3. Миграция ВМ из внешнего гипервизора
40. Клонирование ВМ
41. Резервное копирование (Backup)
41.1. Алгоритмы резервного копирования
41.2. Режимы резервного копирования
41.3. Резервное хранилище
41.4. Резервное копирование по расписанию
41.5. Настройка резервного копирования в графическом интерфейсе
41.6. Резервное копирование из командной строки
41.7. Снимки (snapshot)
42. Встроенный мониторинг PVE
43. Высокая доступность PVE
43.1. Как работает высокая доступность PVE
43.2. Требования для настройки высокой доступности
43.3. Настройка высокой доступности PVE
43.4. Тестирование настройки высокой доступности PVE
44. Пользователи и их права
VI. Управление виртуализацией на основе libvirt
45. Установка сервера
46. Утилиты управления
46.1. Утилита Virsh
46.2. Утилита virt-install
46.3. Утилита qemu-img
46.4. Менеджер виртуальных машин virt-manager
47. Подключение к гипервизору
47.1. Управление доступом к libvirt через SSH
47.2. Подключение к сессии гипервизора с помощью virsh
47.3. Настройка соединения с удаленным гипервизором в virt-manager
48. Создание виртуальных машин
48.1. Создание ВМ на основе файла конфигурации (утилита virsh)
48.2. Создание ВМ с помощью virt-install
48.3. Создание ВМ с помощью virt-manager
49. Запуск и управление функционированием ВМ
49.1. Управление состоянием ВМ в командной строке
49.2. Управление состоянием ВМ в менеджере виртуальных машин
49.3. Подключение к виртуальному монитору ВМ
50. Управление ВМ
50.1. Редактирование файла конфигурации ВМ
50.2. Получение информации о ВМ
50.3. Конфигурирование ВМ в менеджере виртуальных машин
50.4. Мониторинг состояния
50.5. Управление виртуальными сетевыми интерфейсами и сетями
50.6. Управление хранилищами
51. Миграция ВМ
51.1. Миграция с помощью virsh
51.2. Миграция ВМ в менеджере виртуальных машин
52. Снимки ВМ
52.1. Управления снимками ВМ в консоли
52.2. Управления снимками ВМ в менеджере виртуальных машин
53. Регистрация событий libvirt
54. Управление доступом в виртуальной инфраструктуре
VII. Kubernetes
55. Установка и настройка Kubernetes
55.1. Создание кластера Kubernetes
55.2. Тестовый запуск nginx
56. Кластер высокой доступности Kubernetes
56.1. Стековая (составная) топология etcd
56.2. Внешняя etcd-топология
56.3. Настройка HA-кластера etcd с помощью kubeadm
VIII. Настройка системы
57. Центр управления системой
57.1. Описание
57.2. Применение центра управления системой
57.3. Использование веб-ориентированного центра управления системой
IX. Работа с центром управления системой
58. Настройка подключения к Интернету
58.1. Конфигурирование сетевых интерфейсов
58.2. Настройка общего подключения к сети Интернет
58.3. Автоматическое присвоение IP-адресов (DHCP-сервер)
59. Доступ к службам сервера из сети Интернет
59.1. Внешние сети
59.2. Список блокируемых хостов
60. Статистика
60.1. Сетевой трафик
60.2. Прокси-сервер
61. Обслуживание сервера
61.1. Мониторинг состояния системы
61.2. Системные службы
61.3. Резервное копирование
61.4. Обновление системы
61.5. Обновление систем, не имеющих выхода в Интернет
61.6. Локальные учётные записи
61.7. Администратор системы
61.8. Дата и время
61.9. Ограничение использования диска
61.10. Выключение и перезагрузка компьютера
62. Прочие возможности ЦУС
63. Права доступа к модулям
X. Установка пакетов для опытных пользователей
Введение
64. Источники программ (репозитории)
64.1. Редактирование репозиториев
65. Поиск пакетов
66. Установка или обновление пакета
67. Удаление установленного пакета
68. Обновление системы
68.1. Обновление всех установленных пакетов
68.2. Обновление ядра
XI. Основы администрирования Linux
69. Общие принципы работы ОС
69.1. Процессы и файлы
69.2. Работа с наиболее часто используемыми компонентами
69.3. Стыкование команд в системе Linux
70. Режим суперпользователя
70.1. Какие бывают пользователи?
70.2. Для чего может понадобиться режим суперпользователя?
70.3. Как получить права суперпользователя?
70.4. Как перейти в режим суперпользователя?
71. Управление пользователями
71.1. Общая информация
71.2. Команда passwd
71.3. Добавления нового пользователя
71.4. Модификация пользовательских записей
71.5. Удаление пользователей
72. Система инициализации systemd и sysvinit
72.1. Запуск операционной системы
72.2. Системы инициализации systemd и sysvinit
72.3. Примеры команд управления службами, журнал в systemd
72.4. Журнал в systemd
73. Документация
73.1. Экранная документация
73.2. Документация по пакетам
XII. Техническая поддержка продуктов «Базальт СПО»
74. Покупателям нашей продукции
75. Пользователям нашей продукции

Часть I. Что такое Альт Сервер Виртуализации?

Глава 1. Что такое Альт Сервер Виртуализации

Операционная система Альт Сервер Виртуализации — многофункциональный дистрибутив для серверов, прежде всего, предназначен для создания виртуальной среды, обеспечивающей функционирование виртуальных машин и управление ими.
Альт Сервер Виртуализации представляет собой совокупность интегрированных программных продуктов, созданных на основе ОС Linux и обеспечивает обработку, хранение и передачу информации в круглосуточном режиме эксплуатации. Дистрибутив предоставляет интегрированную операционную систему на единой оптимизированной пакетной базе с поддержкой различных аппаратных платформ.
Включает в себя средства виртуализации:
  • вычислений (ЦПУ и память);
  • сети;
  • хранения данных.
Управление системой виртуализации возможно через командный интерфейс, веб-интерфейс, с использованием API.
Альт Сервер Виртуализации оснащён удобным пользовательским интерфейсом для настройки. Управление сервером может осуществляться с любого компьютера через веб-браузер.
ОС Альт Сервер Виртуализации включает в себя:
  • базовый гипервизор (libvirt + qemu-kvm);
  • кластер серверов виртуализации на основе проекта PVE;
  • облачную виртуализацию уровня предприятия на основе проекта OpenNebula;
  • контейнерную виртуализацию (docker, kubernetes, podman, lxd/lxc, rkt);
  • ПО для организации хранилища (ceph, glusterfs, moosefs, nfs, iscsi);
  • ПО для сети (openvswitch, haproxy, keepalived);
  • мониторинг (zabbix-agent, telegraf, collectd, monit, prometheus-node_exporter).

Глава 2. Что такое Linux

2.1. Свободные программы

Операционная система (далее — ОС) Linux — ядро, основные компоненты системы и большинство её пользовательских приложений — свободные программы. Свободные программы можно:
  • запускать на любом количестве компьютеров;
  • распространять бесплатно или за деньги без каких-либо ограничений;
  • получать исходные тексты этих программ и вносить в них любые изменения.
Свобода программ обеспечила их широкое использование и интерес к ним со стороны тысяч разработчиков. Основные программы для Linux выходят под лицензией GNU General Public License (далее — GPL). Лицензия GNU не только гарантирует свободу, но и защищает её. Она допускает дальнейшее распространение программ только под той же лицензией, поэтому исходный код ядра Linux, компиляторов, библиотеки glibc, пользовательских графических оболочек не может быть использован для создания приложений с закрытым кодом. В этом принципиальное отличие Linux от свободных ОС семейства BSD (FreeBSD, NetBSD, OpenBSD), фрагменты которых вошли в Microsoft Windows и даже стали основой OS X. Linux включает в себя многие разработки BSD, но его компиляторы и системные библиотеки разработаны в рамках проекта GNU (http://www.gnu.org/home.ru.html).

2.2. Разработка Linux

В отличие от распространённых несвободных ОС, Linux не имеет географического центра разработки. Нет фирмы, которая владела бы этой ОС, нет и единого координационного центра. Программы для Linux — результат работы тысяч проектов. Большинство из них объединяет программистов из разных стран, связанных друг с другом только перепиской. Лишь некоторые проекты централизованы и сосредоточены в фирмах. Создать свой проект или присоединиться к уже существующему может любой программист, и, в случае успеха, результаты этой работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую. Это позволяет за короткий срок добавлять в программное обеспечение новые возможности, оперативно находить ошибки и исправлять их.
Именно гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение независимых специалистов, обладающих индивидуальным, самостоятельным видением проблем, защита исходного текста программ лицензией GPL — всё это стало причиной успеха свободных программ.
Такая высокая эффективность разработки не могла не заинтересовать крупные фирмы. Они стали создавать свои свободные проекты, основывающиеся на тех же принципах. Так появились Mozilla, LibreOffice, свободный клон Interbase, SAP DB. IBM способствовала переносу Linux на свои мейнфреймы.
Открытый код программ значительно снизил себестоимость разработки закрытых систем для Linux и позволил снизить цену решения для пользователя. Вот почему Linux стала платформой, часто рекомендуемой для таких продуктов, как Oracle, DB2, Informix, Sybase, SAP ERP, Lotus Domino.

2.3. Защищённость

ОС Linux унаследовала от UNIX надёжность и отличную систему защиты. Система разграничения доступа к файлам позволяет не бояться вирусов. Но всё же, программ без ошибок не бывает, и Linux не исключение. Благодаря открытости исходного кода программ, аудит системы может осуществить любой специалист без подписок о неразглашении и без необходимости работы в стенах нанявшей его компании. Сообщества разработчиков и пользователей свободных программ создали множество механизмов оповещения об ошибках и их исправления. Сообщить об ошибке и принять участие в её исправлении независимому программисту или пользователю так же просто, как специалисту фирмы-разработчика или автору проекта. Благодаря этому ошибки защиты эффективно выявляются и быстро исправляются.

2.4. Дистрибутивы Linux

Большинство пользователей для установки Linux используют дистрибутивы. Дистрибутив — это не просто набор программ, а готовое решение для выполнения различных задач пользователя, обладающее идентичностью установки, управления, обновления, а также едиными системами настройки и поддержки.

2.5. Новичку

Linux — самостоятельная операционная система. Все операционные системы разные: Linux — не Windows, не OS X и не FreeBSD. В Linux свои правила, их необходимо изучить и к ним необходимо привыкнуть. Терпение и настойчивость в изучении Linux обернётся значительным повышением эффективности и безопасности вашей работы. То, что сегодня кажется странным и непривычным, завтра понравится и станет нормой.
Не стесняйтесь задавать вопросы, ведь самый простой способ найти ответ — совет опытного специалиста. Взаимопомощь и общение — традиция в мире Linux. Всегда можно обратиться за помощью к сообществу пользователей и разработчиков Linux. Большинство вопросов повторяются, поэтому для начала стоит поискать ответ на свой вопрос в документации, затем в сети Интернет. Если вы не нашли ответа в перечисленных источниках, не стесняйтесь, пишите на форум или в списки рассылки так, как писали бы своим друзьям, и вам обязательно помогут.

Глава 3. Что такое системы Альт

3.1. ALT Linux Team

Команда ALT Linux (http://www.altlinux.org/ALT_Linux_Team) — это интернациональное сообщество, насчитывающее более 200 разработчиков свободных программного обеспечения.

3.2. Сизиф

Sisyphus (https://packages.altlinux.org/ru/Sisyphus/home) — наш ежедневно обновляемый банк программ (часто называемый репозиторий). На его основе создаются все дистрибутивы ALT. Поддерживаемая ALT Linux Team целостность Sisyphus, оригинальная технология сборки программ, утилита apt-get и её графическая оболочка synaptic позволяют пользователям легко обновлять свои системы и быть в курсе актуальных новостей мира свободных программ.
Ежедневно изменяющийся репозиторий содержит самое новое программное обеспечение со всеми его преимуществами и недостатками (иногда ещё неизвестными). Поэтому, перед обновлением вашей системы из Sisyphus, мы советуем взвесить преимущества новых возможностей, реализованных в последних версиях программ, и вероятность возникновения неожиданностей в работе с ними (http://www.altlinux.org/Sisyphus_changes).
Разработка Sisyphus полностью доступна. У нас нет секретных изменений кода и закрытого тестирования с подписками о неразглашении. То, что мы сделали сегодня, завтра вы найдёте в сети. По сравнению с другими аналогичными банками программ (Debian unstable, Mandriva Cooker, PLD, Fedora), в Sisyphus есть немало самобытного. Особое внимание уделяется защите системы, локализации на русский язык, полноте и корректности зависимостей.
Название Sisyphus (Сизиф) заимствовано из греческой мифологии. С кропотливым Сизифом, непрерывно закатывающим в гору камни, команду ALT Linux Team объединяет постоянная работа над усовершенствованием технологий, заложенных в репозиторий.
Sisyphus, в первую очередь, — открытая лаборатория решений. Если вам это интересно, если вы хотите дополнить Sisyphus новыми решениями, если вы считаете, что можете собрать какую-то программу лучше — присоединяйтесь к проекту ALT Linux Team (http://www.altlinux.org/Join).

3.3. Что такое девятая платформа

Как уже говорилось ранее, Sisyphus является часто обновляемым репозиторием, скорее предназначенным для разработчиков. Решением для тех пользователей, которым стабильность и предсказуемость работы системы важнее расширенной функциональности (а это в первую очередь начинающие и корпоративные пользователи), являются стабильные дистрибутивы Альт. Такие стабильные дистрибутивы базируются на стабильном срезе репозитория Sisyphus. Эти срезы называются платформами.
Девятая платформа (p9) была создана в июне 2019 года и её поддержка продлится до декабря 2023 года.

3.3.1. Основные новшества в девятой платформе

В репозитории доступны пакеты для создания современной инфраструктуры:
  • Поддержка новых архитектур — наряду с архитектурами x86, ALT p9 поддерживает 6 новых аппаратных архитектур;
  • Центр приложений — показ и установка не пакетов, а приложений (с показом снимков экрана, рейтингами, локализованным описанием);
  • Изменения в rpm и apt — в девятой платформе произошли серьёзные изменения в apt и rpm;
  • Офисный пакет LibreOffice доступен в двух видах — для экспериментаторов и продвинутых пользователей (версия Fresh) и для корпоративных заказчиков (версия Still);
  • Единый пакет samba (для обычных рабочих мест и для контроллеров домена Active Directory);
  • Поддержка актуальных алгоритмов ГОСТ.

Часть II. Установка дистрибутива

В этой части рассматривается процесс установки дистрибутива.

Глава 4. Подготовка установочного диска

Наиболее частый способ установки операционной системы на компьютер представляет собой установку с установочного DVD-диска. В этой главе описываются различные способы записи дистрибутива на DVD-диск.
Установочные образы являются гибридными, что позволяет производить установку, записав такой образ на USB Flash. О записи установочного образа на USB Flash также рассказано в этой главе.

4.1. Запись ISO-образа дистрибутива на DVD

4.1.1. Запись образа диска под операционной системой MS Windows

Файл ISO-образа диска — это файл специального формата, подготовленный для записи на диск. Для записи ISO-образа под операционной системой MS Windows используйте специальные программы: SCDWriter, Nero BurningROM и другие. Рекомендуем для записи использовать новые диски от известных производителей, таких как: Verbatim, TDK. Записанный на плохой диск образ может вызвать неразрешимые проблемы при установке.

4.1.1.1. Запись образа диска с помощью Small CD-Writer

Весь процесс записи установочного диска при помощи Small CD-Writer состоит из следующих шагов:
  • скачать образ дистрибутива;
  • скачать архив программы Small CD-Writer http://gluek.info/wiki/_media/software/scdwriter14.zip;
  • распаковать файлы программы из архива в любой каталог;
  • вставить чистый диск в привод;
  • войти в распакованный каталог и запустить программу SCDWriter.exe;
  • открыть пункт меню ДискЗаписать ISO-образ на диск и, в появившемся окне, указать путь к образу диска;
  • нажать кнопку Записать.
Окно программы Small CD-Writer

4.1.1.2. Запись образа диска с помощью Nero BurningROM

Процесс записи установочного диска при помощи Nero BurningROM состоит из следующих шагов:
  • скачать образ дистрибутива;
  • скачать программу Nero BurningROM с сайта производителя http://www.nero.com и установить её;
  • запустить программу и выбрать в списке устройств необходимый для записи CD/DVD дисковод;
  • нажать кнопку Открыть проект в главном окне. В появившемся окне выбрать необходимый ISO-образ для записи и нажать кнопку Открыть;
  • в окне Запись проекта (Записать образ) настроить необходимые параметры;
  • записать ISO-образа на диск, щёлкнув по кнопке Запись (Burn).

4.1.2. Запись образа диска под операционной системой Linux

Для записи ISO-образов можно использовать множество утилит и программ с графическим или текстовым интерфейсом. Наиболее удобно использовать программы K3b или Brasero, которые поставляются в комплекте любого дистрибутива операционной системы Linux.

4.1.2.1. Запись образа диска с помощью K3b

Весь процесс записи установочного диска при помощи K3b состоит из следующих шагов:
  • если программа k3b отсутствует, необходимо установить её в систему, используя стандартные для вашего дистрибутива инструменты установки программ;
  • запустить программу k3b. При правильных настройках программа сообщит об отсутствии проблем с системой и предложит перейти к записи на диск;
  • в меню главного окна Сервис (Service) выбрать пункт Записать образ DVD (Burn DVD image);
  • в появившемся окне Записать образ DVD (Burn DVD image) нажать на кнопку Выбор файла для записи. Откроется диалог, в котором необходимо выбрать ISO-образ для записи и после выбора нажать кнопку ОК;
  • программа k3b покажет информацию о ISO-файле и начнёт вычислять контрольную сумму. Эта операция может занять несколько минут. Полученную контрольную сумму можно сравнить с MD5SUM суммой на странице дистрибутива;
  • если контрольные суммы не совпадают, значит, для записи был выбран не тот файл или скачанный ISO-образ был испорчен во время передачи данных по сети;
  • если контрольные суммы совпадают, вставить диск для записи в дисковод. Дождаться активации кнопки Начать (Start);
  • нажать на кнопку Начать (Start).

4.2. Запись установочного образа на USB Flash

Предупреждение

Запись образа дистрибутива на flash-диск приведёт к изменению таблицы разделов на носителе, таким образом, если flash-диск выполнил функцию загрузочного\установочного устройства и требуется вернуть ему функцию переносного накопителя данных, то необходимо удалить все имеющиеся разделы на flash-диске и создать нужное их количество заново.
Для восстановления совместимости flash-диска с операционными системами семейства Windows может понадобиться также пересоздание таблицы разделов (например, при помощи parted). Нужно удалить таблицу GPT и создать таблицу типа msdos. Кроме того, должен быть только один раздел с FAT или NTFS.
Для создания загрузочного flash-диска понадобится файл ISO-образа установочного диска с дистрибутивом. ISO-образы установочных дисков являются гибридными (Hybrid ISO/IMG), что позволяет записать их на flash-накопитель.

4.2.1. В операционной системе Windows

Для создания загрузочного flash-диска под операционной системой MS Windows используйте специальные программы: ALT Media Writer, Win32 Disk Imager, ROSA Image Writer и другие.
ALT Media Writer — это инструмент, который помогает записывать образы ALT на портативные накопители, такие как flash-диски. Он может автоматически загружать образы из интернета и записывать их. Для записи образа на flash-диск необходимо:
  • скачать и установить ALT Media Writer;
  • вставить flash-диск в USB-разъем;
  • запустить ALT Media Writer;
  • выбрать дистрибутив и нажать кнопку Создать Live USB…:
    ALT Media Writer (altmediawriter)
    начнётся загрузка образа из интернета;
  • выбрать устройство (flash-диск);
  • после окончания загрузки нажать кнопку Записать на диск (если был отмечен пункт Записать образ после загрузки, запись образа начнётся автоматически).
Инструкция для записи образа в программе Win32 Disk Imager:
  • скачать и установить программу Win32 Disk Imager;
  • скачать образ дистрибутива;
  • вставить flash-диск в USB-разъем (размер flash-диска должен быть не меньше размера скачанного образа диска);
  • запустить Win32 Disk Imager;
  • в появившимся окне выбрать ISO-образ дистрибутива, выбрать устройство (flash-диск):
    Win32 Disk Imager
  • нажать кнопку Write для записи образа на flash-диск.
Инструкция для записи образа в программе ROSA Image Writer:
  • скачать архив с программой ROSA Image Writer;
  • распаковать файлы программы из архива в любой каталог;
  • скачать образ дистрибутива;
  • вставить flash-диск в USB-разъем (размер flash-диска должен быть не меньше размера скачанного образа диска);
  • запустить файл .exe;
  • в появившимся окне выбрать ISO-образ дистрибутива, выбрать устройство (flash-диск):
    ROSA Image Writer
  • нажать кнопку Записать для записи образа на flash-диск.
Для записи образа на flash-диск подойдёт и утилита HDD Raw Copy Tool. На первом шаге нужно выбрать файл с образом диска:
Выбор файла с образом диска
На втором шаге нужно выбрать flash-диск, на который будет записан образ:
Выбор flash-диска

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!
После проверки правильности выбранных параметров и нажатия кнопки Continue можно приступать к записи, нажав кнопку START. По успешному завершению записи окно с индикацией процесса записи закроется, после чего можно закрыть и окно самой программы.

4.2.2. В операционной системе Linux

Для записи образа на flash-диск можно воспользоваться любой из трёх программ с графическим интерфейсом:
  • ALT Media Writer (altmediawriter):
    ALT Media Writer (altmediawriter)
    ALT Media Writer может автоматически загружать образы из интернета и записывать их, при необходимости извлекая сжатые образы (img.xz).
  • SUSE Studio Imagewriter (imagewriter):
    SUSE Studio Imagewriter (imagewriter)
  • ROSA Image Writer (rosa-imagewriter):
    ROSA Image Writer (rosa-imagewriter)
Для записи установочного образа можно воспользоваться утилитой командной строки dd:
dd oflag=direct if=<файл-образа.iso> of=/dev/sdX bs=1M status=progress
sync
где <файл-образа.iso> — образ диска ISO, а /dev/sdX — устройство, соответствующее flash-диску.
Для удобства показа прогресса записи можно установить пакет pv и использовать команду:
pv <файл-образа.iso> | dd oflag=direct of=/dev/sdX bs=1M;sync
где <файл-образа.iso> — образ диска ISO, а /dev/sdX — устройство, соответствующее flash-диску.
Просмотреть список доступных устройств можно командой lsblk или (если такой команды нет): blkid.
Например, так можно определить имя flash-диска:
$ lsblk | grep disk
sda      8:0    0 931,5G  0 disk
sdb      8:16   0 931,5G  0 disk
sdc      8:32   1   7,4G  0 disk
flash-диск имеет имя устройства sdc.
Затем записать:
# dd oflag=direct if=/iso/alt-server-v-9.2-x86_64.iso of=/dev/sdc bs=1M status=progress; sync
или, например, так:
# pv /iso/alt-server-v-9.2-x86_64.iso | dd oflag=direct of=/dev/sdc bs=1M;sync
dd: warning: partial read (524288 bytes); suggest iflag=fullblock
3GiB 0:10:28 [4,61MiB/s] [===================================>  ] 72% ETA 0:04:07

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

Предупреждение

Не добавляйте номер раздела, образ пишется на flash-диск с самого начала!

Предупреждение

Не извлекайте flash-диск, пока образ не запишется до конца! Определить финал процесса можно по прекращению моргания индикатора flash-диска либо посредством виджета "Безопасное извлечение съемных устройств". В консоли можно подать команду
eject /dev/sdX
и дождаться ее успешного завершения.

4.2.3. В операционной системе OS X

В операционной системе OS X для создания загрузочного flash-диска можно использовать команду:
sudo dd if=alt-server-v-9.2-x86_64.iso of=/dev/diskX bs=1M 
sync
где alt-server-v-9.2-x86_64.iso — образ диска ISO, а /dev/diskX — flash-диск.
Просмотреть список доступных устройств можно командой:
diskutil list

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

4.2.4. Проверка целостности записанного образа

Предупреждение

Внимание! Если речь идёт о записи на flash-диск образа LiveCD, проверка должна быть выполнена сразу же после записи на USB Flash, без запуска с него. Причина в том, что остаток flash-диска, при первом запуске LiveCD, форматируется, как r/w раздел, при этом меняется и таблица разделов.
Для проверки целостности записанного образа необходимо выполнить следующие шаги:
  • определить длину образа в байтах:
    $  du -b alt-server-v-9.2-x86_64.iso | cut -f1 
    2296233984
    
  • посчитать контрольную сумму образа (или просмотреть контрольную сумму образа из файла MD5SUM на сервере FTP):
    $ md5sum alt-server-v-9.2-x86_64.iso
    56e7330ee5a4bf3a4238a8f118c3b834  alt-server-v-9.2-x86_64.iso
    
  • подсчитать контрольную сумму записанного образа на DVD или USB Flash (выполняется под правами пользователя root):
    #  head -c 2296233984 /dev/sdd | md5sum
    56e7330ee5a4bf3a4238a8f118c3b834
    
    где размер после -c — вывод в п.1, а /dev/sdd — устройство DVD или USB Flash, на которое производилась запись.

Глава 5. Сохранение данных и меры предосторожности

Если необходимо установить ОС Альт Сервер Виртуализации и при этом сохранить уже установленную на компьютере операционную систему (например, другую версию GNU/Linux или Microsoft Windows), то нужно обязательно позаботиться о подготовке компьютера к установке второй системы и о сохранении ценных для вас данных.
Если у вас нет загрузочного диска для уже установленной системы, создайте его. В случае прерванной установки ОС Альт Сервер Виртуализации или неправильной настройки загрузчика, вы можете потерять возможность загрузиться в вашу предыдущую ОС.
Если на диске, выбранном для установки ОС Альт Сервер Виртуализации, не осталось свободного раздела, то программа установки должна будет изменить размер существующего раздела. От этой операции могут пострадать ваши данные, поэтому предварительно надо сделать следующие действия.
  • Выполнить проверку раздела, который вы собираетесь уменьшать. Для этого воспользуйтесь соответствующим программным обеспечением (далее — ПО), входящим в состав уже установленной ОС. Программа установки Альт Сервер Виртуализации может обнаружить некоторые очевидные ошибки при изменении размера раздела, но специализированное ПО предустановленной ОС справится с этой задачей лучше.
  • Выполнить дефрагментацию уменьшаемого раздела в целях повышения уровня безопасности данных. Это действие не является обязательным, но мы настоятельно рекомендуем его произвести: изменение размера раздела пройдёт легче и быстрее.

Предупреждение

Полной гарантией от проблем, связанных с потерей данных, является резервное копирование!

Глава 6. Начало установки: загрузка системы

6.1. Способы первоначальной загрузки

Для загрузки компьютера с целью установки системы необходимо воспользоваться носителем, содержащим начальный загрузчик.
Простейший способ запустить программу установки — загрузить компьютер с помощью загрузочного носителя, находящегося на установочном DVD с дистрибутивом (при условии, что система поддерживает загрузку с устройства для чтения DVD).
Также программу установки можно запустить с другого загрузочного носителя. Например, в качестве загрузочного носителя может использоваться загрузочный USB flash-накопитель.

6.2. Загрузка системы

Для того чтобы начать установку ОС Альт Сервер Виртуализации, достаточно загрузиться с носителя, на котором записан дистрибутив.

Примечание

Предварительно следует включить в BIOS опцию загрузки с оптического привода или с USB-устройства.
В большинстве случаев указание способа входа в BIOS отображается на вашем мониторе непосредственно после включения компьютера. Способ входа в меню BIOS и информация о расположении настроек определяется производителем используемого оборудования. За информацией можно обратиться к документации на ваше оборудование.
Загрузка
Загрузка с установочного диска или специально подготовленного USB-flash-накопителя начинается с меню, в котором перечислено несколько вариантов загрузки. Кроме установки системы с установочного диска, в данном меню доступны несколько вариантов сетевой установки.
  • Boot from hard drive as usual — запуск уже установленной на жестком диске операционной системы;
  • Install ALT (server-v) — установка операционной системы;
  • VNC install (edit to set server IP address) — установка по VNC с соединением с устанавливаемой машины на сервер VNC с заданным IP-адресом. Параметры установки по VNC передаются как параметры ядра. Нажатие клавиши Tab позволяет задать IP-адрес компьютера, с которого будет происходить управление (для приёма подключения на сервере VNC следует запустить, например, vncviewer --listen);
  • VNC install (<Tab>, set password and connect here) — установка по VNC с соединением в сторону устанавливаемой машины. Параметры установки по VNC передаются как параметры ядра. Нажатие клавиши Tab позволяет задать пароль (по умолчанию — VNCPWD);
  • Rescue LiveCD — восстановление уже установленной, но так или иначе поврежденной ОС Linux путем запуска небольшого образа ОС в оперативной памяти. Восстановление системы потребует некоторой квалификации. Этот пункт также может быть использован для сбора информации об оборудовании компьютера, которую можно отправить разработчикам, если ОС Альт Сервер Виртуализации устанавливается и работает неправильно. Загрузка восстановительного режима заканчивается приглашением командной строки:
    [root@localhost /]#
    
  • Memory Test — проверка целостности оперативной памяти. Процесс диагностики заключается в проведении нескольких этапов тестирования каждого отдельного модуля ОЗУ (данный процесс будет выполняться бесконечно, пока его не остановят, необходимо дождаться окончания хотя бы одного цикла проверки).

Примечание

Мышь на этом этапе установки не поддерживается. Для выбора опций установки и различных вариантов необходимо использовать клавиатуру.
Нажатие клавиши Tab позволяет вручную задать параметры, передаваемые ядру. Например,
  • nomodeset — не использовать modeset-драйверы для видеокарты;
  • vga=normal — отключить графический экран загрузки установщика;
  • xdriver=vesa — явно использовать видеодрайвер vesa. Данным параметром можно явно указать нужный вариант драйвера;
  • acpi=off noapic — отключение ACPI (управление питанием), если система не поддерживает ACPI полностью.
Параметры передаваемые ядру
Чтобы начать процесс установки, нужно клавишами перемещения курсора вверх и вниз, выбрать пункт меню Установка, и нажать Enter. Начальный этап установки не требует вмешательства пользователя: происходит автоматическое определение оборудования и запуск компонентов программы установки.

Примечание

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

Глава 7. Последовательность установки

До того, как будет произведена установка базовой системы на жёсткий диск, программа установки работает с образом системы, загруженным в оперативную память компьютера.
Если инициализация оборудования завершилась успешно, будет запущен графический интерфейс программы-установщика. Процесс установки разделён на шаги. Каждый шаг посвящён настройке или установке определённого свойства системы. Шаги нужно проходить последовательно. Переход к следующему шагу происходит по нажатию кнопки Далее. При помощи кнопки Назад, при необходимости, можно вернуться к уже пройденному шагу и изменить настройки. Однако возможность перехода к предыдущему шагу ограничена теми шагами, в которых нет зависимости от данных, введённых ранее.
Если по каким-то причинам возникла необходимость прекратить установку, необходимо нажать кнопку <Reset> на корпусе системного блока компьютера.

Примечание

Совершенно безопасно выполнить отмену установки только до шага «Подготовка диска», поскольку до этого момента не производится никаких изменений на жёстком диске. Если прервать установку между шагами «Подготовка диска» и «Установка загрузчика», существует вероятность, что после этого с жёсткого диска не сможет загрузиться ни одна из установленных систем (если такие имеются).
Технические сведения о ходе установки можно посмотреть, нажав Ctrl+Alt+F1, вернуться к программе установки — Ctrl+Alt+F7. По нажатию Ctrl+Alt+F2 откроется отладочная виртуальная консоль.
Каждый шаг сопровождается краткой справкой, которую можно вызвать, щёлкнув кнопку Справка или нажав клавишу F1.
Язык установщика по умолчанию — английский, иной надо выбирать вручную на первом шаге установки.

Глава 8. Язык

По умолчанию используется английский язык:
Язык
Установка Альт Сервер Виртуализации начинается с выбора основного языка — языка интерфейса программы установки и устанавливаемой системы. На этом этапе можно выбрать русский язык:
Язык
На этом же этапе выбирается вариант переключения раскладки клавиатуры. Раскладка клавиатуры — это привязка букв, цифр и специальных символов к клавишам на клавиатуре. Помимо ввода символов на основном языке, в любой системе Linux необходимо иметь возможность вводить латинские символы (имена команд, файлов и т.п.). Для этого обычно используется стандартная английская раскладка клавиатуры. Переключение между раскладками осуществляется при помощи специально зарезервированных для этого клавиш. Для русского языка доступны следующие варианты переключения раскладки:
  • клавиши Alt и Shift одновременно;
  • клавиша CapsLock;
  • клавиши Control и Shift одновременно;
  • клавиша Control;
  • клавиша Alt.
Если выбранный основной язык имеет всего одну раскладку (например, при выборе английского языка в качестве основного), эта единственная раскладка будет принята автоматически.

Глава 9. Лицензионный договор

Лицензионный договор
Перед продолжением установки следует внимательно прочитать условия лицензии. В лицензии говорится о ваших правах. В частности, за вами закрепляются права на:
  • эксплуатацию программ на любом количестве компьютеров и в любых целях;
  • распространение программ (сопровождая их копией авторского договора);
  • получение исходных текстов программ.
Если вы приобрели дистрибутив, то данное лицензионное соглашение прилагается в печатном виде к вашей копии дистрибутива. Лицензия относится ко всему дистрибутиву Альт Сервер Виртуализации. Если вы согласны с условиями лицензии, отметьте пункт Да, я согласен с условиями и нажмите кнопку Далее.

Глава 10. Дата и время

На данном этапе выполняется выбор страны и города, по которым будет определен часовой пояс и установлены системные часы.
Дата и время (выбор часового пояса)
Для корректной установки даты и времени достаточно правильно указать часовой пояс и выставить желаемые значения для даты и времени.
На этом шаге следует выбрать часовой пояс, по которому нужно установить часы. Для этого в соответствующих списках выберите страну, а затем регион. Поиск по списку можно ускорить, набирая на клавиатуре первые буквы искомого слова.
Пункт Хранить время в BIOS по Гринвичу выставляет настройки даты и времени в соответствии с часовыми поясами, установленными по Гринвичу, и добавляет к местному времени часовую поправку для выбранного региона.
После выбора часового пояса будут предложены системные дата и время по умолчанию.
Для ручной установки текущих даты и времени нужно нажать кнопку Изменить…. Откроется окно ручной настройки системных параметров даты и времени.
Дата и время
Для синхронизации системных часов с удалённым сервером времени (NTP) по локальной сети или по сети Интернет нужно отметить пункт Получать точное время с NTP-сервера и указать предпочитаемый NTP-сервер. В большинстве случаев можно указать сервер pool.ntp.org.
Если выбрана опция Получать точное время с NTP-сервера, то компьютер может и сам быть сервером точного времени. Например, использоваться как сервер точного времени машинами локальной сети. Для активации этой возможности необходимо отметить пункт Работать как NTP-сервер.
Для сохранения настроек и продолжения установки системы в окне ручной установки даты и времени необходимо нажать кнопку ОК и затем в окне Дата и время нажать кнопку Далее.

Примечание

В случае если ОС Альт Сервер Виртуализации устанавливается как вторая ОС, необходимо снять отметку с пункта Хранить время в BIOS по Гринвичу, иначе время в уже установленной ОС может отображаться некорректно.

Глава 11. Подготовка диска

На этом этапе подготавливается площадка для установки Альт Сервер Виртуализации, в первую очередь — выделяется свободное место на диске.
Переход к этому шагу может занять некоторое время. Время ожидания зависит от производительности компьютера, объёма жёсткого диска, количества разделов на нём и других параметров.

11.1. Выбор профиля разбиения диска

После завершения первичной конфигурации загрузочного носителя откроется окно Подготовка диска. В списке разделов перечислены уже существующие на жёстких дисках разделы (в том числе здесь могут оказаться съёмные flash-диски, подключённые к компьютеру в момент установки).
Подготовка диска
В списке Выберите профиль перечислены доступные профили разбиения диска. Профиль — это шаблон распределения места на диске для установки ОС. Можно выбрать один из профилей:
  • Minimal server — единственная файловая система ext4 под корень (swap и раздел под efi автоматически);
  • KVM Server — большой раздел под /var/lib/libvirt;
  • Docker Server — большой раздел под /var/lib/docker;
  • OCI Containers Server (Podman,CRI-O) — большой раздел под /var/lib/containers;
  • LXD Server — большой раздел под /var/lib/lxd;
  • PVE or OpenVZ Server — большой раздел под /var/lib/vz;
  • Generic Server — большой раздел под /var.
  • Вручную.
Все профили, кроме последнего предполагают автоматическое разбиение диска.

11.2. Автоматический профиль разбиения диска

Выбор автоматического профиля разбиения диска влияет на предлагаемый по умолчанию профиль устанавливаемого программного обеспечения.
Например, при выборе пункта KVM Server — при разбиении диска будут выделены отдельные разделы для подкачки и для корневой файловой системы. Оставшееся место будет отведено под раздел /var/lib/libvirt. Если результат вас по каким-то причинам не устраивает, прямо сейчас можно его отредактировать.
Выбор автоматического профиля разбиения диска
От возможности редактировать результат разбиения можно отказаться, сняв выделение с пункта Предложить сделать мои изменения после применения профиля. В этом случае никакой информации о распределении дискового пространства на экране отображаться не будет. После осуществления физических изменений на жестком диске начнется установка базовой системы. Этот вариант подойдет для установки на чистый диск.
Рядом с названием каждого профиля указан минимальный объём свободного места на диске, требуемый для установки в соответствии с данным профилем. Если при применении одного из профилей автоматического разбиения диска доступного места на диске окажется недостаточно, то на монитор будет выведено сообщение об ошибке: Невозможно создать все разделы, недостаточно места на диске. В этом случае можно воспользоваться методом ручной разметки: профиль Вручную или установить отметку на пункте Очистить все диски перед применением профиля.

Примечание

При отмеченном пункте Очистить все диски перед применением профиля будут удалены все данные со всех дисков (включая внешние USB-носители) без возможности восстановления. Рекомендуется использовать эту возможность при полной уверенности в том, что диски не содержат никаких ценных данных.

11.3. Ручной профиль разбиения диска

При необходимости освободить часть дискового пространства следует воспользоваться профилем разбиения Вручную. В этом случае можно удалить некоторые из существующих разделов или содержащиеся в них файловые системы. После этого можно создать необходимые разделы самостоятельно или вернуться к шагу выбора профиля и применить автоматический профиль. Выбор этой возможности требует знаний об устройстве диска и технологиях его разметки.
По нажатию кнопки Далее будет произведена запись новой таблицы разделов на диск и форматирование разделов. Только что созданные на диске программой установки разделы пока не содержат данных и поэтому форматируются без предупреждения. Уже существовавшие, но изменённые разделы, которые будут отформатированы, помечаются специальным значком в колонке Файловая система слева от названия. При уверенности в том, что подготовка диска завершена, подтвердите переход к следующему шагу нажатием кнопки Далее.
Не следует форматировать разделы с теми данными, которые вы хотите сохранить, например, со старыми пользовательскими данными (/home) или с другими операционными системами. С другой стороны, отформатировать можно любой раздел, который вы хотите «очистить» (удалить все данные).

Предупреждение

Не уменьшайте NTFS-раздел с установленной Microsoft Windows Vista/Windows 7 средствами программы установки. В противном случае вы не сможете загрузить Microsoft Windows Vista/Windows 7 после установки Альт Сервер Виртуализации. Для выделения места под установку Альт Сервер Виртуализации воспользуйтесь средствами, предоставляемыми самой Microsoft Windows Vista/Windows 7: Управление дискамиСжать.

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

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

11.4.1. Создание программного RAID-массива

Избыточный массив независимых дисков RAID (redundant array of independent disks) — технология виртуализации данных, которая объединяет несколько НЖМД в логический элемент для избыточности и повышения производительности.

Примечание

Для создания программного RAID-массива потребуется минимум два жёстких диска.
Программа установки поддерживает создание программных RAID-массивов следующих типов:
  • RAID 1;
  • RAID 0;
  • RAID 4/5/6;
  • RAID 10.
Процесс подготовки к установке на RAID условно можно разбить на следующие шаги:
  • создание разделов на жёстких дисках;
  • создание RAID-массивов на разделах жёсткого диска;
  • создание файловых систем на RAID-массиве.
Для настройки параметров нового раздела из состава RAID-массива необходимо выбрать неразмеченный диск в окне профиля разбивки пространства Подготовить разделы вручную и нажать кнопку Создать раздел.
Создание разделов для RAID-массива
При создании разделов на жёстких дисках для последующего включения их в RAID-массивы следует указать Тип раздела для них равным Linux RAID.

Примечание

При создании разделов следует учесть, что объём результирующего массива может зависеть от размера, включённых в него разделов жёсткого диска. Например, при создании RAID 1, результирующий размер массива будет равен размеру минимального участника.
После создания разделов на дисках можно переходить к организации самих RAID-массивов. Для этого в списке следует выбрать пункт RAID, после чего нажать кнопку Создать RAID.
Далее мастер предложит выбрать тип массива и указать его участников.
Выбор типа RAID-массива
Выбор участников RAID-массива
После создания RAID-массивов их можно использовать как обычные разделы на жёстких дисках, то есть, на них можно создавать файловые системы или же, например, включать их в LVM-тома.

11.4.2. Создание LVM-томов

Менеджер логических дисков LVM (Logical Volume Manager) — средство гибкого управления дисковым пространством, которое позволяет создавать поверх физических разделов (либо неразбитых дисков) логические тома, которые в самой системе будут видны как обычные блочные устройства с данными (обычные разделы).
Процесс подготовки к установке на LVM условно можно разбить на следующие шаги:
  • создание группы томов LVM;
  • создание томов LVM;
  • создание файловых систем на томах LVM.
Создание группы томов LVM

Важно

Для создания группы томов LVM может потребоваться предварительно удалить таблицу разделов с жёсткого диска.
Для создания группы томов LVM в списке следует выбрать пункт LVM, после чего нажать кнопку Создать группу томов.
Создание тома
После создания группы томов LVM её можно использовать как обычный жёсткий диск, то есть внутри группы томов можно создавать тома (аналог раздела на физическом жёстком диске) и файловые системы внутри томов.

11.4.3. Создание шифрованных разделов

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

Предупреждение

Установка загрузчика на шифрованный раздел не поддерживается.
Для сохранения всех внесенных настроек и продолжения установки в окне Подготовка диска нужно нажать кнопку Далее.

Глава 12. Установка системы

На данном этапе происходит распаковка ядра и установка набора программ, необходимых для работы Альт Сервер Виртуализации.
Программа установки предлагает выбрать дополнительные пакеты программ, которые будут включены в состав Альт Сервер Виртуализации и установлены вместе с ней на диск.

12.1. Дополнительные приложения

Выбор групп приложений
В дистрибутиве Альт Сервер Виртуализации доступно значительное количество программ (до нескольких тысяч), часть из них составляет саму операционную систему, а остальные — это прикладные программы и утилиты.
В Альт Сервер Виртуализации все операции установки и удаления производятся над пакетами — отдельными компонентами системы. Пакет и программа соотносятся неоднозначно: иногда одна программа состоит из нескольких пакетов, иногда один пакет включает несколько программ.
В процессе установки системы обычно не требуется детализированный выбор компонентов на уровне пакетов — это требует слишком много времени и знаний от проводящего установку. Тем более, что комплектация дистрибутива подбирается таким образом, чтобы из имеющихся программ можно было составить полноценную рабочую среду для соответствующей аудитории пользователей. Поэтому, в процессе установки системы пользователю предлагается выбрать из небольшого списка групп пакетов, объединяющих пакеты, необходимые для решения наиболее распространённых задач. Под списком групп на экране отображается информация об объёме дискового пространства, которое будет занято после установки пакетов, входящих в выбранные группы.
Выбор профиля
При установке сервера доступны следующие профили:
  • Минимальная установка — дополнительное ПО в состав устанавливаемых пакетов включаться не будет;
  • Сервер управления Opennebula — управляющий сервер Opennebula;
  • Вычислительный узел Opennebula KVM — гипервизор с виртуальными машинами;
  • Вычислительный узел Opennebula LXD — гипервизор LXC контейнеров;
  • Виртуальное Окружение Proxmox — узел кластера Proxmox Virtual Enviroment. Все ноды кластера равнозначны: нет деления на сервер управления и гипервизор;
  • Базовая виртуализация — минимальный гипервизор, qemu + libvirtd;
  • Docker — сервер с предустановленным docker.
После выбора профиля можно изменить состав устанавливаемых пакетов.
Под списком групп на экране отображается информация об объёме дискового пространства, которое будет занято после установки пакетов, входящих в выбранные группы.
Опция Показать состав группы выводит список программных пакетов, входящих в состав той или иной группы пакетов.
Выбор групп приложений
Выбрав необходимые группы, следует нажать кнопку Далее, после чего начнётся установка пакетов.

12.2. Установка пакетов

На этом этапе происходит установка набора программ, необходимых для работы системы.
Установка системы
Установка происходит автоматически в два этапа:
  • получение пакетов;
  • установка пакетов.
Получение пакетов осуществляется из источника, выбранного на этапе начальной загрузки. При сетевой установке время выполнения этого шага будет зависеть от скорости соединения и может быть значительно большим в сравнении с установкой с лазерного диска.

Глава 13. Сохранение настроек

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

Глава 14. Установка загрузчика

Загрузчик ОС — это программа, которая позволяет загружать Альт Сервер Виртуализации и другие ОС, если они установлены на данной машине.
Установка загрузчика
Программа установки автоматически определяет, в каком разделе НЖМД следует располагать загрузчик для возможности корректного запуска ОС Альт Сервер Виртуализации. Положение загрузчика, в случае необходимости, можно изменить в выпадающем списке Устройство, выбрав другой раздел.
Если же вы планируете использовать и другие ОС, уже установленные на этом компьютере, тогда имеет значение на каком жёстком диске или в каком разделе будет расположен загрузчик.
Для ограничения доступа к опциям загрузки можно установить пароль на загрузчик. Для этого необходимо отметить пункт Установить или сбросить пароль и, в появившихся полях для ввода, задать пароль.
Установка загрузчика

Примечание

При необходимости изменения опций загрузки при старте компьютера потребуется ввести имя пользователя «boot» и заданный на этом шаге пароль.

Важно

При установке на EFI выберите в качестве устройства для установки «EFI». Рекомендуется выбрать автоматическое разбиение на этапе разметки диска для создания необходимых разделов для загрузки с EFI.
Установка загрузчика
Для подтверждения выбора и продолжения работы программы установки необходимо нажать кнопку Далее.

Глава 15. Настройка сети

На этом этапе необходимо задать параметры работы сетевой карты и настройки сети: IP-адреса сетевых интерфейсов, DNS-сервер, шлюз и т.п. Конкретные значения будут зависеть от используемого вами сетевого окружения. Ручного введения настроек можно избежать при наличии в сети настроенного DHCP-сервера. В этом случае все необходимые сетевые настройки будут получены автоматически.
Настройка сети

Важно

Если в сервере есть несколько сетевых карт, то одну можно использовать для управления (на неё следует назначить IP-адрес без моста), вторую использовать только для моста, в который будут подключаться виртуальные машины. Для использования CEPH, iSCSI, NFS или другого сетевого хранилища стоит использовать третью сетевую карту, желательно 10G.

Примечание

Для настройки Ethernet-моста следует нажать кнопку Настроить сетевой мост:
Настройка Ethernet-моста
В открывшемся окне необходимо выбрать сетевой интерфейс в списке доступных интерфейсов (Available interfaces), переместить его в список Участники (Members), в выпадающем списке Тип моста (Bridge type) выбрать тип моста: Linux Bridge (по умолчанию) или Open vSwitch и нажать кнопку Ok:
Настройка Ethernet-моста
Настроить сетевой интерфейс vmbr0: ввести имя компьютера, задать IP-адрес и нажать кнопку Добавить, ввести адрес шлюза по умолчанию и DNS-сервера:
Настройка параметров сетевого интерфейса vmbr0

Важно

При установке PVE в поле Имя компьютера необходимо указать FQDN (полное имя с доменом).
Для сохранения настроек сети и продолжения работы программы установки необходимо нажать кнопку Далее.

Глава 16. Администратор системы

На данном этапе загрузчик создает учетную запись администратора. В открывшемся окне необходимо ввести пароль учетной записи администратора (root). Чтобы исключить опечатки при вводе пароля, пароль учетной записи вводится дважды.
Администратор системы

Примечание

Чтобы избежать последствий неверной раскладки клавиатуры можно просмотреть пароль, который будет сохранен. Для этого нажмите на значок стрелки в поле ввода:
Просмотр пароля
Для автоматической генерации пароля необходимо отметить пункт Создать автоматически. Система предложит пароль, сгенерированный автоматическим образом в соответствии с требованиями по стойкости паролей.
В любой системе Linux всегда присутствует один специальный пользователь — администратор системы, он же суперпользователь. Для него зарезервировано стандартное системное имя — root.
Администратор системы отличается от всех прочих пользователей тем, что ему позволено производить любые, в том числе самые разрушительные изменения в системе. Поэтому выбор пароля администратора системы — очень важный момент для безопасности. Любой, кто сможет ввести его правильно (узнать или подобрать), получит неограниченный доступ к системе. Даже ваши собственные неосторожные действия от имени root могут иметь катастрофические последствия для всей системы.

Важно

Стоит запомнить пароль root — его нужно будет вводить для получения права изменять настройки системы с помощью стандартных средств настройки Альт Сервер Виртуализации. Более подробную информацию о режиме суперпользователя вы можете прочитать в главе Режим суперпользователя.
Подтверждение введенного (или сгенерированного) пароля учетной записи администратора (root) и продолжение работы программы установки выполняется нажатием кнопки Далее.

Глава 17. Системный пользователь

На данном этапе программа установки создает учетную запись системного пользователя (пользователя) Альт Сервер Виртуализации.
Системный пользователь
Помимо администратора (root) в систему необходимо добавить, по меньшей мере, одного обычного системного пользователя. Работа от имени администратора системы считается опасной, поэтому повседневную работу в Linux следует выполнять от имени ограниченного в полномочиях системного пользователя.
При добавлении системного пользователя предлагается ввести имя учётной записи пользователя. Имя учётной записи всегда представляет собой одно слово, состоящее только из строчных латинских букв (заглавные запрещены), цифр и символа подчёркивания «_» (причём цифра и символ «_» не могут стоять в начале слова).
Для того чтобы исключить опечатки, пароль пользователя вводится дважды. Пароль пользователя можно создать автоматически, по аналогии с автоматическим созданием пароля суперпользователя.
Для автоматической генерации пароля необходимо отметить пункт Создать автоматически. Система предложит пароль, сгенерированный автоматическим образом в соответствии с требованиями по стойкости паролей.
В процессе установки предлагается создать только одну учётную запись системного пользователя — от его имени можно выполнять задачи, не требующие привилегий суперпользователя. Учётные записи для всех прочих пользователей системы можно будет создать в любой момент после установки операционной системы.
Подтверждение введенного (или сгенерированного) пароля учетной записи системного пользователя и продолжение работы программы установки выполняется нажатием кнопки Далее.

Глава 18. Установка пароля на шифрованные разделы

Примечание

Если вы не создавали шифруемые разделы, то этот шаг пропускается автоматически. В этом случае сразу переходите к главе Завершение установки.
На этом этапе требуется ввести пароль для шифруемых разделов. Этот пароль потребуется вводить для того, чтобы получать доступ к информации на данных разделах.
Установка пароля на LUKS-разделы
Например, если вы зашифровали /home, то во время загрузки системы будет необходимо ввести пароль для этого раздела, иначе вы не сможете получить доступ в систему под своим именем пользователя.

Глава 19. Завершение установки

На экране последнего шага установки отображается информация о завершении установки Альт Сервер Виртуализации.
Завершение установки
После нажатия кнопки Завершить автоматически начнется перезагрузка системы.
Не забудьте извлечь установочный DVD (если это не происходит автоматически). Далее можно загружать установленную систему в обычном режиме.

Глава 20. Обновление системы до актуального состояния

После установки системы, её лучше сразу обновить до актуального состояния. Можно не обновлять систему и сразу приступать к работе только в том случае, если вы не планируете подключаться к сети или Интернету, не собираетесь устанавливать дополнительных программ.
Для обновления системы необходимо выполнить команды (с правами администратора):
# apt-get update
# apt-get dist-upgrade
# update-kernel
# apt-get clean
# reboot

Примечание

Получить права администратора можно, выполнив в терминале команду:
$ su -
или зарегистрировавшись в системе (например, на второй консоли Ctrl+Alt+F2) под именем root. Про режим суперпользователя можно почитать в главе Режим суперпользователя.

Примечание

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

Часть III. Начало использования Альт Сервер Виртуализации

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

Глава 21. Загрузка системы

Запуск Альт Сервер Виртуализации выполняется автоматически после запуска компьютера и отработки набора программ BIOS.
На экране появляется меню, в котором перечислены возможные варианты загрузки операционной системы.
Загрузка системы

Важно

При первом старте, в условиях установки нескольких ОС на один компьютер, возможно отсутствие в загрузочном меню пункта/пунктов с другой/другими операционными системами, они будут добавлены в список при последующей перезагрузке. Все перечисленные в меню после перезагрузки варианты могут быть загружены загрузчиком Linux.
Стрелками клавиатуры Вверх и Вниз выберите нужную операционную систему. Дополнительно к основным вариантам запуска ОС из этого меню можно загрузить Linux в безопасном режиме или запустить проверку памяти.
Загрузка операционной системы по умолчанию (первая в списке) начинается автоматически после небольшого времени ожидания (обычно несколько секунд). Нажав клавишу Enter, можно начать загрузку немедленно.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, то редактировать их нет необходимости.
В процессе загрузки Альт Сервер Виртуализации пользователь может следить за информацией процесса загрузки, которая отображает этапы запуска различных служб и программных серверов в виде отдельных строк, на экране монитора.
Информация процесса загрузки системы
При этом каждая строка начинается словом вида [XXXXXXX] (FAILED или OK), являющегося признаком нормального или ненормального завершения этапа загрузки. Слово XXXXXXX=FAILED (авария) свидетельствует о неуспешном завершении этапа загрузки, что требует вмешательства и специальных действий администратора системы.
Загрузка операционной системы может занять некоторое время, в зависимости от производительности компьютера. Основные этапы загрузки операционной системы — загрузка ядра, подключение (монтирование) файловых систем, запуск системных служб — периодически могут дополняться проверкой файловых систем на наличие ошибок. В этом случае время ожидания может быть занять больше времени, чем обычно. Подробную информацию о шагах загрузки можно получить, нажав клавишу Esc.

Глава 22. Получение доступа к зашифрованным разделам

В случае, если вы создали шифрованный раздел, вам потребуется вводить пароль при обращении к этому разделу.
Например, если был зашифрован домашний раздел /home, то для того, чтобы войти в систему под своим именем пользователя, вам потребуется ввести пароль этого раздела и затем нажать Enter.

Важно

Если не ввести пароль за отведенный промежуток времени, то загрузка системы завершится ошибкой. В этом случае вам следует перезагрузить систему, нажав для этого два раза Enter, а затем клавиши Ctrl+Alt+Delete.

Глава 23. Вход в систему

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

Примечание

После загрузки будут показаны имя и IP адрес компьютера, а также адрес доступа к панели управления (если были установлены OpenNebula или PVE):
IP адрес компьютера и адрес панели управления PVE
Для дальнейшего входа в систему необходимо ввести логин и пароль учетной записи пользователя.
Приглашение для ввода команд
В случае успешного прохождения процедуры аутентификации и идентификации будет выполнен вход в систему. ОС Альт Сервер Виртуализации перейдет к штатному режиму работы и предоставит дальнейший доступ к консоли.
В процессе работы ОС Альт Сервер Виртуализации активно несколько виртуальных консолей. Каждая виртуальная консоль доступна по одновременному нажатию клавиш Ctrl, Alt и функциональной клавиши с номером этой консоли от F1 до F6.
На первых шести виртуальных консолях (от Ctrl+Alt+F1 до Ctrl+Alt+F6) пользователь может зарегистрироваться и работать в текстовом режиме. Двенадцатая виртуальная консоль (Ctrl+Alt+F12) выполняет функцию системной консоли – на нее выводятся сообщения о происходящих в системе событиях.

Часть IV. OpenNebula

OpenNebula — это платформа облачных вычислений для управления разнородными инфраструктурами распределенных центров обработки данных. Платформа OpenNebula управляет виртуальной инфраструктурой центра обработки данных для создания частных, общедоступных и гибридных реализаций инфраструктуры как службы.
Облачная архитектура определяется 3-мя элементами: хранилищем данных, сетью и системой виртуализации.
OpenNebula состоит из следующих компонентов:
  • Сервер управления (Front-end) — на нём выполняются сервисы OpenNebula;
  • Серверы с виртуальными машинами;
  • Хранилище данных — содержит образы виртуальных машин;
  • Физическая сеть — обеспечивает связь между хранилищем данных, серверами с виртуальными машинами, поддерживает VLAN-ы для виртуальных машин, а также управление сервисами OpenNebula.

Примечание

Компоненты OpenNebula будут установлены в систему, если при установке дистрибутива выбрать профиль Вычислительный узел Opennebula KVM, Вычислительный узел Opennebula LXD или Сервер управления Opennebula (см. главу Установка системы).

Содержание

24. Планирование ресурсов
24.1. Сервер управления
24.2. Серверы виртуализации
24.3. Хранилище данных
24.4. Сетевая инфраструктура
25. Запуск сервера управления OpenNebula
25.1. Установка пароля для пользователя oneadmin
25.2. Настройка MySQL (MariaDB) для хранения конфигурации
25.3. Запуск OpenNebula
25.4. Проверка установки
25.5. Ключи для доступа по SSH
25.6. Конфигурация сети
26. Добавление узлов в OpenNebula
26.1. Добавление узла в OpenNebula-Sunstone
26.2. Работа с узлами в командной строке
27. Управление пользователями
28. Работа с хранилищами в OpenNebula
29. Работа с образами в OpenNebula
29.1. Создание образа ОС в среде OpenNebula
29.2. Использование магазина приложений OpenNebula
30. Установка и настройка LXD
30.1. Настройка узла OpenNebula LXD
30.2. Добавление узла типа LXD в OpenNebula
30.3. Скачивание шаблона контейнера из магазина приложений
31. Настройка отказоустойчивого кластера
31.1. Первоначальная конфигурация Leader
31.2. Добавление дополнительных серверов
31.3. Добавление и удаление серверов
31.4. Восстановление сервера
31.5. Sunstone

Глава 24. Планирование ресурсов

24.1. Сервер управления

Таблица 24.1. Минимальные требования к серверу управления

Ресурс
Минимальное значение
Оперативная память
2 ГБ
CPU
1 CPU (2 ядра)
Диск
100 ГБ
Сеть
2 интерфейса
Максимальное количество серверов (узлов виртуализации), управляемых одним сервером управления, зависит от инфраструктуры, особенно от производительности хранилища. Обычно рекомендуется не управлять более чем 500 серверами из одной точки, хотя существуют примеры с более чем 1000 серверами.

24.2. Серверы виртуализации

Серверы виртуализации — это физические машины, на которых выполняются виртуальные машины. Подсистема виртуализации — это компонент, который отвечает за связь с гипервизором, установленным на узлах, и выполнение действий, необходимых для каждого этапа жизненного цикла виртуальной машины (ВМ).
Серверы (узлы) виртуализации имеют следующие характеристики и их рекомендованные значения:
  • CPU — в обычных условиях каждое ядро, предоставляемое ВМ, должно быть реальным ядром физического процессора. Например, для обслуживания 40 ВМ с двумя процессорами в каждой, облако должно иметь 80 физических ядер. При этом они могут быть распределены по разным серверам: 10 серверов с восемью ядрами или 5 серверов с 16 ядрами на каждом. В случае перераспределения недостаточных ресурсов используются атрибуты CPU и VCPU: CPU определяет физические ядра, выделенные для ВМ, а VCPU — виртуальные ядра для гостевой ОС.
  • Память — по умолчанию, OpenNebula не предоставляет памяти для гостевых систем больше, чем есть на самом деле. Желательно рассчитывать объём памяти с запасом в 10% на гипервизор. Например, для 45 ВМ с 2 ГБ памяти на каждой, необходимо 90 ГБ физической памяти. Важным параметром является количество физических серверов: каждый сервер должен иметь 10% запас для работы гипервизора, так, 10 серверов с 10 ГБ памяти на каждом могут предоставить по 9 ГБ для виртуальных машин и смогут обслужить 45 машин из этого примера (10% от 10 ГБ = 1 ГБ на гипервизор).

24.3. Хранилище данных

OpenNebula работает с двумя видами данных в хранилище: образцами виртуальных машин и образами (дисками) самих ВМ.
В хранилище образов (Images Datastore) OpenNebula хранит все зарегистрированные образы, которые можно использовать для создания ВМ.
Системное хранилище (System Datastore) — используется для хранения дисков виртуальных машин, работающих в текущий момент. Образы дисков перемещаются, или клонируются, в хранилище образов или из него при развертывании и отключении ВМ, при подсоединении или фиксировании мгновенного состояния дисков.
Одним из основных способов управления хранилищем данных является ограничение хранилища, доступного для пользователей, путем определения квот по максимальному количеству ВМ, а также максимального объема энергозависимой памяти, который может запросить пользователь, и обеспечения достаточного пространства хранения системных данных и образов, отвечающего предельным установленным квотам. OpenNebula позволяет администратору добавлять хранилища системных данных и образов, если это необходимо.
Планирование хранилища — является критически важным аспектом, поскольку от него зависит производительность облака. Размер хранилищ сильно зависит от базовой технологии. Например, при использовании Ceph для среднего по размеру облака, необходимо взять как минимум 3 сервера в следующей конфигурации: 5 дисков по 1 ТБ, 16 ГБ памяти, 2 CPU по 4 ядра в каждом и как минимум 2 сетевые карты.

24.4. Сетевая инфраструктура

Сетевая инфраструктура должна быть спланирована так, чтобы обеспечить высокую надёжность и пропускную способность. Рекомендуется использовать 2 сетевых интерфейса на сервере управления и по 4 на каждом сервере виртуализации (публичный, внутренний, для управления и для связи с хранилищем).

Глава 25. Запуск сервера управления OpenNebula

25.1. Установка пароля для пользователя oneadmin

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

Примечание

Файл /var/lib/one/.one/one_auth будет создан со случайно сгенерированным паролем. Необходимо поменять этот пароль перед запуском OpenNebula.
Для установки пароля для пользователя oneadmin необходимо выполнить команду:
# passwd oneadmin
Теперь зайдя под пользователем oneadmin следует заменить содержимое /var/lib/one/.one/one_auth. Он должен содержать следующее: oneadmin:<пароль>. Например:
$ echo "oneadmin:mypassword" > ~/.one/one_auth

25.2. Настройка MySQL (MariaDB) для хранения конфигурации

По умолчанию OpenNebula работает с SQLite. Если планируется использовать OpenNebula с MySQL, следует настроить данную конфигурацию перед первым запуском OpenNebula, чтобы избежать проблем с учетными данными oneadmin и serveradmin.

Примечание

Задать пароль root для mysql и настройки безопасности:
# mysql_secure_installation
Создать нового пользователя, предоставить ему привилегии в базе данных opennebula (эта база данных будет создана при первом запуске OpenNebula) и настроить уровень изоляции:
$ mysql -u root -p
Enter password:

MariaDB > GRANT ALL PRIVILEGES ON opennebula.* TO 'oneadmin' IDENTIFIED BY '<thepassword>';
Query OK, 0 rows affected (0.003 sec)

MariaDB > SET GLOBAL TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.001 sec)

MariaDB > quit
Перед запуском сервера OpenNebula в первый раз необходимо настроить параметры доступа к базе данных в конфигурационном файле /etc/one/oned.conf:
#DB = [ BACKEND = "sqlite" ]

# Sample configuration for MySQL
DB = [ BACKEND = "mysql",
       SERVER  = "localhost",
       PORT    = 0,
       USER    = "oneadmin",
       PASSWD  = "<thepassword>",
       DB_NAME = "opennebula",
       CONNECTIONS = 50 ]

25.3. Запуск OpenNebula

Для запуска OpenNebula необходимо выполнить следующие команды:
# systemctl start opennebula
# systemctl start opennebula-sunstone

25.4. Проверка установки

После запуска OpenNebula в первый раз, следует проверить, что команды могут подключаться к демону OpenNebula. Это можно сделать в командной строке или в графическом интерфейсе пользователя: Sunstone.
В командной строке
$ oneuser show
USER 0 INFORMATION
ID              : 0
NAME            : oneadmin
GROUP           : oneadmin
PASSWORD        : 3bc15c8aae3e4124dd409035f32ea2fd6835efc9
AUTH_DRIVER     : core
ENABLED         : Yes

USER TEMPLATE
TOKEN_PASSWORD="ec21d27e2fe4f9ed08a396cbd47b08b8e0a4ca3c"

VMS USAGE & QUOTAS

VMS USAGE & QUOTAS - RUNNING

DATASTORE USAGE & QUOTAS

NETWORK USAGE & QUOTAS

IMAGE USAGE & QUOTAS
Также можно попробовать войти в веб-интерфейс Sunstone. Для этого необходимо перейти по адресу http://<внешний адрес>:9869. Если все в порядке, будет предложена страница входа.
Необходимо ввести в соответствующие поля имя пользователя (oneadmin) и пароль пользователя (тот, который находится в файле /var/lib/one/.one/one_auth):
Страница авторизации opennebula-sunstone
После входа в систему будет доступна панель инструментов:
Панель инструментов opennebula-sunstone

Примечание

Для смены языка интерфейса необходимо в левом меню выбрать пункт Settings, и на открывшейся странице в выпадающем списке Language выбрать пункт Russian (ru_RU):
Выбор языка интерфейса
Язык интерфейса будет изменён на русский:
Выбор языка интерфейса

25.5. Ключи для доступа по SSH

Сервер управления OpenNebula подключается к хостам гипервизора по SSH. Необходимо распространить открытый ключ пользователя oneadmin со всех машин в файл /var/lib/one/.ssh/authorized_keys на всех машинах.
При установке сервера управления OpenNebula ключ SSH был сгенерирован добавлен в авторизованные ключи. Необходимо синхронизировать id_rsa, id_rsa.pub и authorized_keys сервера управления и узлов. Кроме того, следует создать файл known_hosts и также синхронизировать его с узлами. Чтобы создать файл known_hosts, необходимо выполнить следующую команду (от пользователя oneadmin на сервере управления) со всеми именами узлов и именем сервера управления в качестве параметров:
$ ssh-keyscan <сервер управления> <узел1> <узел2> <узел3> ... >> /var/lib/one/.ssh/known_hosts 
Далее необходимо нужно скопировать каталог /var/lib/one/.ssh на все узлы. Самый простой способ — установить временный пароль для oneadmin на всех хостах и ​​скопировать каталог с сервера управления:
$ scp -rp /var/lib/one/.ssh <узел1>:/var/lib/one/
$ scp -rp /var/lib/one/.ssh <узел2>:/var/lib/one/
$ scp -rp /var/lib/one/.ssh <узел3>:/var/lib/one/
...
После этого необходимо убедиться, что при подключении от сервера управления под пользователем oneadmin к узлам и самому серверу управления, а также от узлов к серверу управления пароль не запрашивается.
Если требуется дополнительный уровень безопасности, можно хранить закрытый ключ только на сервере управления, а не копировать его на весь гипервизор. Таким образом, пользователь oneadmin в гипервизоре не сможет получить доступ к другим гипервизорам. Это достигается путем изменения /var/lib/one/.ssh/config на сервере управления и добавления параметра ForwardAgent к хостам гипервизора для пересылки ключа:
$ cat /var/lib/one/.ssh/config
 Host host1
    User oneadmin
    ForwardAgent yes
 Host host2
    User oneadmin
    ForwardAgent yes

25.6. Конфигурация сети

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

Примечание

Настройка сети необходима только на серверах с виртуальными машинами. Точное имя ресурсов (br0, br1 и т.д.) значения не имеет, но важно, чтобы мосты и сетевые карты имели одно и то же имя на всех узлах.

Глава 26. Добавление узлов в OpenNebula

Чтобы использовать существующие физические узлы, их необходимо зарегистрировать в OpenNebula. Этот шаг может быть выполнен в командной строке или в графическом пользовательском интерфейсе Sunstone.

Примечание

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

26.1. Добавление узла в OpenNebula-Sunstone

Для добавления узла, необходимо в левом меню выбрать ИнфраструктураУзлы и на загруженной странице нажать кнопку +:
Добавление узла в OpenNebula-Sunstone
Далее необходимо указать тип виртуализации, заполнить поле Имя хоста (можно ввести Ip-адрес узла, или его имя) и нажать кнопку Создать:
Добавление узла в OpenNebula-Sunstone
Затем следует вернуться к списку узлов и убедиться, что узел перешел в состояние ВКЛ (это должно занять от 20 секунд до 1 минуты, можно нажать кнопку Обновить для обновления состояния):
Добавление узла в OpenNebula-Sunstone
Далее на этой вкладке можно включать, отключать, удалять и просматривать информацию об узлах.

26.2. Работа с узлами в командной строке

onehost — это инструмент управления узлами в OpenNebula. Описание всех доступных опций утилиты onehost можно получить, выполнив команду:
$ man onehost
Для добавления узла в облако, необходимо выполнить следующую команду от oneadmin на сервере управления:
$ onehost create host01 -im kvm -vm kvm
ID: 1
Список узлов можно просмотреть, выполнив команду:
$ onehost list
  ID NAME         CLUSTER    TVM      ALLOCATED_CPU      ALLOCATED_MEM STAT
   1 host01       default      0       0 / 400 (0%)     0K / 7.6G (0%) on

Примечание

Если возникли проблемы с добавлением узла, то скорее всего неправильно настроен ssh. Ошибки можно просмотреть в /var/log/one/oned.log.
Для указания узла можно использовать его ID или имя. Например, удаление узла с указанием ID:
$ onehost delete host01
или имени:
$ onehost delete 1
Изменение статуса узла:
$ onehost disable host01 // деактивировать узел
$ onehost enable host01 // активировать узел
$ onehost offline host01 // полностью выключить узел
Просмотр информации об узле:
$ onehost show 1
Информация об узле содержит:
  • общую информацию, включая имя и драйверы, используемые для взаимодействия с ним;
  • информацию об объёме (Host Shares) процессора и памяти;
  • информацию о локальном хранилище данных (Local System Datastore), если хост настроен на использование локального хранилища данных;
  • информацию мониторинга;
  • активных ВМ на узле.

Глава 27. Управление пользователями

OpenNebula включает полную систему управления пользователями и группами.
Ресурсы, к которым пользователь может получить доступ в OpenNebula, контролируются системой разрешений. По умолчанию только владелец ресурса может использовать и управлять им. Пользователи могут делиться ресурсами, предоставляя разрешения на использование или управление другим пользователям в своей группе или любому другому пользователю в системе.
oneuser — инструмент командной строки для управления пользователями в OpenNebula.
При установке OpenNebula создаются две административные учетные записи (oneadmin и serveradmin), и две группы (oneadmin и users):
$ oneuser list
  ID NAME                 GROUP    AUTH            VMS     MEMORY        CPU
   1 serveradmin          oneadmin server_c    0 /   -      0M /   0.0 /   -
   0 oneadmin             oneadmin core              -          -          -
$ onegroup list
  ID NAME                 USERS       VMS            MEMORY         CPU
   1 users                    0   0 /   -      0M /       -  0.0 /    -
   0 oneadmin                 2         -                 -           -
Создание нового пользователя:
$ oneuser create <user_name> <password>
По умолчанию новый пользователь будет входить в группу users. Изменить группу пользователя:
$ oneuser chgrp <user_name> oneadmin
Что бы удалить пользователя из группы, необходимо переместить его обратно в группу users.
Временно отключить пользователя:
$ oneuser disable <user_name>
Включить отключённого пользователя:
$ oneuser enable <user_name>
Удалить пользователя:
$ oneuser delete <user_name>
onegroup — инструмент командной строки для управления группами в OpenNebula.
Создание новой группы:
$ onegroup create group_name
ID: 100
Новая группа получила идентификатор 100, чтобы отличать специальные группы от созданных пользователем.
После создания группы может быть создан связанный пользователь-администратор. По умолчанию этот пользователь сможет создавать пользователей в новой группе.
Пример создания новой группы с указанием, какие ресурсы могут быть созданы пользователями группы (по умолчанию VM+IMAGE+TEMPLATE):
$ onegroup create --name testgroup \
--admin_user testgroup-admin --admin_password somestr \
--resources TEMPLATE+VM
При выполнении данной команды также будет создан администратор группы.
Сделать существующего пользователя администратором группы:
$ onegroup addadmin <groupid_list> <userid>
Все операции с пользователями можно производить в веб-интерфейсе:
Управление пользователями в OpenNebula-Sunstone
Создание группы в OpenNebula-Sunstone
Созданный пользователь может аутентифицироваться в веб-интерфейсе OpenNebula и изменить настройки (изменить язык интерфейса, пароль, добавить ssh-ключ для доступа на ВМ и т.д.):
Панель пользователя в OpenNebula-Sunstone

Глава 28. Работа с хранилищами в OpenNebula

По умолчанию в OpenNebula созданы хранилище образов (Images), системное (System) и файлов (Files).
onedatastore — инструмент управления хранилищами в OpenNebula. Описание всех доступных опций утилиты onedatastore можно получить, выполнив команду:
$ man onedatastore
Вывести список хранилищ данных можно, выполнив команду:
$ onedatastore list
ID NAME                       SIZE AVA CLUSTERS IMAGES TYPE DS      TM      STAT
2 files                    104.8G 32% 0             1 fil  fs      ssh     on
1 default                  104.8G 32% 0             8 img  fs      ssh     on
0 system                        - -   0             0 sys  -       ssh     on
Информация о хранилище:
$ onedatastore show default
Создавать, включать, отключать, удалять и просматривать информацию о хранилищах можно в веб-интерфейсе:
Работа с хранилищами в OpenNebula-Sunstone

Глава 29. Работа с образами в OpenNebula

Система хранилищ позволяет пользователям настраивать/устанавливать образы, которые могут быть образами ОС или данных, для использования в ВМ. Данные образы могут использоваться несколькими ВМ одновременно, а также предоставляться другим пользователями.
Типы образов для дисков ВМ (хранятся в хранилище образов):
  • OS — образ загрузочного диска;
  • CDROM — файл образа, содержащий CDROM. Эти образы предназначены только для чтения. В каждом шаблоне ВМ, можно использовать только один образ данного типа;
  • DATABLOCK — файл образа, содержащий блок данных (например, базу данных) или может быть отформатирован как пустой диск.
Типы файлов (хранятся в файловом хранилище):
  • KERNEL — файл, который будет использоваться в качестве ядра ВМ (kernels);
  • RAMDISK — файл, для использования в качестве виртуального диска;
  • CONTEXT — файл для включения в контекстный CD-ROM.
Образы могут работать в двух режимах:
  • persistent (постоянные) — изменения, внесенные в такие образы, будут сохранены после завершения работы ВМ. В любой момент времени может быть только одна ВМ, использующая постоянный образ.
  • non-persistent (непостоянный) — изменения не сохранятся после завершения работы ВМ. Непостоянные образы могут использоваться несколькими ВМ одновременно, поскольку каждая из них будет работать со своей собственной копией.
Управлять образами можно, используя интерфейс командной строки — команда oneimage.
Также управлять образами можно в веб-интерфейсе, на вкладке Образы ВМ.
OpenNebula-Sunstone. Вкладка Образы ВМ

29.1. Создание образа ОС в среде OpenNebula

Для создания образа ОС, необходимо подготовить ВМ и извлечь её диск.

29.1.1. Создание образов дисков

Создать образ типа CDROM с установочным ISO-образом.
Для этого перейти в раздел ХранилищеОбразы ВМ, на загруженной странице нажать +Создать:
Создание образа
В открывшемся окне заполнить поле Название, выбрать тип образа CD-ROM только для чтения, выбрать хранилище, выбрать расположение образа Путь на сервере OpenNebula (Path in OpenNebula Server), указать путь к файлу (.iso) и нажать кнопку Создать:
Создание образа типа CD-ROM

Примечание

ISO-образ должен быть загружен в папку, к которой имеет доступ пользователь oneadmin.
Создать пустой образ диска, на который будет установлена операционная система.
Для этого создать новый образ. Заполнить поле Название, в выпадающем списке Тип выбрать значение Generic storage datablock, в выпадающем списке Этот образ является постоянным выбрать значение Да, выбрать хранилище, в разделе Расположение образа выбрать пункт Пустой образ диска, установить размер выбранного блока, например 45GB, в разделе Расширенные настройки указать драйвер qcow2 и нажать кнопку Создать:
Создание образа типа datablock

Примечание

Эти же действия можно выполнить в командной строке.
Создать образ типа CDROM в хранилище данных по умолчанию (ID = 1):
$ oneimage create -d 1 --name "ALT Workstation ISO" --path /var/tmp/alt-workstation-9.1-x86_64.iso --type CDROM
ID: 31
Создать пустой образ диска (тип образа — DATABLOCK, размер 45 ГБ, драйвер qcow2):
$ oneimage create -d 1 --name "ALT Workstation" --type DATABLOCK --size 45G --persistent --driver qcow2
ID: 33

29.1.2. Создание шаблона ВМ

Примечание

Создание шаблона в командной строке:
  1. Создать файл template со следующим содержимым:
    NAME = "ALT Workstation"
    CONTEXT = [
      NETWORK = "YES",
      SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]" ]
    CPU = "0.25"
    DISK = [
      IMAGE = "ALT Workstation ISO",
      IMAGE_UNAME = "oneadmin" ]
    DISK = [
      DEV_PREFIX = "vd",
      IMAGE = "ALT Workstation",
      IMAGE_UNAME = "oneadmin" ]
    GRAPHICS = [
      LISTEN = "0.0.0.0",
      TYPE = "SPICE" ]
    HYPERVISOR = "kvm"
    INPUTS_ORDER = ""
    LOGO = "images/logos/alt.png"
    MEMORY = "1024"
    MEMORY_UNIT_COST = "MB"
    NIC = [
      NETWORK = "VirtNetwork",
      NETWORK_UNAME = "oneadmin",
      SECURITY_GROUPS = "0" ]
    NIC_DEFAULT = [
      MODEL = "virtio" ]
    OS = [
      BOOT = "disk1,disk0" ]
    SCHED_REQUIREMENTS = "ID=\"0\""
    
  2. Создать шаблон:
    $ onetemplate create template
    ID: 22
    
Ниже рассмотрен пример создания шаблона в веб-интерфейсе.
В левом меню выбрать ШаблоныВМ, на загруженной странице нажать кнопку + и выбрать пункт Создать.
На вкладке Общие необходимо указать параметры процессора, оперативной памяти, а также гипервизор:
Создание шаблона ВМ. Вкладка Общие
На вкладке Хранилище необходимо указать ранее созданный пустой диск (DATABLOCK), в разделе Расширенные настройки в выпадающем списке Шина выбрать Virtio. Далее следует добавить новый диск и указать диск с установщиком ОС.
Создание шаблона ВМ. Вкладка Хранилище
На вкладке Сеть в поле Default hardware model to emulate for all NICs указать Virtio и если необходимо выбрать сеть:
Создание шаблона ВМ. Вкладка Сеть
На вкладке ОС и ЦПУ необходимо указать архитектуру устанавливаемой системы и выбрать порядок загрузки. Можно установить в качестве первого загрузочного устройства — пустой диск (DATABLOCK), а в качестве второго — CDROM (при такой последовательности загрузочных устройств при пустом диске загрузка произойдёт с CDROM, а в дальнейшем, когда ОС будет уже установлена на диск, загрузка будет осуществляться с него).
Создание шаблона ВМ. Вкладка ОС и ЦПУ
На вкладке Ввод/Вывод следует включить SPICE:
Создание шаблона ВМ. Вкладка Ввод/Вывод
На вкладке Контекст необходимо включить параметр Использовать сетевое задание контекста, а также авторизацию по RSA-ключам (укажите свой открытый SSH (.pub) для доступа к ВМ по ключу, если оставить поле пустым, будет использована переменная $USER[SSH_PUBLIC_KEY]):
Создание шаблона ВМ. Вкладка Контекст
На вкладке Расписание если необходимо можно выбрать кластер/хост, на котором будет размещаться виртуальное окружение:
Создание шаблона ВМ. Вкладка Расписание
Для создания шаблона ВМ нажать кнопку Создать.

29.1.3. Создание ВМ

Для инициализации создания ВМ из шаблона в левом меню следует выбрать пункт ШаблоныВМ, выбрать шаблон и нажать кнопку Создать ВМ:
Создание экземпляра ВМ из шаблона
В открывшемся окне необходимо указать имя ВМ и нажать кнопку Создать ВМ:
Создание экземпляра ВМ из шаблона

Примечание

Создание экземпляра ВМ из шаблона в командной строке:
$ onetemplate instantiate 22
VM ID: 94

29.1.4. Подключение к ВМ и установка ОС

Примечание

Процесс создания ВМ может занять несколько минут. Следует дождаться статуса — «ЗАПУЩЕНО» («RUNNING»).
Подключиться к ВМ можно как из веб-интерфейса Sunstone, раздел Экземпляры ВМВМ выбрать ВМ и подключиться по SPICE:
Подключение к ВМ
Так и используя, любой клиент SPICE:
spice://192.168.0.190:5994
где 192.168.0.190 адрес хоста с ВМ, а 94 идентификатор ВМ (номер порта 5900 + 94).
Далее необходимо провести установку системы:
Установка ОС

29.1.5. Настройка контекстуализации

OpenNebula использует метод, называемый контекстуализацией, для отправки информации на ВМ во время загрузки. Контекстуализация позволяет установить или переопределить данные ВМ, имеющие неизвестные значения или значения по умолчанию (имя хоста, IP-адрес, .ssh/authorized_keys).
Пример настройки контекстуализации на установленной ОС Альт:
  1. Подключиться к ВМ через SPICE или по ssh.
  2. Установить пакет opennebula-context:
    # apt-get update && apt-get install opennebula-context 
    
  3. Переключиться на systemd-networkd:
    • установить пакет systemd-timesyncd:
      # apt-get install systemd-timesyncd
      
    • создать файл автонастройки всех сетевых интерфейсов по DHCP /etc/systemd/network/lan.network со следующим содержимым:
      [Match]
      Name = *
      
      [Network]
      DHCP = ipv4
      
    • переключиться с etcnet/NetworkManager на systemd-networkd:
      # systemctl disable network NetworkManager && systemctl enable systemd-networkd systemd-timesyncd
      
  4. Перезагрузить систему.
После перезагрузки доступ в систему будет возможен по ssh-ключу, ВМ будет назначен IP-адрес, который OpenNebula через механизм IPAM (подсистема IP Address Management) выделит из пула адресов.

29.1.6. Создание образа типа OS

После завершения установки и настройки системы следует выключить и удалить ВМ. Диск находится в состоянии Persistent, поэтому все внесенные изменения будут постоянными.
Для удаления ВМ в левом меню следует выбрать пункт Экземпляры ВМВМ, выбрать ВМ и нажать кнопку Уничтожить:
Удаление ВМ

Примечание

Удаление ВМ в командной строке:
$ onevm terminate 94
Затем перейти в ХранилищеОбразы ВМ, выбрать образ с установленной ОС (ALT Workstation) и изменить тип блочного устройства с Datablock на ОС и состояние на Non Persistent:
Изменение типа блочного устройства

Примечание

Изменить тип блочного устройства на ОС и состояние на Non Persistent:
$ oneimage chtype 33 OS
$ oneimage nonpersistent 33
Образ готов. Далее можно использовать как имеющийся шаблон, так и создать новый на основе образа диска «ALT Workstation».

29.2. Использование магазина приложений OpenNebula

Для загрузки приложения из магазина необходимо перейти в ХранилищеМагазины приложений, выбрать OpenNebula PublicПриложения. Появится список доступных приложений:
Магазин приложений OpenNebula
Каждое приложение содержит образ и шаблон.
Чтобы импортировать приложение, необходимо его выбрать и нажать кнопку Import into Datastore:
Импорт приложения из магазина приложений OpenNebula
В открывшемся окне указать имя для образа и шаблона, выбрать хранилище и нажать кнопку Загрузить:
Использование магазина приложений OpenNebula
Настройка образов, загруженных из магазина приложений:
  1. Изменить состояние образа на Постоянный (необходимо дождаться состояния ГОТОВО).
  2. Настроить шаблон.
  3. Создать на основе шаблона ВМ.
  4. Подключиться к ВМ. Установить/настроить необходимые компоненты.
  5. Удалить ВМ.
  6. Изменить состояние образа на Не постоянный.
  7. Далее можно создать новые шаблоны на основе этого образа или использовать существующий.

Глава 30. Установка и настройка LXD

LXD — это гипервизор LXC контейнеров.

Важно

Для работы с LXD в OpenNebula должна быть настроена пара хранилищ (хранилище образов и системное) НЕ типа qcow2 (например, shared или ssh).
Перед добавлением хоста типа LXD на сервер OpenNebula следует настроить узел LXD.

30.1. Настройка узла OpenNebula LXD

Для создания узла типа LXD, при установке дистрибутива нужно выбрать профиль Вычислительный узел Opennebula LXD (см. главу Установка системы):
Установка сервера контейнеризации LXD
Также следует настроить доступ по SSH (см. раздел Ключи для доступа по SSH).

Примечание

В уже установленной системе можно установить пакет opennebula-node-lxd:
# apt-get install opennebula-node-lxd
И инициализировать lxd, выполнив команду из файла /usr/share/doc/opennebula-node-lxd-5.10.5/README.opennebula-lxd

30.2. Добавление узла типа LXD в OpenNebula

Для добавления узла типа LXD на сервере OpenNebula, необходимо в левом меню выбрать ИнфраструктураУзлы и на загруженной странице нажать кнопку +:
Добавление узла в OpenNebula-Sunstone
Далее необходимо указать тип виртуализации — LXD, заполнить поле Имя хоста (можно ввести Ip-адрес узла, или его имя) и нажать кнопку Создать:
Добавление узла типа LXD в OpenNebula-Sunstone
Затем следует вернуться к списку узлов и убедиться, что узел перешел в состояние ВКЛ (это должно занять от 20 секунд до 1 минуты).

Примечание

Для добавления узла типа LXD в командной строке:
$ onehost create host03 -im lxd -vm lxd
ID: 3

30.3. Скачивание шаблона контейнера из магазина приложений

Для загрузки контейнера из магазина необходимо перейти в ХранилищеМагазины приложений, выбрать Linux ContainersПриложения:
Магазин приложений OpenNebula
Выбрать LXD образ. Чтобы импортировать приложение, необходимо его выбрать и нажать кнопку Import into Datastore:
Импорт приложения из магазина приложений OpenNebula
Каждый контейнер содержит образ и шаблон.
В открывшемся окне указать название для образа и шаблона, выбрать хранилище и нажать кнопку Загрузить:
Импорт приложения из магазина приложений OpenNebula
Из полученного шаблона можно разворачивать контейнеры (ВМ в терминологии Opennebula). Процесс разворачивания контейнера из шаблона такой же, как и процесс разворачивания ВМ из шаблона:
Разворачивание контейнера из шаблона

Глава 31. Настройка отказоустойчивого кластера

В данном разделе рассмотрена настройка отказоустойчивого кластера (High Available, HA) для основных служб OpenNebula: core (oned), scheduler (mm_sched).
OpenNebula использует распределенный консенсусный протокол Raft, для обеспечения отказоустойчивости и согласованности состояний между службами. Алгоритм консенсуса построен на основе двух концепций:
  • Состояние системы — данные, хранящиеся в таблицах базы данных (пользователи, списки управления доступом или виртуальные машины в системе).
  • Журнал (Log) — последовательность операторов SQL, которые последовательно применяются к базе данных OpenNebula на всех серверах для изменения состояния системы.
Чтобы сохранить согласованное представление о системе на всех серверах, изменения состояния системы выполняются через специальный узел, лидер или ведущий (Leader). Leader периодически посылает запросы (heartbeats) другим серверам, ведомым (Follower), чтобы сохранить свое лидерство. Если Leader не может послать запрос, Follower-серверы продвигаются к кандидатам и начинают новые выборы.
Каждый раз, когда система изменяется (например, в систему добавляется новая ВМ), Leader обновляет журнал и реплицирует запись у большинства Follower, прежде чем записывать её в базу данных. Таким образом, увеличивается задержка операций с БД, но состояние системы безопасно реплицируется, и кластер может продолжить свою работу в случае отказа узла.
Для настройки High Available требуется:
  • нечетное количество серверов (рекомендуемый размер развертывания — 3 или 5 серверов, что обеспечивает отказоустойчивость при отказе 1 или 2 серверов соответственно);
  • рекомендуется идентичная конфигурация серверов;
  • идентичная программная конфигурация серверов (единственное отличие — это поле SERVER_ID в /etc/one/oned.conf);
  • рекомендуется использовать подключение к базе данных одного типа (MySQL);
  • серверы должны иметь беспарольный доступ для связи друг с другом;
  • плавающий IP, который будет назначен лидеру;
  • общая файловая система.
Добавлять дополнительные серверы или удалять старые можно после запуска кластера.
В данном примере показана настройка HA кластера из трех серверов:
  • 192.168.0.186 opennebula
  • 192.168.0.187 server02
  • 192.168.0.188 server03
  • 192.168.0.200 Floating IP

31.1. Первоначальная конфигурация Leader

Запустить сервис OpenNebula и добавить локальный сервер в существующую или новую зону (в примере зона с ID 0):
$ onezone list
C   ID NAME             ENDPOINT                                      FED_INDEX
*    0 OpenNebula       http://localhost:2633/RPC2                    -1

$ onezone server-add 0 --name opennebula --rpc http://192.168.0.186:2633/RPC2

$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      solo       0          -1         0          -1    -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Остановить сервис opennebula и обновить конфигурацию SERVER_ID в файле /etc/one/oned.conf:
FEDERATION = [
    MODE          = "STANDALONE",
    ZONE_ID       = 0,
    SERVER_ID     = 0, # изменить с -1 на 0 (0 — это ID сервера)
    MASTER_ONED   = ""
]
Включить Raft-обработчики, чтобы добавить плавающий IP-адрес в кластер (файл /etc/one/oned.conf):
RAFT_LEADER_HOOK = [
    COMMAND = "raft/vip.sh",
    ARGUMENTS = "leader enp0s3 192.168.0.200/24"
]

# Executed when a server transits from leader->follower
RAFT_FOLLOWER_HOOK = [
    COMMAND = "raft/vip.sh",
    ARGUMENTS = "follower enp0s3 192.168.0.200/24"
]
Запустить сервис OpenNebula и проверить зону:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     1          5          5          0     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC
Сервер opennebula стал Leader-сервером, так же ему был присвоен плавающий адрес (Floating IP):
$ ip -o a sh enp0s3
2: enp0s3    inet 192.168.0.186/24 brd 192.168.0.255 scope global enp0s3\       valid_lft forever preferred_lft forever
2: enp0s3    inet 192.168.0.200/24 scope global secondary enp0s3\       valid_lft forever preferred_lft forever
2: enp0s3    inet6 fe80::a00:27ff:fec7:38e6/64 scope link \       valid_lft forever preferred_lft forever

31.2. Добавление дополнительных серверов

Предупреждение

Данная процедура удалит полностью базу на сервере и заменит её актуальной с Leader-сервера.

Предупреждение

Рекомендуется добавлять по одному хосту за раз, чтобы избежать конфликта в базе данных.
На Leader создать полную резервную копию актуальной базы и перенести её на другие серверы вместе с файлами из каталога /var/lib/one/.one/:
$ onedb backup -u oneadmin -d opennebula -p oneadmin
MySQL dump stored in /var/lib/one/mysql_localhost_opennebula_2021-6-23_13:43:21.sql
Use 'onedb restore' or restore the DB using the mysql command:
mysql -u user -h server -P port db_name < backup_file

$ scp /var/lib/one/mysql_localhost_opennebula_2021-6-23_13\:43\:21.sql <ip>:/tmp

$ ssh <ip> rm -rf /var/lib/one/.one
$ scp -r /var/lib/one/.one/ <ip>:/var/lib/one/ 
Остановить сервис OpenNebula на Follower-хостах и восстановить скопированную базу:
$ onedb restore -f -u oneadmin -p oneadmin -d opennebula /tmp/mysql_localhost_opennebula_2021-6-23_13\:43\:21.sql
MySQL DB opennebula at localhost restored.
Перейти на Leader и добавить в зону новые хосты (рекомендуется добавлять серверы по-одному):
$ onezone server-add 0 --name server02 --rpc http://192.168.0.187:2633/RPC2
Проверить зону на Leader-сервере:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2
 1 server02        http://192.168.0.187:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     4          22         22         0     -1
 1 server02        error      -          -          -          -     -

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Новый сервер находится в состоянии ошибки, так как OpenNebula на новом сервере не запущена. Следует запомнить идентификатор сервера, в этом случае он равен 1.
Переключиться на добавленный Follower-сервер и обновить конфигурацию SERVER_ID в файле /etc/one/oned.conf, (указать в качестве SERVER_ID значение из предыдущего шага). Включить Raft-обработчики, как это было выполнено на Leader.
Запустить сервис OpenNebula на Follower-сервере и проверить на Leader-сервере состояние зоны:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2
 1 server02        http://192.168.0.187:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     4          28         28         0     -1
 1 server02        follower   4          28         28         0     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2""
Повторить данные действия, чтобы добавить третий сервер в кластер.

Примечание

Добавлять серверы в кластер, следует только в случае нормальной работы кластера (работает Leader, а остальные находятся в состоянии Follower). Если в состоянии error присутствует хотя бы один сервер, необходимо это исправить.
Проверка работоспособности кластера:
$ onezone show 0
ZONE 0 INFORMATION
ID                : 0
NAME              : OpenNebula


ZONE SERVERS
ID NAME            ENDPOINT
 0 opennebula      http://192.168.0.186:2633/RPC2
 1 server02        http://192.168.0.187:2633/RPC2
 2 server03        http://192.168.0.188:2633/RPC2

HA & FEDERATION SYNC STATUS
ID NAME            STATE      TERM       INDEX      COMMIT     VOTE  FED_INDEX
 0 opennebula      leader     4          35         35         0     -1
 1 server02        follower   4          35         35         0     -1
 2 server03        follower   4          35         35         0     -1

ZONE TEMPLATE
ENDPOINT="http://localhost:2633/RPC2"
Если какой-либо хост находится в состоянии ошибки, следует проверить журнал (/var/log/one/oned.log), как в текущем Leader (если он есть), так и в хосте, который находится в состоянии Error. Все сообщения Raft будут регистрироваться в этом файле.

31.3. Добавление и удаление серверов

Команда добавления сервера:
onezone server-add <zoneid>
параметры:
  • -n, --name — имя сервера зоны;
  • -r, --rpc — конечная точка RPC сервера зоны;
  • -v, --verbose — подробный режим;
  • --user name — имя пользователя, используемое для подключения к OpenNebula;
  • --password password — пароль для аутентификации в OpenNebula;
  • --endpoint endpoint — URL конечной точки интерфейса OpenNebula xmlrpc.
Команда удаления сервера:
onezone server-del <zoneid> <serverid>
параметры:
  • -v, --verbose — подробный режим;
  • --user name — имя пользователя, используемое для подключения к OpenNebula;
  • --password password — пароль для аутентификации в OpenNebula;
  • --endpoint endpoint — URL конечной точки интерфейса OpenNebula xmlrpc.

31.4. Восстановление сервера

Если Follower-сервер в течение некоторого времени не работает, он может выпасть из окна восстановления. Чтобы восстановить этот сервер необходимо:
  1. Leader: создать резервную копию БД и скопировать её на отказавший сервер (повторно использовать предыдущую резервную копию нельзя).
  2. Follower: остановить OpenNebula.
  3. Follower: восстановить резервную копию БД.
  4. Follower: запустить OpenNebula.
  5. Leader: сбросить отказавший Follower, выполнив команду:
    onezone server-reset <zone_id> <server_id_of_failed_follower>
    

31.5. Sunstone

Есть несколько способов развертывания Sunstone в среде HA. Базовым является Sunstone, работающий на каждом интерфейсном узле OpenNebula. Клиенты используют только один сервер — Leader с плавающим IP.

Часть V. Средство управления виртуальными окружениями PVE

Private Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора KVM и системы контейнерной изоляции LXC. Основными компонентами среды являются:
  • физические серверы, на которых выполняются процессы гипервизора KVM, и процессы, работающие в контейнерах LXC;
  • хранилища данных, в которых хранятся образы установочных дисков, образы дисков виртуальных машин KVM и файлы, доступные из контейнеров LXC;
  • виртуальные сетевые коммутаторы, к которым подключаются сетевые интерфейсы виртуальных окружений.
PVE состоит из веб-интерфейса, распределённого хранилища данных конфигурации виртуальных окружений, а также утилит конфигурирования, работающих в командной строке. Все эти инструменты предназначены только для управления средой выполнения виртуальных окружений. За формирование среды отвечают компоненты системы, не входящие непосредственно в состав PVE. В первую очередь это сетевая и дисковая подсистемы, а также механизмы аутентификации.

Содержание

32. Краткое описание возможностей
32.1. Веб-интерфейс
32.2. Хранилище данных
32.3. Сетевая подсистема
33. Установка и настройка PVE
33.1. Установка PVE
33.2. Настройка сетевой подсистемы
34. Создание кластера PVE
34.1. Настройка узлов кластера
34.2. Создание кластера в веб-интерфейсе
34.3. Создание кластера в консоли
34.4. Удаление узла из кластера
34.5. Кластерная файловая система PVE (pmxcfs)
35. Системы хранения PVE
35.1. Типы хранилищ в PVE
35.2. Конфигурация хранилища
35.3. Работа с хранилищами в PVE
36. Управление ISO образами и шаблонами LXC
37. Виртуальные машины на базе KVM
37.1. Создание виртуальной машины на базе KVM
37.2. Внесение изменений в ВМ
37.3. Управление ВМ с помощью qm
37.4. Файлы конфигурации ВМ
37.5. Запуск и останов ВМ
37.6. Автоматический запуск ВМ
37.7. Управление образами виртуальных дисков
38. Создание и настройка контейнера LXC
38.1. Создание контейнера в графическом интерфейсе
38.2. Создание контейнера из шаблона в командной строке
38.3. Изменение настроек контейнера
38.4. Запуск и останов контейнеров
38.5. Доступ к LXC контейнеру
39. Миграция ВМ и контейнеров
39.1. Миграция с применением графического интерфейса
39.2. Миграция с применением командной строки
39.3. Миграция ВМ из внешнего гипервизора
40. Клонирование ВМ
41. Резервное копирование (Backup)
41.1. Алгоритмы резервного копирования
41.2. Режимы резервного копирования
41.3. Резервное хранилище
41.4. Резервное копирование по расписанию
41.5. Настройка резервного копирования в графическом интерфейсе
41.6. Резервное копирование из командной строки
41.7. Снимки (snapshot)
42. Встроенный мониторинг PVE
43. Высокая доступность PVE
43.1. Как работает высокая доступность PVE
43.2. Требования для настройки высокой доступности
43.3. Настройка высокой доступности PVE
43.4. Тестирование настройки высокой доступности PVE
44. Пользователи и их права

Глава 32. Краткое описание возможностей

32.1. Веб-интерфейс

Веб-интерфейс PVE предназначен для решения следующих задач:
  • создание, удаление, настройка виртуальных окружений;
  • управление физическими серверами;
  • мониторинг активности виртуальных окружений и использования ресурсов среды;
  • фиксация состояний (snapshot-ы), создание резервных копий и шаблонов виртуальных окружений, восстановление виртуальных окружений из резервных копий.
Кроме решения пользовательских задач, веб-интерфейс PVE можно использовать еще и для встраивания в интегрированные системы управления — например, в панели управления хостингом. Для этого он имеет развитый RESTful API с JSON в качестве основного формата данных.
Для аутентификации пользователей веб-интерфейса можно использовать как собственные механизмы PVE, так и PAM. Использование PAM дает возможность, например, интегрировать PVE в домен аутентификации.
Так как используется кластерная файловая система (pmxcfs), можно подключиться к любому узлу для управления всем кластером. Каждый узел может управлять всем кластером.
Веб-интерфейс PVE доступен по адресу https://<внешний-ip-адрес>:8006. Потребуется пройти аутентификацию (логин по умолчанию: root, пароль указывается в процессе установки).
Пользовательский интерфейс PVE состоит из четырех областей:
  • заголовок — верхняя часть. Показывает информацию о состоянии и содержит кнопки для наиболее важных действий;
  • дерево ресурсов — с левой стороны. Дерево навигации, где можно выбирать конкретные объекты;
  • панель контента — центральная часть. Здесь отображаются конфигурация и статус выбранных объектов;
  • панель журнала — нижняя часть. Отображает записи журнала для последних задач. Чтобы получить более подробную информацию или прервать выполнение задачи, следует дважды щелкнуть левой клавишей мыши по записи журнала.
Веб-интерфейс PVE

32.2. Хранилище данных

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

32.3. Сетевая подсистема

В отличие от хранилища данных, сетевая подсистема требует специальной настройки даже в случае локальной установки PVE. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному же устройству, обеспечивающему соединение с общей сетью передачи данных. Перед началом настройки сети следует принять решение о том, какой тип виртуализации (LXC/KVM) и какой тип подключения будет использоваться (маршрутизация/мост).

Глава 33. Установка и настройка PVE

Примечание

Компоненты PVE будут установлены в систему, если при установке дистрибутива выбрать профиль Виртуальное окружение Proxmox (см. главу Установка системы).
При установке дистрибутива, необходимо настроить Ethernet-мост vmbr0 и при заполнении поля с именем компьютера указать полное имя с доменом (см. главу Настройка сети).
Все остальные настройки можно делать в веб-интерфейсе см. Создание кластера PVE.

33.1. Установка PVE

Если развертывание PVE происходит в уже установленной системе на базе Девятой платформы, достаточно на всех нодах (узлах) любым штатным способом (apt-get, aptitude, synaptic) установить пакет pve-manager:
# apt-get install pve-manager
Все необходимые компоненты при этом будут установлены автоматически.
Также следует убедиться в том, что пакет systemd обновлен до версии, находящейся в репозитории P9.

33.2. Настройка сетевой подсистемы

На всех узлах необходимо настроить Ethernet-мост.

Важно

Мосту должно быть назначено имя vmbr0 и оно должно быть одинаково на всех узлах.

Важно

При использовании дистрибутива Альт Сервер Виртуализации интерфейс vmbr0 создаётся и настраивается в процессе установки системы (см. Настройка сети).

33.2.1. Настройка Ethernet-моста в командной строке

Перед настройкой Ethernet-моста (далее — моста) с помощью etcnet сначала необходимо убедиться, что установлен пакет bridge-utils. Etcnet использует утилиту brctl для настройки моста, и, если утилита не установлена, то при перезапуске системы сеть станет недоступна.
Если интерфейсы, входящие в состав моста, являются единственными физически подключенными и настройка моста происходит с удаленного узла через эти интерфейсы, то требуется соблюдать осторожность, т.к. эти интерфейсы перестанут быть доступны. В случае ошибки в конфигурации потребуется физический доступ к серверу. Для страховки, перед перезапуском сервиса network можно открыть еще одну консоль и запустить там, например, команду: sleep 500 && reboot.
Для настройки Ethernet-моста с именем vmbr0, следует выполнить следующие команды:
# mkdir /etc/net/ifaces/vmbr0
# cp /etc/net/ifaces/enp0s3/* /etc/net/ifaces/vmbr0/
# rm -f /etc/net/ifaces/enp0s3/{i,r}* 
# cat <<EOF > /etc/net/ifaces/vmbr0/options
BOOTPROTO=static
CONFIG_WIRELESS=no
CONFIG_IPV4=yes
HOST='enp0s3'
ONBOOT=yes
TYPE=bri
EOF
Имя интерфейса, обозначенного здесь как enp0s3, следует указать в соответствии с реальной конфигурацией сервера.
IP-адрес для интерфейса будет взят из /etc/net/ifaces/enp0s3/ipv4address.
В опции HOST файла /etc/net/ifaces/vmbr0/options нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, enp0s3), то этот адрес должен быть удален (например, можно закомментировать содержимое файла /etc/net/ifaces/enp0s3/ipv4address).
Для того, чтобы изменения вступили в силу необходим перезапуск сервиса network:
# systemctl restart network
При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически).

33.2.2. Настройка Ethernet-моста в веб-интерфейсе

При установленных пакетах alterator-net-eth и alterator-net-bridge, для настройки Ethernet-моста можно воспользоваться веб-интерфейсом центра управления системой.

Примечание

Должен также быть установлен пакет alterator-fbi и запущены сервисы ahttpd и alteratord:
# apt-get install alterator-fbi
# systemctl start ahttpd
# systemctl start alteratord
Веб-интерфейс доступен по адресу https://<ip-адрес>:8080.
Для настройки Ethernet-моста необходимо выполнить следующие действия:
  1. В веб-интерфейсе выбрать пункт СетьEthernet-интерфейсы
  2. Удалить IP-адрес и шлюз по умолчанию и нажать кнопку Создать сетевой мост:
    Настройка сети в веб-интерфейсе
  3. В открывшемся окне, задать имя моста vmbr0, выбрать сетевой интерфейс в списке доступных интерфейсов (Available interfaces), переместить его в список Участники (Members) и нажать кнопку Ok:
    Выбор сетевого интерфейса
  4. Настроить сетевой интерфейс vmbr0: ввести имя компьютера, задать IP-адрес и нажать кнопку Добавить, ввести адрес шлюза по умолчанию и DNS-сервера:
    Настройка параметров сетевого интерфейса vmbr0

Глава 34. Создание кластера PVE

Рекомендации:
  • все узлы должны иметь возможность подключаться друг к другу через UDP порты 5404 и 5405;
  • дата и время должны быть синхронизированы;
  • между узлами используется SSH туннель на 22 TCP порту;
  • если необходимо обеспечение высокой доступности (High Availability), необходимо иметь как минимум три узла для организации кворума. На всех узлах должна быть установлена одна версия PVE;
  • рекомендуется использовать выделенный сетевой адаптер для трафика кластера, особенно если используется общее хранилище.
В настоящее время создание кластера может быть выполнено либо в консоли (вход через ssh), либо в веб-интерфейсе.

Важно

PVE при создании кластера включает парольную аутентификацию для root в sshd. В целях повышения безопасности, после включения всех серверов в кластер, рекомендуется отключить парольную аутентификацию для root в sshd:
# control sshd-permit-root-login without_password
# systemctl restart sshd
При добавлении в кластер нового сервера, можно временно включить парольную аутентификацию:
# control sshd-permit-root-login enabled
# systemctl restart sshd
А после того, как сервер будет добавлен, снова отключить.
Кластеры используют ряд определённых портов для различных функций. Важно обеспечить доступность этих портов и отсутствие их блокировки межсетевыми экранами.

Таблица 34.1. Используемые порты

Порт
Функция
TCP 8006
Веб-интерфейс PVE
TCP 5900-5999
Доступ к консоли VNC
TCP 3128
Доступ к консоли SPICE
TCP 22
SSH доступ
UDP 5404, 5405
Широковещательный CMAN для применения настроек кластера
Кластер не создается автоматически на только что установленном узле PVE. Он должен быть создан на любом из узлов PVE, затем к данному кластеру присоединяются остальные узлы.
Для правильного функционирования кластера необходимо как минимум три узла. С тремя узлами возможен кворум, который позволяет кластерам обеспечивать работоспособность и функционирование должным образом.

34.1. Настройка узлов кластера

PVE должен быть установлен на всех узлах. Следует убедиться, что каждый узел установлен с окончательным именем хоста и IP-конфигурацией. Изменение имени хоста и IP-адреса невозможно после создания кластера.
Необходимо обеспечить взаимно однозначное прямое и обратное преобразование имен для всех узлов кластера. Крайне желательно использовать DNS, в крайнем случае, можно обойтись соответствующими записями в локальных файлах /etc/hosts:
# echo "192.168.0.186 pve01.test.alt pve01" >> /etc/hosts
# echo "192.168.0.90 pve02.test.alt pve02" >> /etc/hosts
# echo "192.168.0.70 pve03.test.alt pve03" >> /etc/hosts

Примечание

В PVE это можно сделать в панели управления: выбрать узел, перейти в СистемаHosts, добавить все узлы, которые будут включены в состав кластера:
Редактирование записей в файле /etc/hosts

Примечание

Имя машины не должно присутствовать в файле /etc/hosts разрешающимся в 127.0.0.1.

34.2. Создание кластера в веб-интерфейсе

Веб-интерфейс PVE доступен по адресу https://<имя-компьютера>:8006. Потребуется пройти аутентификацию (логин по умолчанию: root, пароль указывается в процессе установки):
Аутентификация в веб-интерфейсе PVE
Для создания кластера необходимо выполнить следующие действия:
  1. В панели управления любого узла кластера выбрать ДатацентрКластер и нажать кнопку Создать кластер:
    Создание кластера в веб-интерфейсе
  2. В открывшемся окне, задать название кластера, выбрать IP-адрес интерфейса, на котором узел кластера будет работать, и нажать кнопку Создать:
    Название кластера
  3. При успешном создании кластера будет выведена соответствующая информация:
    Информация о создании кластера
Для добавления узла в кластер необходимо выполнить следующие действия:
  1. В панели управления узла, на котором был создан кластер, выбрать ДатацентрКластер и нажать кнопку Данные присоединения:
    Создание кластера в веб-интерфейсе. Получить данные присоединения
  2. В открывшемся окне, скопировать данные присоединения (поле Данные присоединения):
    Создание кластера в веб-интерфейсе. Данные присоединения
  3. Перейти в панель управления узла, который следует присоединить к кластеру. Выбрать ДатацентрКластер и нажать кнопку Присоединить к кластеру:
    Узел, который следует присоединить к кластеру
  4. В поле Данные вставить скопированные данные присоединения, в поле Пароль ввести пароль пользователя root первого узла и нажать кнопку Присоединение (Join <имя_кластера>). (поля Адрес сервера и Отпечаток будут заполнены автоматически):
    Присоединение узла к кластеру
  5. Через несколько минут, после завершения репликации всех настроек, узел будет подключен к кластеру:
    Узлы кластера в веб-интерфейсе
Сразу после инициализации кластера в пределах каждого из узлов доступно одно локальное хранилище данных:
Веб-интерфейс PVE
PVE кластер может состоять из двух и более серверов. Максимальное количество узлов в кластере — 32.

34.3. Создание кластера в консоли

Команда, создания кластера:
# pvecm create <cluster_name>
На «головном» узле кластера необходимо выполнить команду инициализации конкретного кластера PVE, в данном случае — «pve-cluster»:
# systemctl start pve-cluster
# pvecm create pve-cluster
Проверка:
# pvecm status
Cluster information
-------------------
Name:             pve-cluster
Config Version:   1
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Jul  8 14:21:44 2021
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.d6
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            Quorate

Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 192.168.0.186 (local)
Команда создания кластера создает файл настройки /etc/pve/corosync.conf. По мере добавления узлов в кластер файл настройки будет автоматически пополняться информацией об узлах.
Команда, для добавления узла в кластер:
# pvecm add <existing_node_in_cluster>
где existing_node_in_cluster — адрес уже добавленного узла (рекомендуется указывать самый первый).
Для добавления узлов в кластер, необходимо на «подчинённых» узлах выполнить команду:
# pvecm add pve01
где pve01 — имя или ip-адрес «головного» узла.
При добавлении узла в кластер, потребуется ввести пароль администратора главного узла кластера:
# pvecm add pve01
Please enter superuser (root) password for 'pve01': ***
Establishing API connection with host 'pve01'

Login succeeded.
Request addition of this node
Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '/var/lib/pve-cluster/backup/config-1625747072.sql.gz'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys and known hosts
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'pve03' to cluster.
После добавления узлов в кластер, файл настройки кластера в /etc/pve/corosync.conf должен содержать информацию об узлах кластера.
На всех узлах кластера должны быть запущены и добавлены в список служб, запускаемых при старте узла, службы:
# systemctl start lxc lxc-net lxc-monitord pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy
# systemctl enable corosync lxc lxc-net lxc-monitord pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests

34.4. Удаление узла из кластера

Перед удалением узла из кластера необходимо переместить все ВМ с этого узла, а также убедиться, что нет никаких локальных данных или резервных копий, которые необходимо сохранить.
Для удаления узла из кластера необходимо выполнить следующие шаги:
  1. Войти в узел кластера не подлежащий удалению.
  2. Ввести команду pvecm nodes, чтобы определить идентификатор узла, который следует удалить:
    # pvecm nodes
    
    Membership information
    ----------------------
        Nodeid      Votes Name
             1          1 pve01 (local)
             2          1 pve02
             3          1 pve03
    
  3. Выключить подлежащий удалению узел (в данном случае pve2).
  4. Удалить узел из кластера, выполнив команду:
    # pvecm delnode pve02
    
  5. Проверить, что узел удален (команда отобразит список узлов кластера без удаленного узла):
    # pvecm nodes
    Membership information
    ----------------------
        Nodeid      Votes Name
             1          1 pve01 (local)
             3          1 pve03
    
Если необходимо вернуть удаленный узел обратно в кластер, следует выполнить следующие действия:
  • переустановить PVE на этом узле (это гарантирует, что все секретные ключи кластера/ssh и любые данные конфигурации будут уничтожены);
  • присоединиться к кластеру.

34.5. Кластерная файловая система PVE (pmxcfs)

Кластерная файловая система PVE (pmxcfs) — это файловая система на основе базы данных для хранения файлов конфигурации виртуальных окружений, реплицируемая в режиме реального времени на все узлы кластера с помощью corosync. Эта файловая система используется для хранения всех конфигурационных файлов связанных c PVE. Хотя файловая система хранит все данные в базе данных на диске, копия данных находится в оперативной памяти. Это накладывает ограничение на максимальный размер, который в настоящее время составляет 30 МБ. Но этого вполне достаточно, чтобы хранить конфигурации нескольких тысяч виртуальных машин.
Преимущества файловой системы:
  • мгновенная репликация и обновление конфигурации на все узлы в кластере;
  • исключается вероятность дублирования идентификаторов виртуальных машин;
  • в случае развала кворума в кластере, файловая система становится доступной только для чтения.
Все файлы и каталоги принадлежат пользователю root и имеют группу www-data. Только root имеет права на запись, но пользователи из группы www-data могут читать большинство файлов. Файлы в каталогах /etc/pve/priv/ и /etc/pve/nodes/${NAME}/priv/ доступны только root.
Файловая система смонтирована в /etc/pve/.

Глава 35. Системы хранения PVE

Образы ВМ могут храниться в одном или нескольких локальных хранилищах или в общем хранилище, например NFS или iSCSI (NAS, SAN). Ограничений нет, можно настроить столько пулов хранения, сколько необходимо.
В кластерной среде PVE наличие общего хранилища не является обязательным, однако, оно делает управление хранением более простой задачей. Преимущества общего хранилища:
  • миграция ВМ в реальном масштабе времени;
  • плавное расширение пространства хранения с множеством узлов;
  • централизованное резервное копирование;
  • многоуровневое кэширование данных;
  • централизованное управление хранением.

35.1. Типы хранилищ в PVE

Существует два основных класса типов хранения:
  • файловые хранилища — хранят данные в виде файлов. Технологии хранения на уровне файлов обеспечивают доступ к полнофункциональной файловой системе (POSIX). В целом они более гибкие, чем любое хранилище на уровне блоков, и позволяют хранить контент любого типа;
  • блочное хранилище — позволяет хранить большие необработанные образы. Обычно в таких хранилищах невозможно хранить другие файлы (ISO-образы, резервные копии, и т.д.). Большинство современных реализаций хранилищ на уровне блоков поддерживают моментальные снимки и клонирование. RADOS и GlusterFS являются распределенными системами, реплицирующими данные хранилища на разные узлы.
Хранилищами данных удобно управлять через веб-интерфейс. В качестве бэкенда хранилищ PVE может использовать:
  • сетевые файловые системы, в том числе распределенные: NFS, CEPH, GlusterFS;
  • локальные системы управления дисковыми томами: LVM, ZFS;
  • удаленные (iSCSI) и локальные дисковые тома;
  • локальные дисковые каталоги.

Таблица 35.1. Доступные типы хранилищ

Хранилище
PVE тип
Уровень
Общее (shared)
Снимки (snapshots)
ZFS (локальный)
zfspool
файл
нет
да
Каталог
dir
файл
нет
нет (возможны в формате qcow2)
NFS
nfs
файл
да
нет (возможны в формате qcow2)
CIFS
cifs
файл
да
нет (возможны в формате qcow2)
GlusterFS
glusterfs
файл
да
нет (возможны в формате qcow2)
CephFS
cephfs
файл
да
да
LVM
lvm
блок
нет
нет
LVM-thin
lvmthin
блок
нет
да
iSCSI/kernel
iscsi
блок
да
нет
iSCSI/libiscsi
iscsidirect
блок
да
нет
Ceph/RBD
rbd
блок
да
да
ZFS over iSCSI
zfs
блок
да
да
Proxmox Backup
pbs
файл/блок
да
-
Ряд хранилищ и формат образа Qemu qcow2 поддерживают тонкую настройку. Если активирована тонкая настройка в хранилище будут записаны только те блоки, которые фактически использует гостевая система.
Например, была создана ВМ с жестким диском объемом 32 ГБ, а после установки ОС гостевой системы корневая файловая система ВМ стала содержать 3 ГБ данных. В этом случае только 3 ГБ записывается в хранилище, даже если ВМ видит жесткий диск 32 ГБ. Таким образом, тонкая настройка позволяет создавать образы дисков, размер которых превышает доступные в настоящее время блоки хранения. Можно создавать большие образы дисков для ВМ, а при необходимости добавлять больше дисков в свое хранилище без изменения размера файловых систем ВМ.
Все типы хранилищ, которые поддерживают функцию Снимки, также поддерживают тонкую настройку.

35.2. Конфигурация хранилища

Вся связанная с PVE конфигурация хранилища хранится в одном текстовом файле /etc/pve/storage.cfg. Поскольку этот файл находится в /etc/pve/, он автоматически распространяется на все узлы кластера. Таким образом, все узлы имеют одинаковую конфигурацию хранилища.
Совместное использование конфигурации хранилища имеет смысл для общего хранилища, поскольку одно и то же «общее» хранилище доступно для всех узлов. Но также полезно для локальных типов хранения. В этом случае такое локальное хранилище доступно на всех узлах, но оно физически отличается и может иметь совершенно разное содержимое.
Каждое хранилище имеет <тип> и уникально идентифицируется своим <STORAGE_ID>. Конфигурация хранилища выглядит следующим образом:
<type>: <STORAGE_ID>
        <property> <value>
        <property> <value>
        ...
Строка <type>: <STORAGE_ID> определяет хранилище, затем следует список свойств.
Пример файла /etc/pve/storage.cfg:
# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content images,rootdir,iso,snippets,vztmpl
        maxfiles 0
nfs: nfs-storage
        export /export/storage
        path /mnt/nfs-vol
        server 192.168.0.105
        content images,iso,backup,vztmpl
        options vers=3,nolock,tcp
В данном случае файл содержит одно специальное хранилище local, которое ссылается на каталог /var/lib/vz и NFS хранилище nfs-storage.

Таблица 35.2. Параметры хранилищ

Свойство
Описание
nodes
Список узлов кластера, где это хранилище можно использовать/доступно. Можно использовать это свойство, чтобы ограничить доступ к хранилищу.
content
Хранилище может поддерживать несколько типов контента. Не все типы хранилищ поддерживают все типы контента. Это свойство указывает, для чего используется это хранилище.
Доступные опции:
  • images — образы виртуальных дисков;
  • rootdir — данные контейнеров
  • vztmpl — шаблоны контейнеров;
  • backup — резервные копии;
  • iso — ISO образы;
  • snippets — файлы сниппетов.
shared
Пометить хранилище как общее
disable
Отключить хранилище
maxfiles
Устарело, используйте вместо этого prune-backups. Максимальное количество файлов резервных копий на ВМ
prune-backups
Варианты хранения резервных копий
format
Формат по умолчанию (raw|qcow2|vmdk)
Сетевые файловые системы подходят для организации распределенных хранилищ данных, доступных со всех узлов кластера. Остальные могут использоваться только в качестве локальных хранилищ, доступных в пределах одного узла.

35.3. Работа с хранилищами в PVE

35.3.1. Использование командной строки

Утилита pvesm (PVE Storage Manager), позволяет выполнять общие задачи управления хранилищами.
Команды добавления (подключения) хранилища:
pvesm add <TYPE> <STORAGE_ID> <OPTIONS>
pvesm add dir <STORAGE_ID> --path <PATH>
pvesm add nfs <STORAGE_ID> --path <PATH> --server <SERVER> --export <EXPORT>
pvesm add lvm <STORAGE_ID> --vgname <VGNAME>
pvesm add iscsi <STORAGE_ID> --portal <HOST[:PORT]> --target <TARGET>
Отключить хранилище:
pvesm set <STORAGE_ID> --disable 1
Включить хранилище:
pvesm set <STORAGE_ID> --disable 0
Для того чтобы изменить/установить опции хранилища можно, выполнить команды:
pvesm set <STORAGE_ID> <OPTIONS>
pvesm set <STORAGE_ID> --shared 1
pvesm set local --format qcow2
pvesm set <STORAGE_ID> --content iso
Удалить хранилище (при этом никакие данные не удаляются, удаляется только конфигурация хранилища):
pvesm remove <STORAGE_ID>
Команда выделения тома:
pvesm alloc <STORAGE_ID> <VMID> <name> <size> [--format <raw|qcow2>]
Выделить том 4 ГБ в локальном хранилище (имя будет сгенерировано):
pvesm alloc local <VMID> '' 4G
Освободить место (уничтожает все данные тома):
pvesm free <VOLUME_ID>
Вывести список хранилищ:
pvesm status
Вывести список содержимого хранилища:
pvesm list <STORAGE_ID> [--vmid <VMID>]

35.3.2. Добавление хранилища в веб-интерфейсе PVE

Хранилища, которые могут быть добавлены через веб-интерфейс PVE:
  • Локальные хранилища:
    • Каталог — хранение на существующей файловой системе;
    • LVM — локальные устройства, такие как, FC, DRBD и т.д.;
    • ZFS;
  • Сетевые хранилища:
    • LVM — сетевая поддержка с iSCSI target;
    • NFS;
    • CIFS;
    • GlusterFS;
    • iSCSI;
    • CephFS;
    • RBD;
    • ZFS over iSCSI.
Выбор типа добавляемого хранилища
При создании каждому хранилищу данных присваивается роль или набор ролей. Например, хранение контейнеров, образов виртуальных дисков, файлов .iso и так далее. Список возможных ролей зависит от бэкенда хранилища. Например, для NFS или каталога локальной файловой системы доступны любые роли или наборы ролей, а хранилища на базе CEPH можно использовать только для хранения ISO-образов или шаблонов контейнеров:
Выбор ролей для хранилища

35.3.3. Каталог (Directory)

PVE может использовать локальные каталоги или локально смонтированные общие ресурсы для организации хранилища. Каталог — это хранилище на уровне файлов, поэтому в нем можно хранить данные любого типа, например, образы виртуальных дисков, контейнеры, шаблоны, ISO-образы или файлы резервных копий. Для хранения данных разного типа, используется предопределенная структура каталогов. Эта структура используется на всех файловых хранилищах.

Таблица 35.3. Структура каталогов

Тип данных
Подкаталог
Образы дисков ВМ
images/<VMID>/
ISO образы
template/iso/
Шаблоны контейнеров
template/cache/
Резервные копии
dump/
Snippets
snippets/
Для создания нового хранилища типа Каталог необходимо выбрать ДатацентрХранилище (DatacenterStorage), нажать кнопку Добавить (Add) и в выпадающем меню выбрать пункт Каталог (Directory).
Диалог создания хранилища local-iso типа Каталог для хранения ISO-образов и шаблонов контейнеров, которое будет смонтировано в каталог /mnt/iso:
Добавление хранилища типа Каталог
Данное хранилище поддерживает все общие свойства хранилищ и дополнительно свойство path для указания каталога. Это должен быть абсолютный путь к файловой системе.
Пример файла конфигурации (/etc/pve/storage.cfg):
dir: backup
        path /mnt/backup
        content backup
        prune-backups keep-last=7
        shared 0
Данная конфигурация определяет пул хранения резервных копий. Этот пул может использоваться для последних 7 резервных копий на виртуальную машину. Реальный путь к файлам резервных копий — /mnt/backup/dump/....
Хранилище Каталог использует четко определенную схему именования образов ВМ:
VM-<VMID>-<NAME>.<FORMAT>
где:
  • <VMID> — ID виртуальной машины;
  • <NAME> — произвольное имя (ascii) без пробелов. По умолчанию используется disk-[N], где [N] заменяется целым числом;
  • <FORMAT> — определяет формат образа (raw|qcow2|vmdk).
Пример:
# ls /var/lib/vz/images/101
vm-101-disk-0.qcow2  vm-101-disk-1.qcow2
При создании шаблона ВМ все образы дисков ВМ переименовываются, чтобы указать, что они теперь доступны только для чтения и могут использоваться в качестве базового образа для клонов:
base-<VMID>-<NAME>.<FORMAT>

35.3.4. NFS

Хранилище NFS аналогично хранению каталогов и файлов на диске, с дополнительным преимуществом совместного хранения и миграции в реальном времени. Свойства хранилища NFS во многом совпадают с хранилищем типа Каталог. Структура каталогов и соглашение об именах файлов также одинаковы. Основным преимуществом является то, что можно напрямую настроить свойства сервера NFS, и общий ресурс будет монтироваться автоматически.
Данное хранилище поддерживает все общие свойства хранилищ кроме флага shared, который всегда установлен. Кроме того, для настройки NFS используются следующие свойства:
  • server — IP-адрес сервера или DNS-имя. Предпочтительнее использовать IP-адрес вместо DNS-имени (чтобы избежать задержек при поиске DNS);
  • export — совместный ресурс с сервера NFS (список можно просмотреть, выполнив команду pvesm scan nfs <server>);
  • path — локальная точка монтирования (по умолчанию /mnt/pve/<STORAGE_ID>/);
  • options — параметры монтирования NFS.
Пример файла конфигурации (/etc/pve/storage.cfg):
nfs: nfs-storage
        export /export/storage
        path /mnt/nfs-vol
        server 192.168.0.105
        content images,backup,vztmpl,iso
        options vers=3,nolock,tcp

Примечание

Для возможности монтирования NFS хранилища должны быть запущены службы rpcbind и nfslock:
# systemctl enable --now rpcbind
# systemctl enable --now nfslock
Присоединение хранилища NFS с именем nfs-storage с удаленного сервера 192.168.0.105:
Создание хранилища NFS
После ввода IP-адреса удаленного сервера, доступные ресурсы будут автоматически просканированы и будут отображены в выпадающем меню Export. В данном примере обнаруженная в блоке диалога точка монтирования — /export/storage.
Пример добавления хранилища NFS в командной строке с помощью утилиты pvesm:
# pvesm add nfs nfs-storage --path /mnt/nfs-vol --server 192.168.0.105 --options vers=3,nolock,tcp --export /export/storage --content images,iso,vztmpl,backup
Получить список совместных ресурсов с сервера NFC:
# pvesm nfsscan <server>

35.3.5. CIFS

Хранилище CIFS расширяет хранилище типа Каталог, поэтому ручная настройка монтирования CIFS не требуется.

Примечание

Для возможности просмотра общих ресурсов на каждом узле кластера необходимо установить пакет samba-client.
Данное хранилище поддерживает все общие свойства хранилищ кроме флага shared, который всегда установлен. Кроме того, для настройки CIFS используются следующие свойства:
  • server — IP-адрес сервера или DNS-имя. Предпочтительнее использовать IP-адрес вместо DNS-имени (чтобы избежать задержек при поиске DNS);
  • share — совместный ресурс с сервера CIFS (список можно просмотреть, выполнив команду pvesm scan cifs <server>);
  • username — имя пользователя для хранилища CIFS (необязательно, по умолчанию «guest»);
  • password — пароль пользователя (необязательно). Пароль будет сохранен в файле, доступном только для чтения root-пользователю (/etc/pve/priv/<STORAGE_ID>.cred);
  • domain — устанавливает домен пользователя (рабочую группу) для этого хранилища (необязательно);
  • smbversion — версия протокола SMB (необязательно, по умолчанию 3);
  • path — локальная точка монтирования (по умолчанию /mnt/pve/<STORAGE_ID>/).
Пример файла конфигурации (/etc/pve/storage.cfg):
cifs: newCIFS
        path /mnt/pve/newCIFS
        server 192.168.0.105
        share smb_data
        smbversion 2.1
Получить список совместных ресурсов с сервера CIFS можно, выполнив команду:
pvesm cifsscan <server> [--username <username>] [--password]
Команда добавления общего ресурса в качестве хранилища:
pvesm add cifs <storagename> --server <server> --share <share> [--username <username>] [--password]
Подключение хранилища CIFS с именем newCIFS с удаленного сервера 192.168.0.105:
Добавление CIFS хранилища
После ввода IP-адреса удаленного сервера, доступные ресурсы будут автоматически просканированы и будут отображены в выпадающем меню Share.

Примечание

При создании CIFS хранилища в веб-интерфейсе, PVE предполагает, что удаленный сервер поддерживает CIFS v3. В веб-интерфейсе нет возможности указать версию CIFS, поэтому в случае, если удалённый сервер поддерживает версии CIFS отличные от v3, создать хранилище можно в командной строке, например:
# pvesm add cifs newCIFS --server 192.168.0.105 --share smb_data --smbversion 2.1

35.3.6. GlusterFS

GlusterFS — это масштабируемая сетевая файловая система. Система использует модульную конструкцию, работает на аппаратном оборудовании и может обеспечить высокодоступное корпоративное хранилище при низких затратах. Такая система способна масштабироваться до нескольких петабайт и может обрабатывать тысячи клиентов.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • server — IP-адрес или DNS-имя сервера GlusterFS;
  • server2 — IP-адрес или DNS-имя резервного сервера GlusterFS;
  • volume — том GlusterFS;
  • transport — транспорт GlusterFS: tcp, unix или rdma.
Пример файла конфигурации (/etc/pve/storage.cfg):
glusterfs: gluster-01
        server 192.168.0.105
        server2 192.168.0.110
        volume glustervol
        content images,iso
Подключение хранилища GlusterFS с именем gluster-01 с удаленного сервера 192.168.0.105:
Создание хранилища GlusterFS

35.3.7. Локальный ZFS

Примечание

Для работы с локальным ZFS хранилищем должен быть установлен модуль ядра kernel-modules-zfs-std-def. Включить модуль:
# modprobe zfs
Чтобы не вводить эту команду после перезагрузки, следует раскомментировать строку:
#zfs
в файле /etc/modules-load.d/zfs.conf.
Локальный ZFS позволяет получить доступ к локальным пулам ZFS (или файловым системам ZFS внутри таких пулов).
Данное хранилище поддерживает все общие свойства хранилищ, кроме того, для настройки ZFS используются следующие свойства:
  • pool — пул/файловая система ZFS;
  • blocksize — размер блока;
  • sparse — использовать тонкую инициализацию ZFS.
Пул ZFS поддерживает следующие типы RAID:
  • RAID-0 (Single Disk) — размер такого пула — сумма емкостей всех дисков. RAID0 не добавляет избыточности, поэтому отказ одного диска делает том не пригодным для использования (минимально требуется один диск);
  • пул RAID-1 (Mirror) — данные зеркалируются на все диски (минимально требуется два диска);
  • пул RAID-10 — сочетание RAID0 и RAID1 (минимально требуется четыре диска);
  • пул RAIDZ-1 — вариация RAID-5, одинарная четность (минимально требуется три диска);
  • пул RAIDZ-2 — вариация на RAID-5, двойной паритет (минимально требуется четыре диска);
  • пул RAIDZ-3 — разновидность RAID-5, тройная четность (минимально требуется пять дисков).
Пример файла конфигурации (/etc/pve/storage.cfg):
zfspool: vmdata
        pool vmdata
        content images,rootdir
        mountpoint /vmdata
        nodes pve03
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw или subvol).
Используется следующая схема именования образов дисков ВМ:
  • vm-<VMID>-<NAME> — образ ВМ;
  • base-<VMID>-<NAME> — шаблон образа ВМ (только для чтения);
  • subvol-<VMID>-<NAME> — файловая система ZFS для контейнеров.

35.3.7.1. Создание локального хранилища ZFS в веб-интерфейсе

Для создания локального хранилища ZFS в веб-интерфейсе, следует выбрать узел, на котором будет создано хранилище, в разделе Диски (Disks) выбрать пункт ZFS и нажать кнопку Создать: ZFS:
Добавление ZFS хранилища
В открывшемся окне следует задать параметры ZFS хранилища: имя хранилища, выбрать диски, уровень RAID и нажать кнопку Создать:
Параметры ZFS хранилища
Статус пула можно просмотреть выбрав его в списке и нажав кнопку Подробно:
Локальное ZFS хранилище
Для того чтобы внести изменения в настройки ZFS хранилища следует выбрать ДатацентрХранилище (DatacenterStorage), затем нужное хранилище и нажать кнопку Редактировать:
Выбор хранилища для редактирования
В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище, включить дисковое резервирование:
Редактирование ZFS хранилища

35.3.7.2. Администрирование ZFS

Основными командами для управления ZFS являются zfs и zpool.
Для создания нового пула необходим как минимум один пустой диск.
Создание нового пула RAID-0 (минимум 1 диск):
zpool create -f -o ashift=12 <pool> <device1> <device2>
Создание нового пула RAID-1 (минимум 2 диска):
zpool create -f -o ashift=12 <pool> mirror <device1> <device2>
Создание нового пула RAID-10 (минимум 4 диска):
zpool create -f -o ashift=12 <pool> mirror <device1>
<device2> mirror <device3> <device4>
Создание нового пула RAIDZ-1 (минимум 3 диска):
zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>
Создание нового пула RAIDZ-2 (минимум 4 диска):
zpool create -f -o ashift=12 <pool> raidz2 <device1>
<device2> <device3> <device4>
Смена неисправного устройства:
zpool replace -f <pool> <old device> <new device>
Включить сжатие:
zfs set compression=on <pool>
Получить список доступных ZFS файловых систем:
# pvesm zfsscan
Пример создания RAID1(mirror) с помощью zfs:
# zpool create -f vmdata mirror sdb sdc
Просмотреть созданные в системе пулы:
# zpool list
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
vmdata  17,5G   492K  17,5G        -         -     0%     0%  1.00x    ONLINE  -
Просмотреть статус пула:
# zpool status
  pool: vmdata
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    vmdata      ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0

errors: No known data errors

35.3.8. LVM

LVM (Logical Volume Management) это система управления дисковым пространством. Позволяет логически объединить несколько дисковых пространств (физические тома) в одно, и уже из этого пространства (дисковой группы или группы томов — VG), можно выделять разделы (логические тома — LV), доступные для работы.
Использование LVM групп обеспечивает лучшую управляемость. Логические тома можно легко создавать/удалять/перемещать между физическими устройствами хранения. Если база хранения для группы LVM доступна на всех PVE узлах (например, ISCSI LUN) или репликах (например, DRBD), то все узлы имеют доступ к образам ВМ, и возможна live-миграция.
Данное хранилище поддерживает все общие свойства хранилищ, кроме того, для настройки LVM используются следующие свойства:
  • vgname — имя группы томов LVM (должно указывать на существующую группу томов);
  • base — базовый объем;
  • saferemove — обнуление данных при удалении LV. При удалении тома это гарантирует, что все данные будут удалены;
  • saferemove_throughput — очистка пропускной способности (значение параметра cstream -t).
Пример файла конфигурации (/etc/pve/storage.cfg):
lvm: vg
    vgname vg
    content rootdir,images
    nodes pve03
    shared 0
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw).

35.3.8.1. Создание локального LVM хранилища в веб-интерфейсе

Примечание

Для создания локального LVM хранилища в веб-интерфейсе необходимо чтобы в системе имелся хотя бы один пустой жесткий диск.
Для создания локального LVM хранилища в веб-интерфейсе, следует выбрать узел, на котором будет создано хранилище, в разделе Диски (Disks) выбрать пункт LVM и нажать кнопку Создать: Volume Group:
Пункт LVM в разделе Диски
В открывшемся окне следует выбрать диск, задать имя группы томов, отметить пункт Add Storage (если этот пункт не отмечен будет создана только группа томов) и нажать кнопку Создать:
Создание группы томов
Для того чтобы внести изменения в настройки LVM хранилища следует выбрать ДатацентрХранилище (DatacenterStorage), затем нужное хранилище и нажать кнопку Редактировать. В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище:
Редактирование LVM хранилища

35.3.8.2. Создание хранилища LVM в командной строке

Пример создания LVM хранилища на пустом диске /dev/sdd:
  1. Создать физический том (PV):
    # pvcreate /dev/sdd
      Physical volume "/dev/sdd" successfully created.
    
  2. Создать группу томов (VG) с именем vg:
    # vgcreate vg /dev/sdd
      Volume group "vg" successfully created
    
  3. Создать логические тома (LV):
    # lvcreate -n lv01 -L 10G vg
      Logical volume "lv01" created.
    # lvcreate -n lv02 -L 5G vg
      Logical volume "lv02" created.
    
  4. Показать информацию о физических томах:
    # pvs
    PV         VG        Fmt  Attr PSize   PFree
      /dev/sdd   vg        lvm2 a--  <18,00g <3,00g
    
  5. Показать информацию о группах томов:
    # vgs
      VG        #PV #LV #SN Attr   VSize   VFree
      vg          1   2   0 wz--n- <18,00g <3,00g
    
  6. Показать информацию о логических томах:
    # lvs
      LV        VG        Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
      lv01      vg        -wi-a----- 10,00g
      lv02      vg        -wi-a-----  5,00g
    
  7. Получить список доступных PVE групп томов:
    # pvesm lvmscan
    vg
    
  8. Создать LVM хранилище с именем myspace:
    # pvesm add lvm myspace --vgname vg --nodes pve03
    

35.3.9. LVM-Thin

LVM-Thin (thin provision) — это возможность использовать какое-либо внешнее блочное устройство в режиме только для чтения как основу для создания новых логических томов LVM. Такие разделы при создании уже будут выглядеть так, будто они заполнены данными исходного блочного устройства. Операции с томами изменяются налету таким образом, что чтение данных выполняется с исходного блочного устройства (или с тома, если данные уже отличаются), а запись — на том.
Такая возможность может быть полезна, например, при создании множества однотипных ВМ или для решения других аналогичных задач, т.е. задач, где нужно получить несколько изменяемых копий одних и тех же исходных данных.
Данное хранилище поддерживает все общие свойства хранилищ, кроме того, для настройки LVM-Thin используются следующие свойства:
  • vgname — имя группы томов LVM (должно указpvesm lvmscanывать на существующую группу томов);
  • thinpool — название тонкого пула LVM.
Пример файла конфигурации (/etc/pve/storage.cfg):
lvmthin: vmstore
        thinpool vmstore
        vgname vmstore
        content rootdir,images
        nodes pve03
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw).
LVM-Thin является блочным хранилищем, но полностью поддерживает моментальные снимки и клоны. Новые тома автоматически инициализируются с нуля.
Тонкие пулы LVM не могут совместно использоваться несколькими узлами, поэтому их можно использовать только в качестве локального хранилища.

35.3.9.1. Создание локального LVM-Thin хранилища в веб-интерфейсе

Примечание

Для создания локального LVM-Thin хранилища в веб-интерфейсе необходимо чтобы в системе имелся хотя бы один пустой жесткий диск.
Для создания локального LVM-Thin хранилища в веб-интерфейсе, следует выбрать узел, на котором будет создано хранилище, в разделе Диски (Disks) выбрать пункт LVM-Thin и нажать кнопку Создать: Thinpool:
Пункт LVM-Thin в разделе Диски
В открывшемся окне следует выбрать диск, задать имя группы томов, отметить пункт Add Storage (если этот пункт не отмечен будет создана только группа томов) и нажать кнопку Создать:
Создание LVM-Thin хранилища
Для того чтобы внести изменения в настройки LVM-Thin хранилища следует выбрать ДатацентрХранилище (DatacenterStorage), затем нужное хранилище и нажать кнопку Редактировать. В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище:
Редактирование LVM-Thin хранилища

35.3.9.2. Создание хранилища LVM-Thin в командной строке

Для создания и управления пулами LVM-Thin можно использовать инструменты командной строки.
Пул LVM-Thin должен быть создан поверх группы томов.
Команда создания нового тонкого пула LVM (размер 80 ГБ) с именем vmstore (предполагается, что группа томов LVM с именем vg уже существует):
# lvcreate -L 80G -T -n vmstore vg
Получить список доступных LVM-Thin пулов в группе томов vg:
# pvesm lvmthinscan vg
vmstore
Команда создания LVM-Thin хранилища с именем vmstore на узле pve03:
# pvesm add lvmthin vmstore --thinpool vmstore --vgname vg --nodes pve03

35.3.10. iSCSI

iSCSI (Internet Small Computer System Interface) — широко применяемая технология, используемая для подключения к серверам хранения.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • portal — IP-адрес или DNS-имя сервера iSCSI;
  • target — iSCSI target.
Пример файла конфигурации (/etc/pve/storage.cfg):
iscsi: test1-iSCSI
    portal 192.168.0.105
    target iqn.2021-7.local.omv:test
    content images
Возможные типы содержимого: images (образ виртуального диска в формате raw).
iSCSI является типом хранилища блочного уровня и не предоставляет интерфейса управления. Поэтому обычно лучше экспортировать одно большое LUN и установить LVM поверх этого LUN.

Примечание

Для работы с устройством, подключенным по интерфейсу iSCSI, на всех узлах необходимо выполнить команду (должен быть установлен пакет open-iscsi):
# systemctl enable --now iscsid
Добавление адресата iSCSI с именем test1-iSCSI, который настроен на удаленном узле 192.168.0.105:
Добавление хранилища типа iSCSI
Параметр Использовать LUN напрямую (Use LUNs directly) — разрешение/запрет прямого применения LUN (параметр должен быть установлен на запрет, разрешение может привести к потере данных).
Посмотреть доступные для подключения iSCSI target-ы:
pvesm scan iscsi <HOST[:PORT]>

35.3.11. Ceph RBD

Хранилище RBD (Rados Block Device) предоставляется распределенной системой хранения Ceph. По своей архитектуре Ceph является распределенной системой хранения. Хранилище RBD может содержать только форматы образов .raw.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • monhost — список IP-адресов демона монитора (только если Ceph не работает на кластере PVE);
  • pool — название пула Ceph (rbd);
  • username — идентификатор пользователя Ceph (только если Ceph не работает на кластере PVE);
  • subdir — подкаталог CephFS для монтирования (по умолчанию /);
  • fuse — доступ к CephFS через FUSE (по умолчанию 0).
Пример файла конфигурации (/etc/pve/storage.cfg):
rbd: new
    content images
    krbd 0
    monhost 192.168.0.105
    pool rbd
    username admin
Возможные типы содержимого: rootdir (данные контейнера), images (образ виртуального диска в формате raw).
Добавление хранилища RBD:
Добавление хранилища типа RBD

35.3.12. CephFS

CephFS реализует POSIX-совместимую файловую систему, использующую кластер хранения Ceph для хранения своих данных. Поскольку CephFS основывается на Ceph, он разделяет большинство свойств, включая избыточность, масштабируемость, самовосстановление и высокую доступность.
Данное хранилище поддерживает все общие свойства хранилищ, и дополнительно используются следующие свойства:
  • monhost — список IP-адресов демона монитора (только если Ceph не работает на кластере PVE);
  • path — локальная точка монтирования (по умолчанию используется /mnt/pve/<STORAGE_ID>/);
  • username — идентификатор пользователя (только если Ceph не работает на кластере PVE);
  • krbd — доступ к блочным устройствам через модуль ядра krbd.
Пример файла конфигурации (/etc/pve/storage.cfg):
cephfs: cephfs-external
    content backup,images
    monhost 192.168.0.105
    username admin
Возможные типы содержимого: vztmpl (шаблон контейнера), iso (ISO-образ), backup (резервная копия), snippets (сниппеты).
Добавление хранилища CephFS:
Добавление хранилища CephFS

Глава 36. Управление ISO образами и шаблонами LXC

Для выгрузки ISO образов и шаблонов в хранилище PVE следует выполнить следующие шаги:
  1. Выбрать хранилище.
  2. Перейти на вкладку ISO Images или CT Templates для отображения сохраненных в хранилище ISO образов или шаблонов LXC:
    Локальное хранилище
    Если загруженных файлов не существует, доступна только кнопка Загрузить (Upload).
  3. Нажать кнопку Загрузить (Upload) для открытия диалогового блока.
  4. Нажать кнопку Выбрать файл… (Select File...) для выбора файла для выгрузки с локального компьютера:
    Выбор образа
  5. Нажать кнопку Загрузить (Upload) для старта выгрузки файла в хранилище.
Для удаления ISO образа или шаблона LXC следует выбрать файл из списка в хранилище и нажать кнопку Удалить (Remove).
ISO образы и шаблоны LXC могут также копироваться через интерфейс командной строки. Если используются только локальные хранилища, эти образы ISO и шаблоны необходимо выгрузить на все узлы в кластере. При общем хранилище можно хранить все образы в одном месте, таким образом, сохраняя пространство локальных хранилищ.

Таблица 36.1. Каталоги локального хранилища

Каталог
Тип шаблона
/var/lib/vz/template/iso/
ISO образы
/var/lib/vz/template/cache/
Шаблоны контейнеров LXC

Таблица 36.2. Каталоги общих хранилищ

Каталог
Тип шаблона
/mnt/pve/<storage_name>/template/iso/
ISO образы
/mnt/pve/<storage_name>/template/cache/
Шаблоны контейнеров LXC

Глава 37. Виртуальные машины на базе KVM

Виртуальные машины являются строительными блоками виртуальной среды.

37.1. Создание виртуальной машины на базе KVM

Прежде чем создать в интерфейсе PVE виртуальную машину (ВМ), необходимо определиться со следующими моментами:
  • откуда будет загружен инсталлятор ОС, которая будет установлена внутрь ВМ;
  • плавное расширение пространства хранения с множеством узлов;
  • на каком физическом узле будет выполняться процесс гипервизора kvm;
  • на каком хранилище данных будут располагаться образы дисков ВМ.
Все остальные параметры ВМ относятся к конфигурации виртуального компьютера и могут быть определены по ходу процесса создания ВМ (PVE пытается выбрать разумные значения по умолчанию для ВМ).
Чтобы установить ОС на ВМ, расположенную на этом узле, нужно обеспечить возможность загрузки инсталлятора на этой ВМ. Для этого необходимо загрузить ISO-образ инсталлятора в хранилище данных выбранного физического узла или общее хранилище. Это удобно делать в веб-интерфейсе (см. Управление ISO образами и шаблонами LXC).
Для создания ВМ необходимо нажать кнопку Создать VM (Create VM), расположенную в правом верхнем углу веб-интерфейса PVE:
Кнопка Создать VM
Процесс создания ВМ оформлен в виде «мастера», привычного для пользователей систем управления ВМ.
На вкладке Общее необходимо указать:
  • Узел (Node) — физический сервер, на котором будет работать ВМ;
  • VM ID — идентификатор ВМ в численном выражении. Одно и то же значение идентификатора не может использоваться более чем для одной машины. Поле идентификатора ВМ заполняется автоматически инкрементально: первая созданная ВМ по умолчанию будет иметь VM ID со значением 100, следующая 101 и так далее;
  • Имя (Name) — текстовая строка названия ВМ;
  • Пул ресурсов (Resource pool) — имя пула данной ВМ, к которому она будет относиться. Данное значение не обязательное.test Чтобы иметь возможность выбора, этот пул должен быть предварительно создан.
Вкладка Общее
На вкладке ОС необходимо указать источник установки ОС, выбрать тип операционной системы для данной ВМ:
Вкладка ОС
Возможны следующие варианты источник установки ОС:
  • Использовать файл с образом CD/DVD (Use CD/DVD disc image file) — выбирает уже выгруженный в хранилище образ ISO:
    Выбор ISO образа
  • Использовать привод CD/DVD (Use physical CD/DVD Drive) — использовать физический диск хоста PVE;
  • Нет носителя (Do not use any media) — не использовать ISO образ или физический носитель.
Выбор типа гостевой ОС при создании ВМ позволяет PVE оптимизировать некоторые параметры низкого уровня.
На следующем этапе (вкладка Система) можно выбрать видеокарту, контроллер SCSI, указать использовать ли Агент QEMU:
Вкладка Система
Вкладка Жесткий диск (Hard Disk) содержит следующие настройки:
  • Шина/Устройство (Bus/Device) — тип устройства виртуального диска. Допустимые значения: IDE, SATA, VirtIO Block и SCSI (по умолчанию). Можно также выбрать номер порта;
  • Хранилище (Storage) — выбор хранилища для размещения данного виртуального диска;
  • Размер диска (Disk size) (GiB) — размер виртуального диска в гигабайтах;
  • Формат (Format) — выбирается формат образа виртуального диска. Доступные значения: Несжатый образ диска (raw), Формат образа QEMU (qcow2) и Формат образа Vmware (vmdk). Формат образа RAW является полностью выделяемым (thick-provisioned), т.е. выделяется сразу весь объем образа. QEMU и VMDK поддерживают динамичное выделение пространства (thin-provisioned), т.е. объем растет по мере сохранения данных на виртуальный диск;
  • Кэш (Cache) — выбор метода кэширования ВМ. По умолчанию выбирается работа без кэширования. Доступные значения: Direct sync, Write through, Write back и Writeback (не безопасно) и Нет кэша;
  • Отклонить (Discard) — делает доступным TRIM, что очищает неиспользуемое пространство образа виртуального диска.
Вкладка Жесткий диск
Максимальный объем виртуального диска — 128 ТБ.
На следующем этапе настраивается процессор (CPU):
  • Сокеты (Sockets) — число сокетов ЦПУ для данной ВМ;
  • Ядра (Cores) — число ядер для данной ВМ;
  • Тип (Type) — тип процессора.
Вкладка Процессор
Максимальное количество виртуальных процессоров в ВМ — 512.
На вкладке Память (Memory) необходимо указать объем оперативной памяти выделяемой ВМ:
Вкладка Память
Максимальное количество памяти, выделяемое ВМ — 2ТБ.
Вкладка Сеть (Network) содержит следующие настройки:
  • Нет сетевого устройства (No network device) — выбор данного параметра пропускает шаг настройки сетевой среды;
  • Сетевой мост (Bridged mode) — установка сетевого интерфейса в режиме моста. Это предпочтительный параметр для сетевой среды ВМ. В этом режиме возможно создание множества мостов с виртуальными сетями для создания изолированных сетей в одной и той же платформе, поскольку ВМ не имеют прямого доступа к реальной локальной сетевой среде;
  • Брандмауэр (Firewall) — разрешает использование для ВМ встроенных межсетевых экранов;
  • Модель (Model) — тип драйвера сетевого устройства. Для максимальной сетевой производительности ВМ следует выбрать пункт VirtIO (паравиртуализированно);
  • Адрес MAC (MAC address) — по умолчанию PVE автоматически создает уникальный MAC адрес для сетевого интерфейса. Если есть такая необходимость, можно ввести пользовательский MAC адрес вручную.
Вкладка Сеть
Последняя вкладка Подтверждение (Confirm) отобразит все введенные или выбранные значения для данной ВМ:
Вкладка Подтверждение
Для создания ВМ следует нажать кнопку Далее. Если необходимо внести изменения в параметры ВМ, можно перейти по вкладкам назад. Если отметить пункт Start after created ВМ будет запущена после создания.

37.2. Внесение изменений в ВМ

Вносить изменения в конфигурацию ВМ можно и после ее создания. Для того чтобы внести изменения в конфигурацию ВМ необходимо выбрать ВМ и перейти на вкладку Оборудование (Hardware). На этой вкладке следует выбрать технические средства и нажать кнопку Редактировать (Edit) для выполнения изменений:
Оборудование ВМ
Эти изменения могут не вступить в действие сразу, и может потребоваться выключение с последующим включением ВМ для инициализации данных аппаратных изменений.

37.3. Управление ВМ с помощью qm

Если веб-интерфейс PVE недоступен, можно управлять ВМ при помощи командной строки (либо через сеанс SSH, либо из консоли noVNC, или зарегистрировавшись на физическом хосте).
qm — это инструмент для управления ВМ Qemu/KVM в PVE. Утилиту qm можно использовать для создания/удаления ВМ, для контроля выполнения (запуск/остановка/приостановка/возобновление), для установки параметров в соответствующем конфигурационном файле, а также для создания виртуальных дисков.
Чтобы просмотреть доступные для ВМ команды PVE можно выполнить следующую команду:
# qm help
Примеры использования утилиты qm:
  • создать ВМ, используя ISO-файл, загруженный в локальное хранилище, с диском IDE 21 ГБ, в хранилище local-lvm:
    # qm create 300 -ide0 local-lvm:21 -net0 e1000 -cdrom local:iso/alt-server-9.1-x86_64.iso
    
  • запуск ВМ:
    # qm start 300
    
  • отправить запрос на отключение, и дождаться остановки ВМ:
    # qm shutdown 300 && qm wait 300
    

37.4. Файлы конфигурации ВМ

Файлы конфигурации ВМ хранятся в файловой системе кластера PVE и доступны по адресу /etc/pve/qemu-server/<VMID>.conf. Как и другие файлы, хранящиеся в /etc/pve/, они автоматически реплицируются на все другие узлы кластера.

Примечание

VMID < 100 зарезервированы для внутренних целей. VMID должны быть уникальными для всего кластера.
Пример файла конфигурации:
boot: order=scsi0;scsi7;net0
cores: 1
memory: 512
name: newVM
net0: virtio=C6:E4:55:03:79:5A,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local:100/vm-100-disk-0.qcow2,size=32G
scsi7: local:iso/alt-server-9.1-x86_64.iso,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=a4ce5cab-f4df-4bde-a19b-6b9f3ebbaddb
sockets: 1
vmgenid: a1109827-0dc7-4d91-8625-1cff91c23d33c
Файлы конфигурации ВМ используют простой формат: разделенные двоеточиями пары ключ/значение (пустые строки игнорируются, строки, начинающиеся с символа #, рассматриваются как комментарии и также игнорируются):
OPTION: value
Для применения изменений, которые напрямую вносились в файл конфигурации, необходимо перезапустить ВМ. По этой причине рекомендуется использовать команду qm для генерации и изменения этих файлов, либо выполнять такие действия в веб-интерфейсе.
При создании снимка ВМ, конфигурация ВМ во время снимка, сохраняется в этом же файле конфигурации в отдельном разделе. Например, после создания снимка «snapshot» файл конфигурации будет выглядеть следующим образом:
bootdisk: scsi0
…
parent: snapshot
…
vmgenid: a1109827-0dc7-4d91-8625-1cff91c23d33

[snapshot]
bootdisk: scsi0
cores: 1
memory: 512
name: newVM
net0: virtio=C6:E4:55:03:79:5A,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
runningmachine: pc-i440fx-4.1
scsi0: local:100/vm-100-disk-0.qcow2,size=32G
scsi7: local:iso/alt-server-9.1-x86_64.iso,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=a4ce5cab-f4df-4bde-a19b-6b9f3ebbaddb
snaptime: 1595498248
sockets: 1
vmgenid: a1109827-0dc7-4d91-8625-1cff91c23d33
vmstate: local:100/vm-100-state-snapshot.raw
Свойство parent при этом используется для хранения родительских/дочерних отношений между снимками, а snaptime — это отметка времени создания снимка (эпоха Unix).

37.5. Запуск и останов ВМ

37.5.1. Изменение состояния ВМ в веб-интерфейсе

Для запуска ВМ следует выбрать ее в левой панели; иконка ВМ должна быть серого цвета, обозначая, что ВМ не запущена.
Запустить ВМ можно, выбрав в контекстном меню ВМ пункт Запуск:
Контекстное меню ВМ
либо нажав на кнопку Запуск (Start):
Кнопки управления состоянием ВМ
Запущенная ВМ будет обозначена зеленой стрелкой на значке ВМ.
Для запущенной ВМ доступны следующие действия:
  • Пауза (Pause) — перевод ВМ в спящий режим;
  • Hibernate — перевод ВМ в ждущий режим;
  • Выключить (Shutdown) — выключение ВМ;
  • Остановка (Stop) — остановка ВМ, путем прерывания ее работы;
  • Перезапустить (Reboot) — перезапустить ВМ.
Контекстное меню запущенной ВМ

37.5.2. Изменение состояний ВМ в командной строке

Состоянием ВМ можно управлять из командной строки PVE (либо через сеанс SSH, либо из консоли noVNC, или зарегистрировавшись на физическом хосте).
Для запуска ВМ с VM ID 105 необходимо ввести команду:
# qm start 105
Эта же ВМ может быть остановлена при помощи команды:
# qm stop 105

37.6. Автоматический запуск ВМ

Для того чтобы ВМ запускалась автоматически при загрузке хост-системы, необходимо выбрать опцию Запуск при загрузке на вкладке Параметры требуемой ВМ в веб-интерфейсе или установить ее с помощью следующей команды:
# qm set <vmid> -onboot 1
Иногда необходимо точно настроить порядок загрузки ВМ, например, если одна из ВМ обеспечивает межсетевой экран или DHCP для других гостевых систем. Для настройки порядка запуска ВМ можно использовать следующие параметры (опция Порядок запуска и выключения на вкладке Параметры требуемой ВМ):
  • Порядок запуска и выключения (Start/Shutdown order) — определяет приоритет порядка запуска. Для того чтобы ВМ запускалась первой необходимо установить этот параметр в значение 1 (для выключения используется обратный порядок: ВМ машина с порядком запуска 1 будет выключаться последней). Если несколько хостов имеют одинаковый порядок, определенный на хосте, они будут дополнительно упорядочены в порядке возрастания VMID;
  • Задержка запуска (Startup delay) — определяет интервал (в секундах) между запуском этой ВМ и последующими запусками ВМ;
  • Задержка выключения (Shutdown timeout) — определяет продолжительность в секундах, в течение которой PVE должен ожидать, пока ВМ не будет в автономном режиме после выдачи команды выключения. По умолчанию это значение установлено равным 180 — PVE выдаст запрос на отключение и подождет 180 секунд, пока машина не будет в автономном режиме. Если машина все еще находится в сети после истечения времени ожидания, она будет принудительно остановлена.
Настройка порядка запуска и выключения ВМ

Примечание

ВМ, управляемые стеком HA, в настоящее время не поддерживают параметры запуска при загрузке и порядка загрузки.
ВМ без настроенного параметра Порядок запуска и выключения всегда будут запускаться после тех, для которых установлен этот параметр. Кроме того, этот параметр может быть применен только для ВМ, работающих на одном хосте, но не для всего кластера.

37.7. Управление образами виртуальных дисков

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

37.7.1. Поддерживаемые форматы образов

PVE поддерживает форматы виртуальных дисков .raw, .qcow2 и .vmdk. Каждый формат имеет свои преимущества и недостатки. Формат образа обычно выбирается на основании функции ВМ, используемой системы хранения, требующейся производительности и доступного бюджета. В процессе создания виртуального диска в веб-интерфейсе можно выбрать формат диска:
Выбор формата виртуального диска
Формат образа qcow2 (QEMU image format) — универсальный формат для выполнения любых задач. Его преимущество в том, что файл с данными будет содержать только реально занятое место внутри ВМ. Например, если было выделено 40 ГБ места, а реально было занято только 2 ГБ, то все остальное место будет доступно для других ВМ. По мере сохранения пользователем данных в этой ВМ, такой образ будет постепенно увеличиваться в размере. Формат образа .qcow2 позволяет администратору превышать обеспечение ВМ файлом образа диска .qcow2. В таких средах необходимо постоянно наблюдать за доступным пространством хранения. Все операции ввода-вывода при использовании этого формата программно обрабатываются, что влечет за собой замедление при активной работе с дисковой подсистемой. Если стоит задача развернуть на сервере базу данных, то лучше выбрать формат RAW. Создаваемые из образа qcow2 резервные копии могут восстанавливаться только в NFS или локальный каталог.
Формат образа raw — это файл с данными жесткого диска «байт в байт» без сжатия или оптимизации. Его главное преимущество состоит в производительности — это самый быстрый «тип» накопителя, так как гипервизору не нужно его никак обрабатывать. Формат .raw может создавать только файлы образов ВМ фиксированного размера с предварительным выделением (thick-provisioned). Например, создаваемая ВМ с пространством хранения 50 ГБ будет иметь файл образа 50 ГБ. При этом администратор точно знает, сколько пространства используется, поэтому отсутствует возможность неуправляемого выхода за пределы хранения. Формат образа .raw может восстанавливаться практически на любой тип системы хранения.
Формат образа vmdk (VMware image format) очень распространен в инфраструктуре VMware. Он позволяет выполнить миграцию виртуальной машины VMware в инфраструктуру PVE.

37.7.2. Управление образами виртуальных дисков

Для управления образами виртуальных дисков ВМ необходимо выбрать нужную ВМ в меню навигации и перейти на вкладку Оборудование (Hardware). После выбора образа диска становятся доступными все связанные меню, такие как Добавить (Add), Отключить (Remove), Редактировать (Edit), Изменить размер диска (Resize disk), Переместить диск (Move disk):
Вкладка Оборудование

37.7.2.1. Добавление виртуального диска в ВМ

Для добавления образа виртуального диска к ВМ необходимо:
  1. Перейти на вкладку Оборудование (Hardware);
  2. Нажать кнопку Добавить (Add) и выбрать в выпадающем списке пункт Жесткий диск (Hard Disk):
    Кнопка «Добавить» → «Жесткий диск»
  3. После ввода необходимых значений нажать кнопку Добавить (Add) для завершения добавления виртуального диска:
    Опции добавления жесткого диска
    В примере добавляется образ виртуального диска объемом 32 ГБ в виртуальную машину 100.

37.7.2.2. Удаление образа виртуального диска

Для удаления образа виртуального диска к ВМ необходимо:
  1. Перейти на вкладку Оборудование (Hardware);
  2. Выбрать образ диска ВМ;
  3. Нажать кнопку Отключить (Remove);
  4. В окне подтверждения нажать кнопку Да (Yes) для подтверждения действия. При этом виртуальный диск будет отсоединен от ВМ, но не удален полностью. Он будет присутствовать в списках как Неиспользуемый диск (Unused Disk):
    Неиспользуемый диск
Чтобы удалить образ диска окончательно, следует выбрать неиспользуемый диск и нажать кнопку Удалить (Remove).
Если образ диска был отключен от ВМ по ошибке, можно повторно подключить его к ВМ, выполнив следующие действия:
  1. Выбрать неиспользуемый диск;
  2. Нажать кнопку Редактировать (Edit);
  3. В открывшемся диалоговом окне изменить, если это необходимо, параметры Шина/Устройство (Bus/Device):
    Подключение неиспользуемого диска
  4. Нажать кнопку Добавить (Add) для повторного подключения образа диска.

37.7.2.3. Изменение размера диска

Функция изменения размера поддерживает только увеличение размера файла образа виртуального диска. При изменении размера образа виртуального диска изменяется только размер файла образа виртуального диска. После изменения размера файла, разделы жесткого диска должны быть изменены внутри самой ВМ.
Для изменения размера виртуального диска необходимо:
  1. Перейти на вкладку Оборудование (Hardware);
  2. Выбрать образ диска ВМ;
  3. Нажать кнопку Изменить размер диска (Resize disk);
  4. В открывшемся диалоговом окне в поле Увеличение размера (GiB) ввести значение увеличения размера диска. Например, если размер существующего диска составляет 20 ГБ, следует ввести 10 для изменения размера диска до 30 ГБ:
    Изменение размера диска
  5. Нажать кнопку Изменить размер диска (Resize Disk) для завершения изменения размера.
Команда изменения размера виртуального диска:
#  qm resize <vm_id> <virtual_disk> +<size>G

37.7.2.4. Перемещение диска на другое хранилище

Образы виртуального диска могут перемещаться с одного хранилища на другое в пределах одного кластера. Данные шаги выполнят задачу для перемещения образа диска:
  1. Перейти на вкладку Оборудование (Hardware);
  2. Выбрать образ перемещаемого виртуального диска;
  3. Нажать кнопку Переместить диск (Move disk);
  4. В открывшемся диалоговом окне выбрать в выпадающем меню Целевое хранилище (Target Storage) — хранилище-получатель, место, куда будет перемещен образ виртуального диска:
    Диалоговое окно перемещения диска
  5. Выбрать в выпадающем меню Формат (Format) образ диска, если это необходимо. Этот параметр полезен для преобразования образов диска из одного формата в другой;
  6. Отметить, если это необходимо, пункт Удалить источник (Delete source) для удаления образа диска источника после его перемещения в новое хранилище;
  7. Нажать кнопку Переместить диск (Move disk) для запуска перемещения образа диска.

37.7.3. Управление дисками в командной строке

В комплект PVE входит утилита qemu-img. qemu-img — утилита для манипулирования с образами дисков машин QEMU. Она поддерживает несколько подкоманд:
  • create
  • commit
  • convert
  • info
Команда преобразования (конвертирования) vmdk-образа виртуального накопителя VMware под названием test в формат qcow2:
# qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2
Создать образ test в формате RAW, размером 40 ГБ:
# qemu-img create -f raw test.raw 40G
Изменение размера виртуального диска:
# qemu-img resize -f raw test.raw 80G
Просмотр информации об образе:
# qemu-img info test.raw

37.7.4. Кэширование виртуального диска

Параметр настройки кэширования доступен в диалоговом окне создания или изменений текущего образа диска ВМ:
Выбор типа кэширования
Доступны следующие виды кэширования:
  • Нет кэша (No cache) — опция кэширования по умолчанию. При этой опции кэширования на уровне хоста не происходит, однако гостевые ВМ выполняют кэширование отложенной записи. Диск такой ВМ напрямую получает подтверждение от устройства хранения. В случае внезапного отключения питания существует большой риск потери данных. Данный тип кэширования представляет хорошее соотношение производительности и безопасности;
  • Write through (кэш сквозной записи) — использует «host cache» для чтения. При этом типе кэширования подтверждение на запись выдается только когда данные зафиксированы на устройстве хранения. Writethrough выполняет fsync (синхронизация находящихся данных в памяти с диском) для каждой записи. Это более безопасный режим кеширования, так как возможность потери данных стремится к нулю, однако при этом более медленный;
  • Direct sync (прямая синхронизация) — хост не производит никакого кэширования, т.е. читает всегда напрямую с блочного устройства (это может быть RAID контроллер) и пишет в блочное устройства (это может быть RAID контроллер) обязательно дожидаясь подтверждения записи. Прямая синхронизация рекомендуется для ВМ, которые не отправляют запросы на сброс при их необходимости. Это наиболее безопасный кэш, так как данные не будут утрачены при отказе питания, однако он также и самый медленный;
  • Write back (отложенная запись) — хост выполняет и кэширование чтения, и кэширование записи. Подтверждение на запись диском ВМ выполняется как только данные зафиксированы в кэше хоста вне зависимости от того были они зафиксированы в хранилище или нет. Самый быстрый тип хеширования, но при потере питания пропадают все данные;
  • Write back (не безопасно) (ненадежная отложенная запись) — аналогично отложенной записи за исключением того, что все сбросы данных полностью игнорируются со стороны гостевой ВМ. Это самый быстрый и небезопасный тип кэширования. Он не должен применяться в промышленных кластерах. Обычно этот кэш используется для ускорения установки ОС в ВМ. После установки ОС этот кэш должен быть отключен и возвращен в другую более безопасную опцию.

Глава 38. Создание и настройка контейнера LXC

38.1. Создание контейнера в графическом интерфейсе

Перед созданием контейнера можно загрузить шаблоны LXC в хранилище. Это удобно делать в веб-интерфейсе (см. Управление ISO образами и шаблонами LXC).
Для создания контейнера необходимо нажать кнопку Создать СТ (Create СТ), расположенную в правом верхнем углу веб-интерфейса PVE:
Кнопка Создать СТ
Это запустит диалог Создать: Контейнер LXC, который предоставляет графический интерфейс для настройки контейнера.
На первой вкладке Общее необходимо указать:
  • Узел (Node) — узел назначения для данного контейнера;
  • CT ID — идентификатор контейнера в численном выражении;
  • Имя хоста (Hostname) — алфавитно-цифровая строка названия контейнера;
  • Непривилегированный контейнер — определяет, как будут запускаться процессы контейнера (если процессам внутри контейнера не нужны полномочия администратора, то необходимо снять отметку с этого пункта);
  • Пул ресурсов (Resource pool) — имя пула данного контейнера, к которому он будет относиться. Данное значение не обязательное. Чтобы иметь возможность выбора этот пул должен быть предварительно создан;
  • Пароль (Password) — пароль для данного контейнера;
  • Открытый SSH ключ (SSH public key) — ssh ключ.
Вкладка Общее диалога создания контейнера
На вкладке Шаблон (Template) настраиваются:
  • Хранилище (Storage) — хранилище в котором хранятся шаблоны LXC
  • Шаблон (Template) — шаблон контейнера.
Вкладка Шаблон диалога создания контейнера
На вкладке Корневой диск (Root Disk) определяется хранилище, где будут храниться диски контейнера. Здесь также можно определить размер виртуального диска (не следует выбирать размер диска менее 4 ГБ):
Вкладка Корневой диск диалога создания контейнера
На вкладке Процессор (CPU) определяется количество ядер процессора, которые будут выделены контейнеру:
Вкладка Процессор диалога создания контейнера
На вкладке Память (Memory) настраиваются:
  • Память (Memory) (MiB) — выделяемая память в мегабайтах;
  • Подкачка (Swap) (MiB) — выделяемое пространство подкачки в мегабайтах.
Вкладка Память диалога создания контейнера
Вкладка Сеть (Network) включает следующие настройки:
  • Имя (Name) — определяет, как будет именоваться виртуальный сетевой интерфейс внутри контейнера; значение по умолчанию eth0;
  • Адрес MAC (MAC address) — по умолчанию, все MAC адреса для виртуальных сетевых интерфейсов назначаются автоматически. Можно задать определенный MAC адрес необходимый для приложения в данном контейнере;
  • Сетевой мост (Bridge) — выбор виртуального моста, к которому будет подключаться данный интерфейс; значение по умолчанию установлено в vmbr0;
  • Тег VLAN (VLAN Tag) — применяется для установки идентификатора VLAN для данного виртуального интерфейса;
  • Ограничение трафика (Rate limit) (MBit/s) — ограничение пропускной способности сетевой среды (в Мб/с). Для работы без ограничений следует оставить поле пустым;
  • Брандмауэр (Firewall) — поддержка межсетевого экрана (если пункт отмечен, применяются правила хоста);
  • IPv4/IPv6 — можно настроить и IPv4, и IPv6 для виртуального сетевого интерфейса. IP адреса можно устанавливать вручную или разрешить получать от DHCP-сервера для автоматического назначения IP. IP должен вводиться в соответствии с CIDR (например, 192.168.0.0/24).
Вкладка Сеть диалога создания контейнера
Вкладка DNS содержит настройки:
  • Домен DNS (DNS domain) — имя домена (по умолчанию используются параметры хост системы);
  • Серверы DNS (DNS server) — IP адреса серверов DNS (доступно только при введенном имени домена).
Вкладка DNS диалога создания контейнера
Во вкладке Подтверждение (Confirm) отображаются все введенные или выбранные значения для данного контейнера:
Вкладка Подтверждение диалога создания контейнера
Для создания контейнера следует нажать кнопку Далее (Finish). Если необходимо внести изменения в параметры контейнера, можно перейти по вкладкам назад.
Если отметить пункт Start after created контейнер будет запущен сразу после создания.
После нажатия кнопки Далее во вкладке Подтверждение, диалог настройки закрывается и в браузере открывается новое окно, которое предлагает возможность наблюдать за построением PVE контейнера LXC из шаблона:
Создание контейнера

38.2. Создание контейнера из шаблона в командной строке

Контейнер также может быть создан из шаблона при помощи командной строки хоста PVE с использованием команды pct.
Следующий сценарий bash иллюстрирует применение такой команды для создания контейнера:
#!/bin/bash
#### Set Variables ####
$hostname="pve01"
$vmid="100"
$template-path="/var/lib/vz/template/cache"
$storage="local"
$description="alt-p9"
$template="alt-p9-rootfs-systemd-x86_64.tar.xz"
$ip="192.168.0.186/24"
$nameserver="8.8.8.8"
$ram="1024"
$rootpw="changeme"
$rootfs="4"
$gateway="192.168.0.1"
$bridge="vmbr0"
$if="eth0"
#### Execute pct create using variable substitution ####
pct create $vmid \
  $template-path/$template \
  -description $description \
  -rootfs $rootfs \
  -hostname $hostname \
  -memory $ram \
  -nameserver $nameserver \
  -storage $storage \
  -password $rootpw \
  -net0 name=$if,ip=$ip,gw=$gateway,bridge=$bridge

38.3. Изменение настроек контейнера

Изменения в настройки контейнера можно вносить и после его создания. При этом изменения сразу же вступают в действие, без необходимости перезагрузки контейнера.
Есть три способа, которыми можно регулировать выделяемые контейнеру ресурсы:
  • веб-интерфейс PVE;
  • командная строка;
  • изменение файла настройки

38.3.1. Изменение настроек в веб-интерфейсе

В большинстве случаев изменения настройки контейнера и добавление виртуальных устройств может быть выполнено в веб-интерфейсе.
Для изменения ресурсов контейнера можно использовать три вкладки:
  • Ресурсы (оперативная память, подкачка, количество ядер ЦПУ, размер диска);
  • Сеть;
  • DNS.
Изменений настроек контейнера в веб-интерфейсе PVE
Для редактирования ресурсов или добавления устройств, следует выполнить следующие действия:
  1. В режиме просмотра по серверам выбрать необходимый контейнер;
  2. Перейти на вкладку Ресурсы (Resource);
  3. Выбрать элемент для изменения: Память (Memory), Подкачка (Swap), Ядра (CPU units) или Корневой диск (Root Disk), и нажать кнопку Редактировать (Edit);
  4. В открывшемся диалоговом окне ввести нужные значения и нажать кнопку OK.
Если, например, необходимо увеличить размер диска контейнера до 18 ГБ вместо предварительно созданного 8 ГБ, нужно нажать кнопку Изменить размер диска (Resize disk) и в открывшемся диалоговом окне и ввести значение увеличения размера диска:
Изменение размера диска
Для изменения сетевых настроек контейнера необходимо:
  1. В режиме просмотра по серверам выбрать необходимый контейнер;
  2. Перейти на вкладку Сеть (Network) для выбранного в левой панели навигации контейнера. На экране отобразятся все настроенные для контейнера виртуальные сетевые интерфейсы:
    Виртуальные сетевые интерфейсы контейнера
  3. Выбрать нужный интерфейс, и нажать кнопку Редактировать (Edit) для внесения изменений;
  4. После выполнения необходимых изменений нажать кнопку OK для принятия введенных значений:
    Изменение сетевых настроек контейнера

38.3.2. Настройка ресурсов в командной строке

Если веб-интерфейс PVE недоступен, можно управлять контейнером при помощи командной строки (либо через сеанс SSH, либо из консоли noVNC, или зарегистрировавшись на физическом хосте).
pct — утилита управления контейнерами LXC в PVE. Чтобы просмотреть доступные для контейнеров команды PVE, можно выполнить следующую команду:
# pct help
Выполняемое командой pct изменение ресурсов фиксируется в контейнере немедленно, без необходимости перезапуска этого контейнера. Формат использования команды для изменения ресурсов контейнера:
 pct set <ct_id> [options]
Например, если необходимо изменить адрес IP контейнера #101, команда должна быть такой:
# pct set 101 –net0 name=eth0,bridge=vmbr0,ip=192.168.0.17/24,gw=192.168.0.1
Чтобы изменить выделение памяти контейнеру в реальном масштабе времени можно использовать следующую команду:
pct set <ct_id> -memory <int_value>
Следующая команда изменяет имя хоста данного контейнера:
pct set <ct_id> -hostname <string>
Команда увеличения размера диска данного контейнера:
pct set <ct_id> -rootfs size=<int_value for GB>
Состоянием контейнера также можно управлять из командной строки PVE.
Разблокировка заблокированного контейнера в командной строке:
pct set <ct_id> -unlock
Список контейнеров LXC данного узла:
# pct list
VMID       Status     Lock         Name
102        stopped                 LXC2
Запуск и останов контейнера LXC из командной строки:
pct start <ct_id>
pct stop <ct_id>

38.3.3. Настройка ресурсов прямым изменением

В PVE файлы конфигурации контейнеров находятся в каталоге /etc/pve/lxc, а файлы конфигураций ВМ — в /etc/pve/qemu-server/.

Примечание

Выполнять редактирование файла настройки контейнера LXC не рекомендуется, несмотря на то, что это возможно.
Любые выполненные вручную изменения в файлах не применяются, пока контейнер не будет перезапущен. Однако существуют ситуации, при которых изменение настроек вручную необходимо. Контейнеры LXC имеют большое число параметров, которые не могут быть изменены в веб-интерфейсе или с помощью утилиты pct. Такие параметры могут быть применены только путем изменения в файлах настройки с последующим перезапуском таких контейнеров.
Пример файла настройки /etc/pve/lxc/102.conf:
arch: amd64
cores: 1
hostname: LXC2
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.0.1,hwaddr=32:EF:01:1A:5C:7F,ip=192.168.0.91/24,ip6=dhcp,type=veth
ostype: altlinux
rootfs: local:102/vm-102-disk-0.raw,size=8G
swap: 512

38.4. Запуск и останов контейнеров

38.4.1. Изменение состояния контейнера в веб-интерфейсе

Для запуска контейнера следует выбрать его в левой панели; его иконка должна быть серого цвета, обозначая, что контейнер не запущен.
Запустить контейнер можно выбрав в контекстном меню контейнера пункт Запуск:
Контекстное меню контейнера
либо нажав на кнопку Запуск (Start):
Кнопки управления состоянием контейнера
Запущенный контейнер будет обозначен зеленой стрелкой на значке контейнера.
Для запущенного контейнера доступны следующие действия:
  • Выключить (Shutdown) — остановка контейнера;
  • Остановка (Stop) — остановка контейнера, путем прерывания его работы;
  • Перезапустить (Reboot) — перезапуск контейнера.

38.4.2. Изменение состояния контейнера в командной строке

Состоянием контейнера можно управлять из командной строки PVE (либо через сеанс SSH, либо из консоли noVNC, или зарегистрировавшись на физическом хосте).
Для запуска контейнера с VM ID 102 необходимо ввести команду:
# pct start 102
Этот же контейнер может быть остановлен при помощи команды:
# pct stop 102

38.5. Доступ к LXC контейнеру

Есть несколько вариантов при помощи, которых, может быть осуществлен доступ к LXC контейнеру:
  • консоль: noVNC, SPICE или xterm.js;
  • SSH;
  • интерфейс командной строки PVE.
Можно получить доступ к контейнеру из веб-интерфейса при помощи консоли noVNC. Это почти визуализированный удаленный доступ к экземпляру.
Для доступа к запущенному контейнеру в консоли следует выбрать в веб-интерфейсе нужный контейнер, а затем нажать кнопку Консоль (Console) и в выпадающем меню выбрать нужную консоль:
Кнопка Консоль
Консоль также можно запустить, выбрав вкладку Консоль (Console) для контейнера:
Консоль
Одной из функций LXC контейнера является возможность прямого доступа к оболочке контейнера через командную строку его узла хоста. Команда для доступа к оболочке контейнера LXC:
pct enter <ct_id>
Данная команда предоставляет прямой доступ на ввод команд внутри указанного контейнера:
[root@pve01 ~]# pct enter 107
[root@LXC2 ~]#
Таким образом был получен доступ к контейнеру LXС с именем newLXC на узле pve01. При этом для входа в контейнер не был запрошен пароль. Так как контейнер работает под пользователем root, можно выполнять внутри этого контейнера любые задачи. Завершив их, можно просто набрать exit для возвращения назад в свой узел из данного контейнера.

Предупреждение

При возникновении ошибки:
Insecure $ENV{ENV} while running with...
необходимо закомментировать строку:
"ENV=$HOME/.bashrc"
в файле /root/.bashrc.
Также можно выполнять внутри контейнера различные команды без реального входа в такой контейнер. Следующий формат команды применяется для выполнения команд внутри некоего контейнера:
pct exec <ct_id> -- <command>
Например, если нужно создать каталог внутри контейнера и проверить что этот каталог был создан, команды и их вывод будут следующими:
# pct exec 107 mkdir /home/demouser
# pct exec 107 ls /home
demouser
Для выполнения внутри контейнера команды с параметрами необходимо изменить команду pct, добавив -- после идентификатора контейнера:
# pct exec 107 -- df –H /
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       19G  402M   18G   3% /
none            504k     0  504k   0% /dev
udevfs          5.3M     0  5.3M   0% /dev/tty
tmpfs           1.1G     0  1.1G   0% /dev/shm
tmpfs           1.1G   82k  1.1G   1% /run
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           1.1G     0  1.1G   0% /sys/fs/cgroup
tmpfs           1.1G     0  1.1G   0% /tmp

Глава 39. Миграция ВМ и контейнеров

В случае, когда PVE управляет не одним физическим узлом, а кластером физических узлов, должна обеспечиваться возможность миграции ВМ с одного физического узла на другой. Миграция представляет собой заморозку состояния ВМ на одном узле, перенос данных и конфигурации на другой узел, и разморозку состояния ВМ на новом месте. Возможные сценарии, при которых может возникнуть необходимость миграции:
  • отказ физического узла;
  • необходимость перезагрузки узла после применения обновлений или обслуживания технических средств;
  • перемещение ВМ с узла с низкой производительностью на высокопроизводительный узел.
Есть два механизма миграции:
  • онлайн-миграция (Live Migration);
  • автономная миграция.

Примечание

Миграция контейнеров без перезапуска в настоящее время не поддерживается.
При выполнении миграции запущенного контейнера, контейнер будет выключен, перемещен, а затем снова запущен на целевом узле. Поскольку контейнеры очень легкие, это обычно приводит к простою в несколько сотен миллисекунд.
Для возможности Live Migration необходимы следующие условия:
  • ВМ не имеет локальных ресурсов;
  • хосты находятся в одном кластере PVE;
  • хосты имеют работающее (и надежное) сетевое соединение;
  • целевой хост должен иметь одинаковые или более высокие версии пакетов PVE.
Миграция в реальном времени обеспечивает максимальное время работы, но, в то же время медленнее. Причина в том, что при миграции в реальном времени без выключения питания процесс должен скопировать все содержимое оперативной памяти ВМ на новый узел. Чем больше объем выделенной ВМ памяти, тем дольше будет происходить ее перенос.
Если образ виртуального диска ВМ хранится в локальном хранилище узла PVE миграция в реальном времени не возможна. В этом случае ВМ должна быть выключена перед миграцией. В процессе миграции ВМ, хранящейся локально, PVE будет копировать весь виртуальный диск на узел получателя с применением rsync.
Запустить процесс миграции можно как в графическом интерфейсе PVE, так в интерфейсе командной строки.

39.1. Миграция с применением графического интерфейса

Для миграции ВМ или контейнера необходимо выполнить следующие шаги:
  1. Выбрать ВМ или контейнер для миграции и нажать кнопку Миграция (Migrate):
    Выбор ВМ или контейнера для миграции
  2. В открывшемся диалоговом окне выбрать узел назначения, на который будет осуществляться миграция, и нажать кнопку Миграция (Migrate) для запуска процесса миграции.

    Примечание

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

39.2. Миграция с применением командной строки

Чтобы осуществить миграцию ВМ необходимо выполнить следующую команду:
qm migrate <vmid> <target> [OPTIONS]
Для осуществления миграции ВМ в реальном времени необходимо использовать параметр --online.
Чтобы осуществить миграцию контейнера необходимо выполнить следующую команду:
pct migrate <ctid> <target> [OPTIONS]
Поскольку миграция контейнеров в реальном времени не возможна, можно выполнить миграцию работающего контейнера с перезапуском, добавив параметр --restart. Например:
# pct migrate 101 pve02 --restart

39.3. Миграция ВМ из внешнего гипервизора

Экспорт ВМ из внешнего гипервизора обычно заключается в переносе одного или нескольких образов дисков с файлом конфигурации, описывающим настройки ВМ (ОЗУ, количество ядер). Образы дисков могут быть в формате vmdk (VMware или VirtualBox), или qcow2 (KVM).

39.3.1. Миграция KVM ВМ в PVE

В данном разделе рассмотрен процесс миграции ВМ из OpenNebula в PVE.
Выключить ВМ на хосте источнике. Найти путь до образа жесткого диска, который используется в ВМ (в данной команде 14 — id образа диска ВМ):
$ oneimage show 14
IMAGE 14 INFORMATION
ID             : 14
NAME           : ALT Linux p9
USER           : oneadmin
GROUP          : oneadmin
LOCK           : None
DATASTORE      : default
TYPE           : OS
REGISTER TIME  : 04/30 11:00:42
PERSISTENT     : Yes
SOURCE         : /var/lib/one//datastores/1/f811a893808a9d8f5bf1c029b3c7e905
FSTYPE         : save_as
SIZE           : 12G
STATE          : used
RUNNING_VMS    : 1

PERMISSIONS
OWNER          : um-
GROUP          : ---
OTHER          : ---

IMAGE TEMPLATE
DEV_PREFIX="vd"
DRIVER="qcow2"
SAVED_DISK_ID="0"
SAVED_IMAGE_ID="7"
SAVED_VM_ID="46"
SAVE_AS_HOT="YES"
где /var/lib/one//datastores/1/f811a893808a9d8f5bf1c029b3c7e905 — адрес образа жёсткого диска ВМ.
Скопировать данный образ на хост назначения с PVE.

Примечание

В OpenNebula любой диск ВМ можно экспортировать в новый образ (если ВМ находится в состояниях RUNNING, POWEROFF или SUSPENDED):
onevm disk-saveas <vmid> <diskid> <img_name>  [--type type --snapshot snapshot]
где --type <type> — тип нового образа (по умолчанию raw); --snapshot <snapshot_id> — снимок диска, который будет использован в качестве источника нового образа (по умолчанию текущее состояние диска).
Экспорт диска ВМ:
$ onevm disk-saveas 125 0 test.qcow2
Image ID: 44
Информация об образе диска ВМ:
$ oneimage show 44
MAGE 44 INFORMATION
ID             : 44
NAME           : test.qcow2
USER           : oneadmin
GROUP          : oneadmin
LOCK           : None
DATASTORE      : default
TYPE           : OS
REGISTER TIME  : 07/12 21:34:42
PERSISTENT     : No
SOURCE         : /var/lib/one//datastores/1/9d6336a88d6ab62ea1dce65d81e55881
FSTYPE         : save_as
SIZE           : 12G
STATE          : rdy
RUNNING_VMS    : 0

PERMISSIONS
OWNER          : um-
GROUP          : ---
OTHER          : ---

IMAGE TEMPLATE
DEV_PREFIX="vd"
DRIVER="qcow2"
SAVED_DISK_ID="0"
SAVED_IMAGE_ID="14"
SAVED_VM_ID="125"
SAVE_AS_HOT="YES"

VIRTUAL MACHINES
Информация о диске:
$ qemu-img info /var/lib/one//datastores/1/9d6336a88d6ab62ea1dce65d81e55881
image: /var/lib/one//datastores/1/9d6336a88d6ab62ea1dce65d81e55881
file format: qcow2
virtual size: 12 GiB (12884901888 bytes)
disk size: 3.52 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
На хосте нахзначения подключить образ диска к ВМ (рассмотрено подключение на основе Directory Storage):
  • Создать новую ВМ в веб-интерфейсе PVE или командой:
    # qm create 120 --bootdisk scsi0 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci
    
  • Чтобы использовать в PVE образ диска в формате qcow2 (полученный из другой системы KVM, либо преобразованный из другого формата), его необходимо импортировать. Команда импорта:
    qm importdisk <vmid> <source> <storage> [OPTIONS]
    
    Импорт диска f811a893808a9d8f5bf1c029b3c7e905 в хранилище local, для ВМ с ID 120 (подразумевается, что образ импортируемого диска находится в каталоге, из которого происходит выполнение команды):
    # qm importdisk 120 f811a893808a9d8f5bf1c029b3c7e905 local --format qcow2
    importing disk 'f811a893808a9d8f5bf1c029b3c7e905' to VM 120 ...
    …
    Successfully imported disk as 'unused0:local:120/vm-120-disk-0.qcow2'
    
  • Привязать диск к ВМ.
    В веб-интерфейсе PVE: перейти на вкладку Оборудование, созданной ВМ. В списке устройств будет показан неиспользуемый жесткий диск, выбрать его, выбрать режим SCSI и нажать кнопку Добавить:
    Добавление диска к ВМ
    В командной строке:
    # qm set 120 --scsi0 local:120/vm-120-disk-0.qcow2
    update VM 120: -scsi0 local:120/vm-120-disk-0.qcow2
    
Донастроить параметры процессора, памяти, сетевых интерфейсов, порядок загрузки. Включить ВМ.

39.3.2. Миграция ВМ из VMware в PVE

В данном разделе рассмотрена миграция ВМ из VMware в PVE, на примере ВМ с Windows 7.
Подготовить ОС Windows. ОС Windows должна загружаться с дисков в режиме IDE.
Подготовить образ диска. Необходимо преобразовать образ диска в тип single growable virtual disk. Сделать это можно с помощью утилиты vmware-vdiskmanager (поставляется в комплекте с VMWare Workstation). Для преобразования образа перейти в папку с образами дисков и выполнить команду:
"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager"
-r win7.vmdk -t 0 win7-pve.vmdk
где win7.vmdk — файл с образом диска.
На хосте назначения подключить образ диска к ВМ одним из трёх указанных способов:
  1. Подключение образа диска к ВМ на основе Directory Storage:
    • В веб-интерфейсе PVE создать новую ВМ KVM;
    • Скопировать преобразованный образ win7-pve.vmdk в каталог с образами ВМ /var/lib/vz/images/VMID, где VMID — VMID, созданной виртуальной машины (можно воспользоваться WinSCP);
    • Преобразовать файл win7-pve.vmdk в qemu формат:
      # qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2
      
    • Добавить в конфигурационный файл ВМ (/etc/pve/nodes/pve02/qemu-server/VMID.conf) строку:
      unused0: local:100/win7-pve.qcow2
      
      где 100 — VMID, а local — хранилище в PVE.
    • Перейти в веб-интерфейсе PVE на вкладку Оборудование, созданной ВМ. В списке устройств будет показан неиспользуемый жесткий диск, выбрать его, выбрать режим IDE и нажать кнопку Добавить:
      Добавление диска к ВМ
  2. Подключение образа диска к ВМ на основе LVM Storage:
    • В веб-интерфейсе PVE создать новую ВМ с диском большего размера, чем диск в образе vmdk. Посмотреть размер диска в образе можно командой:
      # qemu-img info win7-pve.vmdk
      image: win7-pve.vmdk
      file format: vmdk
      virtual size: 127G (136365211648 bytes)
      disk size: 20.7 GiB
      cluster_size: 65536
      Format specific information:
          cid: 3274246794
          parent cid: 4294967295
          create type: streamOptimized
          extents:
              [0]:
                  compressed: true
                  virtual size: 136365211648
                  filename: win7-pve.vmdk
                  cluster size: 65536
                  format:
      
      В данном случае необходимо создать диск в режиме IDE размером не меньше 127GB.
    • Скопировать преобразованный образ win7-pve.vmdk в каталог с образами ВМ /var/lib/vz/images/VMID, где VMID — VMID, созданной виртуальной машины (можно воспользоваться WinSCP);
    • Перейти в консоль ноды кластера и посмотреть, как называется LVM диск созданной ВМ (он должен быть в статусе ACTIVE):
      # lvscan
        ACTIVE            '/dev/sharedsv/vm-101-disk-1' [130,00 GiB] inherit
      
    • Сконвертировать образ vdmk в raw формат непосредственно на LVM-устройство:
      # qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/sharedsv/vm-101-disk-1
      
  3. Подключение образа диска к ВМ на основе CEPH Storage:
    • В веб-интерфейсе PVE создать новую ВМ с диском большего размера, чем диск в образе vmdk. Посмотреть размер диска в образе можно командой:
      # qemu-img info win7-pve.vmdk
      
    • Скопировать преобразованный образ win7-pve.vmdk в каталог с образами ВМ /var/lib/vz/images/VMID, где VMID — VMID, созданной виртуальной машины;
    • Перейти в консоль ноды кластера. Отобразить образ из пула CEPH в локальное блочное устройство:
      # rbd map rbd01/vm-100-disk-1
      /dev/rbd0
      

      Примечание

      Имя нужного пула можно посмотреть на вкладке ДатацентрХранилищеrbd-storage.
    • Сконвертировать образ vdmk в raw формат непосредственно на отображенное устройство:
      # qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/rbd0
      
Адаптация новой ВМ:
  1. Проверить режим работы жесткого диска: для Windows — IDE, для Linux — SCSI.
  2. Режим VIRTIO жесткого диска (режим VIRTIO также доступен для Windows, но сразу загрузиться в этом режиме система не может):
    • загрузиться сначала в режиме IDE и выключить машину, добавить еще один диск в режиме VIRTIO и включить машину. Windows установит нужные драйвера;
    • выключить машину;
    • изменить режим основного диска с IDE на VIRTIO;
    • загрузить систему, которая должна применить VIRTIO драйвер и выдать сообщение, что драйвер от RedHat.
  3. Включить ВМ. Первое включение займет какое-то время (будут загружены необходимые драйвера).

Глава 40. Клонирование ВМ

Простой способ развернуть множество ВМ одного типа — скопировать (создать клон) ВМ.
Существует два вида клонов:
  • Полный клон — результатом такой копии является независимая ВМ. Новая ВМ не разделяет ресурсы хранения с оригинальными. При таком клонировании можно выбрать целевое хранилище, поэтому его можно использовать для переноса ВМ в совершенно другое хранилище. Также можно изменить формат образа диска, если драйвер хранилища поддерживает несколько форматов.
  • Связанный клон — такой клон является записываемой копией, исходное содержимое которой совпадает с исходными данными. Создание связанного клона происходит практически мгновенно и изначально не требует дополнительного места. Клоны называются связанными, потому что новое изображение ссылается на оригинал. Немодифицированные блоки данных считываются из исходного изображения, но изменения записываются (и затем считываются) из нового местоположения. При этом требуется, чтобы исходный том работал в режиме только для чтения. С помощью PVE можно преобразовать любую ВМ в шаблон. Такие шаблоны впоследствии могут быть использованы для эффективного создания связанных клонов. Для связанных клонов невозможно изменить целевое хранилище, поскольку это внутренняя функция хранилища.

Примечание

Полному клону необходимо прочитать и скопировать все данные образа ВМ. Это обычно намного медленнее, чем создание связанного клона.
Весь функционал клонирования доступен из графического интерфейса PVE.
Для клонирования ВМ необходимо выполнить следующие шаги:
  1. Создать ВМ с необходимыми настройками (все создаваемые из такой ВМ клоны будут иметь идентичные настройки) или воспользоваться уже существующей ВМ;
  2. В контекстном меню выбранной ВМ выбрать пункт Клонировать (Clone):
    Контекстное меню ВМ
  3. Откроется диалоговое окно, со следующими полями:
    • Целевой узел (Target node) — узел получатель клонируемой ВМ (для создания новой ВМ на другом узле необходимо чтобы ВМ находилась в общем хранилище и это хранилище должно быть доступно на целевом узле);
    • VM ID — идентификатор ВМ;
    • Имя (Name) — название ВМ;
    • Пул ресурсов (Resource Pool) — пул, к которому будет относиться ВМ;
    • Режим (Mode) — метод клонирования (если клонирование происходит из шаблона ВМ). Доступными параметрами являются Полное клонирование (Full Clone) и Связанная копия (Linked Clone);
    • Снимок (Snapshot) — снимок из которого будет создаваться клон (если снимки существуют). Если существует несколько снимков, доступных для данной ВМ, из них можно выбирать на основе выпадающего меню;
    • Целевое хранилище (Target Storage) — хранилище для клонируемых виртуальных дисков;
    • Формат (Format) — формат образа виртуального диска.
    Настройки клонирования
  4. Для запуска процесса клонирования необходимо нажать кнопку Клонировать.
Некоторые типы хранилищ позволяют копировать определенный снимок, который по умолчанию соответствует текущим данным ВМ. Клон ВМ никогда не содержит дополнительных снимков оригинальной ВМ.
Выбор снимка для клонирования
ВМ можно преобразовать в шаблон. Такие шаблоны доступны только для чтения, и их можно использовать для создания связанных клонов.
Для преобразования ВМ в шаблон необходимо в контекстном меню ВМ выбрать пункт Сохранить как шаблон (Convert to template) и в ответ на запрос на подтверждения, нажать кнопку Да.

Примечание

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

Глава 41. Резервное копирование (Backup)

PVE предоставляет полностью интегрированное решение, использующее возможности всех хранилищ и всех типов гостевых систем.
Резервные копии PVE представляют собой полные резервные копии — они содержат конфигурацию ВМ/CT и все данные. Резервное копирование может быть запущено через графический интерфейс или с помощью утилиты командной строки vzdump.

41.1. Алгоритмы резервного копирования

Инструментарий для создания резервных копий PVE поддерживает следующие механизмы сжатия:
  • Сжатие LZO — алгоритм сжатия данных без потерь (реализуется в PVE утилитой lzop). Основной особенностью этого алгоритма является скоростная распаковка. Следовательно, любая резервная копия, созданная с помощью этого алгоритма, может при необходимости быть развернута за минимальное время.
  • Сжатие GZIP — при использовании этого алгоритма резервная копия будет «на лету» сжиматься утилитой GNU Zip, использующей мощный алгоритм Deflate. Основной упор делается на максимальное сжатие данных, что позволяет сократить место на диске, занимаемое резервными копиями. Главным отличием от LZO является то, что процедуры компрессии/декомпрессии занимают достаточно большое количество времени.
  • Сжатие Zstandard (zstd) — алгоритм сжатия данных без потерь. В настоящее время Zstandard является самым быстрым из этих трех алгоритмов. Многопоточность — еще одно преимущество zstd перед lzo и gzip.

41.2. Режимы резервного копирования

Режимы резервного копирования для виртуальных машин:
  • режим остановки (Stop) — обеспечивает самую высокую надежность резервного копирования, но требует полного выключения ВМ. В этом режиме ВМ отправляется команда на штатное выключение, после остановки выполняется резервное копирование и затем отдается команда на включение ВМ. Количество ошибок при таком подходе минимально и чаще всего сводится к нулю;
  • режим приостановки (Suspend) — ВМ временно «замораживает» свое состояние, до окончания процесса резервного копирования. Содержимое оперативной памяти не стирается, что позволяет продолжить работу ровно с той точки, на которой работа была приостановлена. Сервер простаивает во время копирования информации, но при этом нет необходимости выключения/включения ВМ, что достаточно критично для некоторых сервисов. Особенно, если запуск части сервисов не является автоматическим. Такие резервные копии следует разворачивать в тестовой среде для проверки;
  • режим снимка (Snapshot) — использование этого механизма не прерывает работу ВМ (Live backup), но имеет два очень серьезных недостатка — могут возникать проблемы из-за блокировок файлов операционной системой и самая низкая скорость создания. Резервные копии, созданные этим методом, надо всегда проверять в тестовой среде.
Режимы резервного копирования для контейнеров:
  • режим остановки (Stop) — остановка контейнера на время резервного копирования. Это может привести к длительному простою;
  • режим приостановки (Suspend) — этот режим использует rsync для копирования данных контейнера во временную папку (опция --tmpdir). Затем контейнер приостанавливается и rsync копирует измененные файлы. После этого контейнер возобновляет свою работу. Это приводит к минимальному времени простоя, но требует дополнительное пространство для хранения копии контейнера. Когда контейнер находится в локальной файловой системе и хранилищем резервной копии является сервер NFS, необходимо установить --tmpdir также и в локальной файловой системе, так как это приведет к повышению производительности. Использование локального tmpdir также необходимо, если требуется сделать резервную копию локального контейнера с использованием списков контроля доступа (ACL) в режиме ожидания, если хранилище резервных копий — сервер NFS;
  • режим снимка (Snapshot) — этот режим использует возможности мгновенных снимков основного хранилища. Сначала, контейнер будет приостановлен для обеспечения согласованности данных, будет сделан временный снимок томов контейнера, а содержимое снимка будет заархивировано в tar-файле, далее временный снимок удаляется.

41.3. Резервное хранилище

Перед тем, как настроить резервное копирование, необходимо определить хранилище резервных копий. Хранилище резервных копий должно быть хранилищем уровня файлов, так как резервные копии хранятся в виде обычных файлов. В большинстве случаев можно использовать сервер NFS для хранения резервных копий.
Если хранилище будет использоваться только для резервных копий, следует выставить соответствующие настройки:
Настройка хранилища NFS
На вкладке Backup Retention можно указать параметры хранения резервных копий:
Параметры хранения резервных копий (prune-backups) в хранилище NFS
Доступны следующие варианты хранения резервных копий (в скобках указаны параметры опции prune-backups команды vzdump):
  • Keep all backups (keep-all=<1|0>) — хранить все резервные копии (если отмечен этот пункт, другие параметры не могут быть установлены);
  • keep-last (keep-last=<N>) — хранить <N> последних резервных копий;
  • Keep Hourly (keep-hourly=<N>) — хранить резервные копии за последние <N> часов (если за один час создается более одной резервной копии, сохраняется только последняя);
  • Keep Daily (keep-daily=<N>) — хранить резервные копии за последние <N> дней (если за один день создается более одной резервной копии, сохраняется только самая последняя);
  • Keep Weekly (keep-weekly=<N>) — хранить резервные копии за последние <N> недель (если за одну неделю создается более одной резервной копии, сохраняется только самая последняя);
  • Keep Monthly (keep-monthly=<N>) — хранить резервные копии за последние <N> месяцев (если за один месяц создается более одной резервной копии, сохраняется только самая последняя);
  • Keep Yearly (keep-yearly=<N>) — хранить резервные копии за последние <N> лет (если за один год создается более одной резервной копии, сохраняется только самая последняя);
Варианты хранения обрабатываются в указанном выше порядке. Каждый вариант распространяется только на резервное копирование в определенный период времени.
Пример указания параметров хранения резервных копий при создании задания:
# vzdump 777 --prune-backups keep-last=3,keep-daily=13,keep-yearly=9
Хотя можно передавать параметры хранения резервных копий непосредственно в vzdump, часто более разумно настроить эти параметры на уровне хранилища.

41.4. Резервное копирование по расписанию

Задания резервного копирования можно запланировать так, чтобы они выполнялись автоматически в определенные дни и часы для конкретных узлов и гостевых систем. Конфигурирование заданий создания резервных копий выполняется на уровне центра обработки данных в веб-интерфейсе, который создает запись cron в /etc/cron.d/vzdump.

41.5. Настройка резервного копирования в графическом интерфейсе

Для того чтобы создать расписание резервного копирования, необходимо его настроить во вкладке Резервная копия (BackUP) датацентра:
Вкладка Резервная копия
При создании задания на резервирование, необходимо указать:
Создание задания для резервного копирования
  • Узел (Node) — можно создавать график из одного места по разным узлам (серверам);
  • Хранилище (Storage) — точка смонтированного накопителя, куда будет проходить копирование;
  • День недели (Day of Week) — здесь можно указать один или несколько определенных дней, в которые будет выполняться резервное копирование (несколько дней можно выбрать при помощи зажатой клавиши CTRL);
  • Время запуска (Start time) — время старта резервного копирования (указывается в формате 24);
  • Режим выбора (Selection mode) — принимает значения: Учитывать выбранные VM (Include), Все (All), Исключить выбранные VM (Exclude), Pool based;
  • Отправить письмо (Send email to) — адрес, на который будут приходить результаты резервного копирования;
  • Уведомление по почте (Email notification) — принимает два значения: Всегда (Always) — сообщение будет приходить при любом результате резервного копирования, Только при ошибках (On failure only) — сообщение будет приходить только в случае неудачной попытки резервного копирования;
  • Сжатие (Compression) — метод сжатия, принимает четыре значения: ZSTD (быстро и хорошо) (по умолчанию), LZO (быстро), GZIP (хорошо) и нет;
  • Режим (Mode) — режим ВМ, в котором будет выполняться резервное копирование. Может принимать три значения: Снимок, Приостановить, Остановка:
    Выбор режима создания резервной копии
После указания необходимых параметров и нажатия кнопки Создать, задание для резервного копирования появляется в списке:
Задание резервного копирования
Данное задание будет запускаться в назначенное время.
Также существует возможность запустить задание по требованию — кнопка Run now.
Для того чтобы разово создать резервную копию конкретной ВМ, достаточно открыть ВМ, выбрать в ней раздел Резервная копия (Backup) и нажать кнопку Создать резервную копию сейчас (Backup Now):
Вкладка Резервная копия ВМ
Далее следует указать параметры резервного копирования:
Выбор режима создания резервной копии
После создания резервной копии рекомендуется сразу убедиться, что из нее можно восстановить ВМ. Для этого необходимо открыть хранилище с резервной копией:
Резервная копия в хранилище nfs-backup
И начать процесс восстановления (при восстановлении можно указать новое имя для ВМ):
Восстановить ВМ из резервной копии
Если восстанавливать из резервной копии в интерфейсе ВМ, то будет предложена только замена существующей ВМ:
Восстановление из резервной копии в интерфейсе ВМ

41.6. Резервное копирование из командной строки

41.6.1. Файлы резервных копий

Все создаваемые резервные копии будут лежать в подкаталоге dump. Они будут иметь вид:
  • vzdump-qemu-номер_машины-дата-время.vma.zst при использовании метода ZST;
  • vzdump-qemu-номер_машины-дата-время.vma.gz при использовании метода GZIP;
  • vzdump-qemu-номер_машины-дата-время.vma.lzo при использовании метода LZO.
vzdump кодирует тип ВМ и время резервного копирования в имя файла, например:
vzdump-qemu-103-2021_07_02-15_32_31.vma.zst

41.6.2. Восстановление

Резервные копии могут быть восстановлены с помощью следующих утилит:
  • pct restore — утилита восстановления контейнера;
  • qmrestore — утилита восстановления QemuServer.

41.6.3. Ограничение пропускной способности

Для восстановления одной или нескольких больших резервных копий может потребоваться много ресурсов, особенно пропускной способности хранилища как для чтения из резервного хранилища, так и для записи в целевое хранилище. Это может негативно повлиять на другую ВМ, так как доступ к хранилищу может быть перегружен.
Чтобы избежать этого, можно установить ограничение полосы пропускания для задания резервного копирования. PVE реализует два вида ограничений для восстановления и архивирования:
  • per-restore limit — максимальный объем полосы пропускания для чтения из архива резервной копии;
  • предел записи для хранилища — обозначает максимальный объем полосы пропускания, используемый для записи в конкретное хранилище.
Ограничение чтения косвенно влияет на ограничение записи. Меньшее ограничение на задание перезапишет большее ограничение на хранилище. Больший лимит на каждое задание будет перезаписывать только лимит на хранилище, если есть разрешения «Data.Allocate» для уязвимого хранилища.

Примечание

Чтобы отключить все ограничения для конкретного задания восстановления можно использовать значение lim 0 для параметра bwlimit. Это может быть полезно, если требуется как можно быстрее восстановить ВМ.
Установить ограничение пропускной способности по умолчанию для настроенного хранилища, можно с помощью команды:
# pvesm set STORAGEID --bwlimit KIBs

41.6.4. Конфигурация

Глобальные настройки создания резервных копий хранятся в файле конфигурации /etc/vzdump.conf. Каждая строка файла имеет следующий формат (пустые строки в файле игнорируются, строки, начинающиеся с символа #, рассматриваются как комментарии и также игнорируются):
OPTION: value

Таблица 41.1. Параметры файла конфигурации

Опция
Описание
bwlimit: integer (0 — N) (default=0)
Ограничение пропускной способности ввода/вывода (Кб/с)
compress: (0|1|gzip|lzo|zstd) (default=0)
Сжатие файла резервной копии
dumpdir: string
Записать результирующие файлы в указанный каталог
exclude-path: string
Исключить определенные файлы/каталоги
ionice: integer (0 — 8) (default=7)
Установить CFQ приоритет ionice
lockwait: integer (0 — N) (default=180)
Максимальное время ожидания для глобальной блокировки (в минутах)
mailnotification: (always|failure) (default=always)
Указание, когда следует отправить отчет по электронной почте
mailto: string
Разделенный запятыми список адресов электронной почты, на которые будут приходить уведомления
maxfiles: integer (1 — N) (default=1)
Максимальное количество файлов резервных копий ВМ
mode: (snapshot|stop|suspend) (default=snapshot)
Режим резервного копирования
pigz: integer (default=0)
Использует pigz вместо gzip при N>0. N=1 использует половину ядер (uses half of cores), при N>1 N — количество потоков
prune-backups
Использовать эти параметры хранения вместо параметров из конфигурации хранилища (см.выше)
remove: boolean (default=1)
Удалить старые резервные копии, если их больше, чем установлено опцией maxfiles
script: string
Использовать указанный скрипт
stdexcludes: boolean (default=1)
Исключить временные файлы и файлы журналов
stopwait: integer (0 — N) (default=10)
УМаксимальное время ожидания пока ВМ не остановится (минуты)
storage: string
Хранить полученный файл в этом хранилище
tmpdir: string
Хранить временные файлы в указанном каталоге
zstd: integer (default = 1)
Количество потоков zstd. N = 0 использовать половину доступных ядер, N> 0 использовать N как количество потоков
Пример файла vzdump.conf:
tmpdir: /mnt/fast_local_disk
storage: my_backup_storage
mode: snapshot
bwlimit: 10000

41.6.5. Файлы, не включаемые в резервную копию

Примечание

Эта опция доступна только при создании резервных копий контейнеров.
vzdump пропускает следующие файлы по умолчанию (отключается с помощью опции --stdexcludes 0):
/tmp/?*
/var/tmp/?*
/var/run/?*pid
Кроме того, можно вручную указать какие файлы исключать (дополнительно), например:
# vzdump 777 --exclude-path /tmp/ --exclude-path '/var/foo*'
Файлы конфигурации также хранятся внутри архива резервных копий (в /etc/vzdump/) и будут корректно восстановлены.

41.6.6. Примеры

Простая резервная копия гостевой системы 103 — без снимка, только архив гостевой части и конфигурационного файла в каталог резервного копирования по умолчанию (обычно /var/lib/vz/dump/):
# vzdump 103
Использовать rsync и режим приостановки для создания снимка (минимальное время простоя):
# vzdump 103 --mode suspend
Сделать резервную копию всей гостевой системы и отправить отчет пользователю root и admin:
# vzdump --all --mode suspend --mailto root --mailto admin
Использовать режим мгновенного снимка (нет времени простоя) и каталог для хранения резервных копий /mnt/backup:
# vzdump 103 --dumpdir /mnt/backup --mode snapshot
Резервное копирование более чем одной ВМ (выборочно):
# vzdump 101 102 103 --mailto root
Резервное копирование всех ВМ, исключая 101 и 102:
# vzdump --mode suspend --exclude 101,102
Восстановить контейнер в новый контейнер 600:
# pct restore 600 /mnt/backup/vzdump-lxc-104.tar
Восстановить QemuServer VM в VM 601:
# qmrestore /mnt/backup/vzdump-qemu-105.vma 601
Клонировать существующий контейнер 101 в новый контейнер 300 с 4 ГБ корневой файловой системы, используя pip:
# vzdump 101 --stdout | pct restore --rootfs 4 300 - 

41.7. Снимки (snapshot)

Снимки ВМ — это файловые снимки состояния, данных диска и конфигурации ВМ в определенный момент времени. Можно создать несколько снимков ВМ даже во время ее работы. Затем можно возвратить ее в любое из предыдущих состояний, применив моментальный снимок к ВМ.
Чтобы создать снимок состояния системы в меню ВМ необходимо выбрать пункт Снимки (Snapshots) и затем нажать кнопку Сделать снимок:
Окно управления снимками ВМ
В открывшемся окне следует ввести название снимка (можно также ввести его описание) и нажать кнопку Сделать снимок:
Создание снимка ВМ
Для того чтобы восстановить ВМ из снимка, необходимо в меню ВМ выбрать пункт Снимки (Snapshots), выбрать снимок и нажать кнопку Откатить:
Восстановление ОС из снимка
При создании снимков, qm сохраняет конфигурацию ВМ во время снимка в отдельном разделе в файле конфигурации ВМ. Например, после создания снимка с именем first файл конфигурации будет выглядеть следующим образом:
boot: order=scsi0;scsi7;net0
cores: 1
memory: 1024
name: VMT
net0: virtio=96:53:8D:BF:FC:94,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
parent: first
scsi0: local:103/vm-103-disk-0.qcow2,size=32G
scsi7: nfs-storage:iso/alt-kworkstation-9.2-x86_64.iso,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=e53c7a24-6fc3-4f33-8173-d36f938d1c77
sockets: 1
vmgenid: ec8a0c17-8438-439d-9ee0-13be4497f8ed

[first]
#clear system
boot: order=scsi0;scsi7;net0
cores: 1
memory: 1024
name: VMT
net0: virtio=96:53:8D:BF:FC:94,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
runningcpu: kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep
runningmachine: pc-i440fx-5.1+pve0
scsi0: local:103/vm-103-disk-0.qcow2,size=32G
scsi7: nfs-storage:iso/alt-kworkstation-9.2-x86_64.iso,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=e53c7a24-6fc3-4f33-8173-d36f938d1c77
snaptime: 1625210352
sockets: 1
vmgenid: ec8a0c17-8438-439d-9ee0-13be4497f8ed
vmstate: local:103/vm-103-state-first.raw
Свойство parent используется для хранения родительских/дочерних отношений между снимками, snaptime — это отметка времени создания снимка (эпоха Unix).

Глава 42. Встроенный мониторинг PVE

Все данные о потреблении ресурсов и производительности можно найти на вкладках Сводка (Summary) узлов PVE и ВМ. Можно просматривать данные на основе почасового ежедневного, еженедельного или за год периодов.
Сводка (Summary) узла pve02 со списком для выбора периода данных:
Выбор периода данных, для отображения отчета
Просмотреть список всех узлов, ВМ и контейнеров в кластере можно, выбрав ДатацентрПоиск (DatacenterSearch). Этот список может быть отсортирован по полям: Тип (Type), Описание (Description), Использование диска % (Disk usage), Использование памяти (Memory usage), Загрузка CPU (CPU usage) и Время работы (Uptime). В этом списке отображается потребление ресурсов только в реальном масштабе времени.
Потребление ресурсов
Для мониторинга состояния локальных дисков используется пакет smartmontools. Он содержит набор инструментов для мониторинга и управления S.M.A.R.T. системой для локальных жестких дисков.
Получить статус диска можно, выполнив следующую команду:
# smartctl -a /dev/sdX
где /dev/sdX — это путь к одному из локальных дисков.
Включить поддержку SMART для диска, если она отключена:
# smartctl -s on /dev/sdX
Просмотреть S.M.A.R.T. статус диска в веб-интерфейсе можно, выбрав в разделе Диски нужный диск и нажав кнопку Показать данные S.M.A.R.T.:
Кнопка Показать данные S.M.A.R.T.
По умолчанию, smartmontools daemon smartd активен и включен, и сканирует диски в /dev/sdX и /dev/hdX каждые 30 минут на наличие ошибок и предупреждений, а также отправляет сообщение электронной почты пользователю root в случае обнаружения проблемы (для пользователя root в PVE должен быть введен действительный адрес электронной почты).
Электронное сообщение будет содержать имя узла, где возникла проблема, а также параметры самого устройства, такие как серийный номер и идентификатор дискового устройства. Если та же самая ошибка продолжит возникать, узел будет отсылать электронное сообщение каждые 24 часа. Основываясь на содержащейся в электронном сообщении информации можно определить отказавшее устройство и заменить его в случае такой необходимости.

Глава 43. Высокая доступность PVE

Высокая доступность является комбинацией компонентов и настроек, которые делают возможной непрерывную работу вычислительной среды на протяжении длительного времени. В основном это означает, что даже если находящееся в автоматическом режиме оборудование сервера испытывает проблемы в среде реального времени, высокая доступность (HA) может управлять оставшимися серверами самостоятельно и поддерживая виртуальную среду в рабочем состоянии автоматически перемещая или выполняя миграцию ВМ с одного узла на другой. Настроенная надлежащим образом HA требует очень незначительного реального вмешательства пользователей в случае отказа аппаратных средств. Без HA на своем месте, все узлы требуют постоянного мониторинга со стороны сетевых менеджеров чтобы вручную перемещать ВМ на жизнеспособные узлы, когда некоторые узлы испытывают проблемы.
В небольших средах перемещение вручную ВМ не является проблемой, однако в больших средах из сотен ВМ или узлов постоянный мониторинг может быть очень затратным в смысле времени. Несмотря на то, что в системе может существовать программное обеспечение мониторинга, без HA администратор будет должен вручную перемещать или выполнять миграцию любых ВМ с отказавшего узла. Это может повлечь за собой значительное время простоя. Это именно то место, где вступает в действие функциональность HA PVE. HA выводит вмешательство оператора за скобки решения, просто перемещая или выполняя миграцию ВМ как только возникает отказ оборудования сервера.
Для функционирования HA в PVE необходимо чтобы все ВМ были в общем хранилище. HA PVE обрабатывает только узлы PVE и ВМ в пределах кластера PVE. Такую функциональность HA не следует путать с избыточностью общих хранилищ, которую PVE может применять в своем развертывании HA. Высокая доступность в общем хранилище так же важна, как и высокая доступность ВМ PVE. Общие хранилища сторонних производителей могут предоставлять свою собственную функциональность HA. Таким образом, и сам кластер PVE, и общее хранилище должны быть настроены для предоставления реальной среды с высокой доступностью.
В вычислительном узле PVE могут существовать свои уровни избыточности, такие как применение RAID, дополнительные источники питания, агрегированные сетевые связи или сцепления (bond). HA в PVE не подменяет собой ни один из этих уровней. Он просто способствует использованию функций избыточности ВМ для сохранения их в рабочем состоянии при отказе какого-либо узла.
Перезагрузка узла PVE, вызванная необходимостью применения обновлений, вызовет выключение всех ВМ с включенной HA, перемещение их на следующий доступный узел PVE и их последующий повторный запуск. В подобной ситуации может оказаться необходимой миграция ВМ в реальном времени вручную до перезагрузки обновляемого узла.

43.1. Как работает высокая доступность PVE

Основной блок управления, управляемый ha-manager называется ресурсом. Ресурс (сервис) однозначно идентифицируется идентификатором сервиса (SID), который состоит из типа ресурса и идентификатора, специфичного для данного типа например, vm: 100. Этот пример ресурса типа vm (виртуальная машина) с идентификатором 100.
В случае, когда по какой-либо причине узел становится недоступным, HA PVE ожидает 60 секунд прежде чем выполнится ограждение (fencing) отказавшего узла. Ограждение предотвращает службы кластера от возврата в рабочее состояние в этом месте. Затем HA перемещает эти ВМ и контейнеры на следующий доступный узел в их группе участников HA. Даже если узел с ВМ все еще включен, но потерял связь с сетевой средой, HA PVE попытается переместить все ВМ с этого узла на другой узел.
При возврате отказавшего узла в рабочее состояние, HA не будет автоматически перемещать ВМ на первоначальный узел. Это необходимо выполнять вручную. При этом ВМ может быть перемещена вручную только если HA запрещен для такой ВМ. Поэтому сначала следует выключить HA, а затем переместить на первоначальный узел и включить HA на данной ВМ вновь.

43.2. Требования для настройки высокой доступности

Среда перед настройкой HA PVE должна отвечать следующим требованиям:
  • кластер не менее чем из трех узлов (для получения надежного кворума);
  • общее хранилище для ВМ и контейнеров;
  • аппаратное резервирование;
  • использование надежных «серверных» компонентов;
  • аппаратный сторожевой таймер (если он недоступен, используется программный таймер ядра Linux);
  • дополнительные устройства ограждения (fencing).

43.3. Настройка высокой доступности PVE

Все настройки HA PVE могут быть выполнены в веб-интерфейсе. Функциональность HA доступна при выборе ДатацентрHA (DatacenterHA). Это меню, в котором будут выполняться все связанные с HA настройки и управление:
Меню HA
В окне отображается статус настройки HA.

43.3.1. Создание группы

Подменю Группы применяется для создания различных групп PVE для HA и управления ими. Наиболее характерным использованием групп являются некие программные решения или инфраструктура ВМ, которые должны работать совместно. Например, контроллер домена, файловый сервер и тому подобное. Назначенные в определенную группу ВМ могут перемещаться только совместно с узлами участниками этой группы. Например, шесть узлов, три из которых обладают всей полнотой ресурсов достаточной для исполнения виртуального сервера базы данных, а другие три узла выполняют виртуальные рабочие столы или решения VDI. Можно создать две группы, для которых виртуальные серверы баз данных могут перемещаться только в пределах тех узлов, которые будут назначены для данной группы. Это гарантирует, что ВМ переместится на правильный узел, который будет способен исполнять такие ВМ.
Для включения HA для ВМ необходима как минимум одна группа.
Для создания группы необходимо в подменю Группы (Groups) нажать кнопку Создать (Create).
Элементы, доступные в блоке диалога HA Group:
  • ID — название HA Group;
  • Узел (Node) — назначение узлов в создаваемую группу. Чтобы создать конкретную группу, нужно выбрать, по крайней мере, один узел;
  • Restricted — разрешение перемещения ВМ со стороны HA PVE только в рамках узлов участников данной группы HA. Если перемещаться некуда, то эти ВМ будут автоматически остановлены;
  • Nofailback — используется для предотвращения автоматического восстановления состояния ВМ/контейнера при восстановлении узла в кластере (не рекомендуется включать эту опцию).
Диалог создания группы
Подменю Группы с созданной группой

43.3.2. Добавление ресурсов

Для включения HA для ВМ или контейнера следует нажать кнопку Добавить в разделе Ресурсы меню HA. В открывшемся диалоговом окне нужно выбрать ВМ и группу HA, к которой будет относиться данная ВМ:
Добавление ресурса в группу
В окне можно настроить следующие параметры:
  • Макс. перезапусков (Max. Restart) — количество попыток запуска ВМ/контейнера на новом узле после перемещения;
  • Макс. перемещений (Max. Relocate) — количество попыток перемещения ВМ/контейнера на новый узел;
  • Статус запроса (Request State) — доступны варианты: started — кластер менеджер будет пытаться поддерживать состояние машины в запущенном состоянии; stopped — при отказе узла перемещать ресурс, но не пытаться запустить; ignored — ресурс, который не надо перемещать при отказе узла; disabled — в этот статус переходят ВМ, которые находятся в состоянии «error».
Группа HA PVE и добавленные в нее ВМ и контейнеры, которыми будет управлять HA:
Список ресурсов
Раздел Статус (Status) отображает текущее состояние функциональности HA:
  • кворум кластера установлен;
  • главный узел pve01 группы HA активен и последний временной штамп жизнеспособности (heartbeat timestamp) проверен;
  • все узлы, участвующие в группе HA активны и последний временной штамп жизнеспособности (heartbeat timestamp) проверен.
Просмотреть состояние функциональности HA можно и в консоли:
# ha-manager status
quorum OK
master pve01 (active, Fri Jul  2 16:12:08 2021)
lrm pve01 (idle, Fri Jul  2 16:12:07 2021)
lrm pve02 (active, Fri Jul  2 16:12:05 2021)
lrm pve03 (idle, Fri Jul  2 16:12:08 2021)
service ct:105 (pve02, relocate)

43.4. Тестирование настройки высокой доступности PVE

Для того чтобы убедиться, что HA действительно работает можно отключить сетевое соединение для pve01 и понаблюдать за окном Статус на предмет изменений HA:
Список ресурсов
После того как соединение с узлом pve01 будет потеряно, он будет помечен как недоступный:
Нет соединения с pve01
По истечению 60 секунд, HA PVE предоставит следующий доступный в группе HA узел в качестве главного:
Изменение главного узла на pve03
После того, как HA PVE предоставит новый ведущий узел для данной группы HA, она затем запустит ограждение для ресурсов ВМ/контейнера для их подготовки к перемещению на другой узел. В процессе ограждения, все связанные с данной ВМ службы ограждаются, что означает, что даже если отказавший узел вернется в строй на этом этапе, его ВМ не будет иметь возможность восстановить свою нормальную работу.
После того, как ресурсы данной ВМ/контейнера ограждены, данная ВМ/контейнер полностью останавливается. Так как узел сам по себе отключен, ВМ/контейнер не может выполнить миграцию в реальном времени, поскольку состояние оперативной памяти исполняемой ВМ не может быть получено с отключенного узла.
После того, как отслеживаемая ВМ/контейнер остановлена, она перемещается на следующий свободный узел в группе HA и автоматически запускается.
Контейнер 107 перемещен на узел pve03 и запущен:
Контейнер 107 запущен на узле pve03
В случае возникновения любой ошибки, HA PVE выполнит несколько попыток в соответствии с политиками restart и relocate для восстановления. Если все попытки окажутся неудачными, HA PVE поместит ресурсы в ошибочное состояние и не будет выполнять для них никаких задач.

Глава 44. Пользователи и их права

Для аутентификации пользователей в веб-интерфейсе PVE можно использовать как собственные механизмы PVE, так и PAM:
Выбор типа аутентификации в веб-интерфейсе
Используя основанное на ролях управление пользователями и разрешениями для всех объектов (ВМ, хранилищ, узлов и т. д.), можно определить многоуровневый доступ.
Доступны следующие области (методы) аутентификации:
  • Стандартная аутентификация Linux PAM (Linux PAM standart authentication) — при использовании этой аутентификации системный пользователь должен существовать (должен быть создан например, с помощью команды adduser) на всех узлах, на которых пользователю разрешено войти в систему. Пользователь аутентифицируется с помощью своего обычного системного пароля;
  • Сервер аутентификации PVE (PVE authentication server) — это хранилище паролей в стиле Unix (/etc/pve/priv/shadow.cfg). Пароль шифруется с использованием метода хеширования SHA-256. Этот метод аутентификации удобен для небольших (или даже средних) установок, где пользователям не нужен доступ ни к чему, кроме PVE. В этом случае пользователи полностью управляются PVE и могут менять свои пароли через графический интерфейс;
    PVE хранит данные пользователей в файле /etc/pve/user.cfg:
    # cat /etc/pve/user.cfg
    user:root@pam:1:0::::::
    user:test@pve:1:0::::::
    user:testuser@pve:1:0::::Just a test::
    user:user@pam:1:0::::::
    
    group:admin:user@pam::
    group:testgroup:test@pve::
    
  • LDAP — можно аутентифицировать пользователей через сервер LDAP (например, openldap). Сервер и дополнительный резервный сервер можно настроить, а соединение можно зашифровать с помощью SSL.
Пользователь root является неограниченным администратором и всегда может войти в систему, используя Linux PAM. Этого пользователя нельзя удалить, все системные письма будут отправляться на адрес электронной почты, назначенный этому пользователю.
Каждый пользователь может быть членом нескольких групп.
Чтобы пользователь мог выполнить какое-либо действие (например, просмотр, изменение или удаление ВМ), ему необходимо иметь соответствующие разрешения.
PVE использует систему управления разрешениями на основе ролей и путей. Запись в таблице разрешений позволяет пользователю или группе играть определенную роль при доступе к объекту или пути. Это означает, что такое правило доступа может быть представлено как тройка (путь, пользователь, роль) или (путь, группа, роль), причем роль содержит набор разрешенных действий, а путь представляет цель этих действий.
Роль — это список привилегий. В PVE предопределён ряд ролей:
  • Administrator — имеет все привилегии;
  • NoAccess — нет привилегий (используется для запрета доступа);
  • PVEAdmin — все привилегии, кроме прав на изменение настроек системы (Sys.PowerMgmt, Sys.Modify, Realm.Allocate);
  • PVEAuditor — доступ только для чтения;
  • PVEDatastoreAdmin — создание и выделение места для резервного копирования и шаблонов;
  • PVEDatastoreUser — выделение места для резервной копии и просмотр хранилища;
  • PVEPoolAdmin — выделение пулов;
  • PVESysAdmin — ACL пользователя, аудит, системная консоль и системные журналы;
  • PVETemplateUser — просмотр и клонирование шаблонов;
  • PVEUserAdmin — администрирование пользователей;
  • PVEVMAdmin — управление ВМ;
  • PVEVMUser — просмотр, резервное копирование, настройка CDROM, консоль ВМ, управление питанием ВМ.
Просмотреть список предопределенных ролей в веб-интерфейсе можно, выбрав ДатацентрРазрешенияРоли:
Список предопределенных ролей
Добавить новую роль можно как в веб-интерфейсе, так и в командной строке.
Привилегия — это право на выполнение определенного действия. Для упрощения управления списки привилегий сгруппированы в роли, которые затем можно использовать в таблице разрешений. Привилегии не могут быть напрямую назначены пользователям, не будучи частью роли.
Пул ресурсов — это набор ВМ, контейнеров и хранилищ. Пул ресурсов удобно использовать для обработки разрешений в случаях, когда определенные пользователи должны иметь контролируемый доступ к определенному набору ресурсов. Пулы ресурсов часто используются в тандеме с группами, чтобы члены группы имели разрешения на набор машин и хранилищ.

Таблица 44.1. Привилегии используемые в PVE

Привилегия
Описание
Привилегии узла/системы
Permissions.Modify
Изменение прав доступа
Sys.PowerMgmt
Управление питанием узла (запуск, остановка, сброс, выключение)
Sys.Console
Консольный доступ к узлу
Sys.Syslog
Просмотр Syslog
Sys.Audit
Просмотр состояния/конфигурации узла, конфигурации кластера Corosync и конфигурации HA
Sys.Modify
Создание/удаление/изменение параметров сети узла
Group.Allocate
Создание/удаление/изменение групп
Pool.Allocate
Создание/удаление/изменение пулов
Realm.Allocate
Создание/удаление/изменение областей аутентификации
Realm.AllocateUser
Назначение пользователю области аутентификации
User.Modify
Создание/удаление/изменение пользователя
Права, связанные с ВМ
VM.Allocate
Создание/удаление ВМ
VM.Migrate
Миграция ВМ на альтернативный сервер в кластере
VM.PowerMgmt
Управление питанием (запуск, остановка, сброс, выключение)
VM.Console
Консольный доступ к ВМ
VM.Monitor
Доступ к монитору виртуальной машины (kvm)
VM.Backup
Резервное копирование/восстановление ВМ
VM.Audit
Просмотр конфигурации ВМ
VM.Clone
Добавление/изменение/удаление дисков ВМ
VM.Config.Disk
Создание/удаление/изменение областей аутентификации
VM.Config.CDROM
Извлечь/изменить CDROM
VM.Config.CPU
Изменение настроек процессора
VM.Config.Memory
Изменение настроек памяти
VM.Config.Network
Добавление/изменение/удаление сетевых устройств
VM.Config.HWType
Изменение типа эмуляции
VM.Config.Options
Изменение любой другой конфигурации ВМ
VM.Snapshot
Создание/удаление снимков ВМ
Права, связанные с хранилищем
Datastore.Allocate
Создание/удаление/изменение хранилища данных
Datastore.AllocateSpace
Выделить место в хранилище
Datastore.AllocateTemplate
Размещение/загрузка шаблонов контейнеров и ISO-образов
Datastore.Audit
Просмотр хранилища данных
Права доступа назначаются объектам, таким как ВМ, хранилища или пулы ресурсов. PVE использует файловую систему как путь к этим объектам. Эти пути образуют естественное дерево, и права доступа более высоких уровней (более короткий путь) необязательно распространяются вниз по этой иерархии. Примеры:
  • /nodes/<node> — доступ к серверам PVE;
  • /vms — все ВМ;
  • /vms/<vmid> — доступ к определенным ВМ;
  • /storage/<storeid> — доступ к хранилищам;
  • /access/groups — администрирование групп;
  • /access/realms/<realmid> — административный доступ.
Для назначения разрешений необходимо в окне ДатацентрРазрешения нажать кнопку Добавить и в выпадающем меню выбрать Разрешения группы, если разрешения назначаются группе пользователей, или Разрешения пользователя, если разрешения назначаются пользователю. Далее в открывшемся окне выбрать путь, группу и роль и нажать кнопку Добавить:
Добавление разрешений группе
Для добавления нового пользователя, необходимо в окне ДатацентрРазрешенияПользователи нажать кнопку Добавить.
Создание нового пользователя с использованием PAM аутентификации (системный пользователь user должен существовать, в качестве пароля будет использоваться пароль для входа в систему):
Создание нового пользователя с использованием PAM аутентификации
Создание нового пользователя с использованием PVE аутентификации:
Создание нового пользователя с использованием PVE аутентификации
Примеры использования командной строки для управления пользователями PVE:
  • Создать пользователя:
    # pveum useradd testuser@pve -comment "Just a test"
    
  • Задать или изменить пароль:
    # pveum passwd testuser@pve
    
  • Отключить пользователя:
    # pveum usermod testuser@pve -enable 0
    
  • Создать новую группу:
    # pveum groupadd testgroup
    
  • Создать новую роль:
    # pveum roleadd PVE_Power-only -privs "VM.PowerMgmt VM.Console"
    

Часть VI. Управление виртуализацией на основе libvirt

libvirt — это набор инструментов, предоставляющий единый API к множеству различных технологий виртуализации.
Кроме управления виртуальными машинами/контейнерами libvirt поддерживает управление виртуальными сетями и управление хранением образов.
Для управления из консоли разработан набор утилит virt-install, virt-clone, virsh и других. Для управления из графической оболочки можно воспользоваться virt-manager.
Любой виртуальный ресурс, необходимый для создания ВМ (compute, network, storage) представлен в виде объекта в libvirt. За процесс описания и создания этих объектов отвечает набор различных XML-файлов. Сама ВМ в терминологии libvirt называется доменом (domain). Это тоже объект внутри libvirt, который описывается отдельным XML-файлом.
При первоначальной установке и запуске libvirt по умолчанию создает мост (bridge) virbr0 и его минимальную конфигурацию. Этот мост не будет подключен ни к одному физическому интерфейсу, однако, может быть использован для связи виртуальных машин внутри одного гипервизора.

Содержание

45. Установка сервера
46. Утилиты управления
46.1. Утилита Virsh
46.2. Утилита virt-install
46.3. Утилита qemu-img
46.4. Менеджер виртуальных машин virt-manager
47. Подключение к гипервизору
47.1. Управление доступом к libvirt через SSH
47.2. Подключение к сессии гипервизора с помощью virsh
47.3. Настройка соединения с удаленным гипервизором в virt-manager
48. Создание виртуальных машин
48.1. Создание ВМ на основе файла конфигурации (утилита virsh)
48.2. Создание ВМ с помощью virt-install
48.3. Создание ВМ с помощью virt-manager
49. Запуск и управление функционированием ВМ
49.1. Управление состоянием ВМ в командной строке
49.2. Управление состоянием ВМ в менеджере виртуальных машин
49.3. Подключение к виртуальному монитору ВМ
50. Управление ВМ
50.1. Редактирование файла конфигурации ВМ
50.2. Получение информации о ВМ
50.3. Конфигурирование ВМ в менеджере виртуальных машин
50.4. Мониторинг состояния
50.5. Управление виртуальными сетевыми интерфейсами и сетями
50.6. Управление хранилищами
51. Миграция ВМ
51.1. Миграция с помощью virsh
51.2. Миграция ВМ в менеджере виртуальных машин
52. Снимки ВМ
52.1. Управления снимками ВМ в консоли
52.2. Управления снимками ВМ в менеджере виртуальных машин
53. Регистрация событий libvirt
54. Управление доступом в виртуальной инфраструктуре

Глава 45. Установка сервера

В качестве сервера для развертывания libvirt удобно использовать дистрибутив Альт Сервер Виртуализации (Сервер виртуализации). Он уже содержит все необходимые компоненты.

Примечание

Компоненты libvirt будут установлены в систему, если при установке дистрибутива выбрать профиль Базовая виртуализация (см. главу Установка системы).

Примечание

На этапе «Подготовка диска» рекомендуется выбрать KVM Server (large /var/lib/libvirt).
Если же развертывание libvirt происходит в уже установленной системе на базе Девятой платформы, достаточно на всех нодах (узлах) любым штатным способом (apt-get, aptitude, synaptic) установить пакеты libvirt-kvm и virt-install:
# apt-get update
# apt-get install libvirt-kvm virt-install
Запуск службы:
# systemctl enable --now libvirtd
Для непривилегированного доступа (не root) к управлению libvirt, пользователь должен быть включён в группу vmusers:
# gpasswd -a user vmusers
Для удаления узла из кластера необходимо выполнить следующие шаги:
  • /etc/libvirt/ — каталог с файлами конфигурации libvirt;
  • /var/lib/libvirt/ — рабочий каталог сервера виртуализации libvirt;
  • /var/log/libvirt — файлы журналов libvirt.

Глава 46. Утилиты управления

Основные утилиты командной строки для управления ВМ:
  • qemu-img — управление образами дисков ВМ. Позволяет выполнять операции по созданию образов различных форматов, конвертировать файлы-образы между этими форматами, получать информацию об образах и объединять снимки ВМ для тех форматов, которые это поддерживают;
  • virsh — консольный интерфейс управления ВМ, виртуальными дисками и виртуальными сетями;
  • virt-clone — клонирование ВМ;
  • virt-convert — конвертирования ВМ между различными форматами и программно-аппаратными платформами;
  • virt-image — создание ВМ по их XML описанию;
  • virt-install — создание ВМ с помощью опций командной строки;
  • virt-xml — редактирование XML-файлов описаний ВМ.

46.1. Утилита Virsh

virsh — утилита для командной строки, предназначенная для управления ВМ и гипервизорами KVM.
virsh использует libvirt API и служит альтернативой графическому менеджеру виртуальных машин (virt-manager).
С помощью virsh можно сохранять состояние ВМ, переносить ВМ между гипервизорами и управлять виртуальными сетями.
Получить список доступных команд или параметров утилиты virsh, можно используя команду:
$ virsh help

Таблица 46.1. Утилита командной строки virsh. Команды управления виртуальными машинами

Команда
Описание
help
Краткая справка
list
Просмотр всех ВМ
dumpxml
Вывести файл конфигурации XML для заданной ВМ
create
Создать ВМ из файла конфигурации XML и ее запуск
start
Запустить неактивную ВМ
destroy
Принудительно остановить работу ВМ
define
Определяет файл конфигурации XML для заданной ВМ
domid
Просмотр идентификатора ВМ
domuuid
Просмотр UUID ВМ
dominfo
Просмотр сведений о ВМ
domname
Просмотр имени ВМ
domstate
Просмотр состояния ВМ
quit
Закрыть интерактивный терминал
reboot
Перезагрузить ВМ
restore
Восстановить сохраненную в файле ВМ
resume
Возобновить работу приостановленной ВМ
save
Сохранить состояние ВМ в файл
shutdown
Корректно завершить работу ВМ
suspend
Приостановить работу ВМ
undefine
Удалить все файлы ВМ
migrate
Перенести ВМ на другой узел

Таблица 46.2. Утилита командной строки virsh. Параметры управления ресурсами ВМ и гипервизора

Команда
Описание
setmem
Определяет размер выделенной ВМ памяти
setmaxmem
Ограничивает максимально доступный гипервизору объем памяти
setvcpus
Изменяет число предоставленных ВМ виртуальных процессоров
vcpuinfo
Просмотр информации о виртуальных процессорах
vcpupin
Настройка соответствий виртуальных процессоров
domblkstat
Просмотр статистики блочных устройств для работающей ВМ
domifstat
Просмотр статистики сетевых интерфейсов для работающей ВМ
attach-device
Подключить определенное в XML-файле устройство к ВМ
attach-disk
Подключить новое дисковое устройство к ВМ
attach-interface
Подключить новый сетевой интерфейс к ВМ
detach-device
Отключить устройство от ВМ (принимает те же определения XML, что и attach-device)
detach-disk
Отключить дисковое устройство от ВМ
detach-interface
Отключить сетевой интерфейс от ВМ

46.2. Утилита virt-install

virt-install — это инструмент для создания ВМ, основанный на командной строке.
Описание всех доступных опций утилиты virt-install можно получить, выполнив команду:
$ man virt-install

Таблица 46.3. Параметры команды virt-install

Команда
Описание
-n NAME, --name=NAME
Имя новой ВМ. Это имя должно быть уникально внутри одного гипервизора
--memory MEMORY
Определяет размер выделенной ВМ памяти (в МБ)
--vcpus VCPUS
Определяет количество виртуальных ЦПУ. Например:
  • --vcpus 5
  • --vcpus 5,maxvcpus=10,cpuset=1-4,6,8
  • --vcpus sockets=2,cores=4,threads=2
--cpu CPU
Модель ЦП и его характеристики. Например:
  • --cpu coreduo,+x2apic
  • --cpu host-passthrough
  • --cpu host
--metadata METADATA
Метаданные ВМ
Метод установки
--cdrom CDROM
Установочный CD-ROM. Может указывать на файл ISO-образа или на устройство чтения CD/DVD-дисков
-l LOCATION, --location LOCATION
Источник установки, например, https://host/path
--pxe
Выполнить загрузку из сети используя протокол PXE
--import
Пропустить установку ОС, и создать ВМ на основе существующего образа диска
--boot BOOT
Параметры загрузки ВМ. Например:
  • --boot hd,cdrom,menu=on
  • --boot init=/sbin/init (для контейнеров)
--os-type=DISTRO_TYPE
Оптимизирует настройки ВМ для заданного типа ОС
--os-variant=DISTRO_VARIANT
Дополнительная оптимизация ВМ для конкретного варианта ОС
--disk DISK
Настройка пространства хранения данных. Например:
  • --disk size=10 (новый образ на 10 ГБ в выбранном по умолчанию месте)
  • --disk /my/existing/disk,cache=none
  • --disk device=cdrom,bus=scsi
  • --disk=?
-w NETWORK, --network NETWORK
Конфигурация сетевого интерфейса ВМ. Например:
  • --network bridge=mybr0
  • --network network=my_libvirt_virtual_net
  • --network network=mynet,model=virtio,mac=00:11...
  • --network none
--graphics GRAPHICS
Настройки экрана ВМ. Например:
  • --graphics spice
  • --graphics vnc,port=5901,listen=0.0.0.0
  • --graphics none
--input INPUT
Конфигурация устройства ввода. Например:
  • --input tablet
  • --input keyboard,bus=usb
--hostdev HOSTDEV
Конфигурация физических USB/PCI и других устройств хоста для совместного использования ВМ
-filesystem FILESYSTEM
Передача каталога хоста гостевой системе. Например:
  • --filesystem /my/source/dir,/dir/in/guest
Параметры платформы виртуализации
-v, --hvm
Эта ВМ должна быть полностью виртуализированной
-p, --paravirt
Эта ВМ должна быть паравиртуализированной
--container
Тип ВМ — контейнер
--virt-type VIRT_TYPE
Тип гипервизора (kvm, qemu и т.п.)
--arch ARCH
Имитируемая архитектура процессора
--machine MACHINE
Имитируемый тип компьютера
Прочие параметры
--autostart
Запускать домен автоматически при запуске хоста
--transient
Создать временный домен
--noautoconsole
Не подключаться к гостевой консоли автоматически
-q, --quiet
Подавлять вывод (за исключением ошибок)
-d, --debug
Вывести отладочные данные
Далее подробно рассматриваются возможности создания ВМ при помощи утилиты командной строки virt-install.
Утилита virt-install поддерживает как графическую установку операционных систем при помощи VNC и Spice, так и текстовую установку через последовательный порт. Гостевая система может быть настроена на использование нескольких дисков, сетевых интерфейсов, аудиоустройств и физических USB- и PCI-устройств.
Установочный носитель может располагаться как локально, так и удаленно, например, на NFS, HTTP или FTP серверах. В последнем случае virt-install получает минимальный набор файлов для запуска установки и позволяет установщику получить отдельные файлы. Также поддерживается загрузка по сети (PXE) и создание виртуальной машины/контейнера без этапа установки ОС или загрузка по сети предустановленной системы.
Утилита virt-install поддерживает большое число опции, позволяющих создать полностью независимую ВМ, готовую к работе, что хорошо подходит для автоматизации установки ВМ.

46.3. Утилита qemu-img

qemu-img — инструмент для манипулирования с образами дисков машин QEMU.
Использование:
qemu-img command [command options]
Для манипуляции с образами используются следующие команды:
  • create — создание нового образа диска;
  • check — проверка образа диска на ошибки;
  • convert — конвертация существующего образа диска в другой формат;
  • info — получение информации о существующем образе диска;
  • snapshot — управляет снимками состояний (snapshot) существующих образов дисков;
  • commit — записывает произведенные изменения на существующий образ диска;
  • rebase — создает новый базовый образ на основании существующего.
qemu-img работает со следующими форматами:
  • raw — простой формат для дисковых образов, обладающий отличной переносимостью на большинство технологий виртуализации и эмуляции. Только непосредственно записанные секторы будут занимать место на диске. Действительный объем пространства, занимаемый образом, можно определить с помощью команд qemu-img info или ls -ls;
  • qcow2 — формат QEMU. Этот формат рекомендуется использовать для небольших образов (в частности, если файловая система не поддерживает фрагментацию), дополнительного шифрования AES, сжатия zlib и поддержки множества снимков ВМ;
  • qcow — старый формат QEMU. Используется только в целях обеспечения совместимости со старыми версиями;
  • cow — формат COW (Copy On Write). Используется только в целях обеспечения совместимости со старыми версиями;
  • vmdk — формат образов, совместимый с VMware 3 и 4;
  • cloop — формат CLOOP (Compressed Loop). Его единственное применение состоит в обеспечении повторного использования сжатых напрямую образов CD-ROM, например, Knoppix CD-ROM.
Команда получения сведений о дисковом образе:
# qemu-img info /var/lib/libvirt/images/alt8.0.qcow2
image: /var/lib/libvirt/images/alt8.0.qcow2
file format: qcow2
virtual size: 12 GiB (12884901888 bytes)
disk size: 12 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: true
    refcount bits: 16
    corrupt: false
    extended l2: false
В результате будут показаны сведения о запрошенном образе, в том числе зарезервированный объем на диске, а также информация о снимках ВМ.
Команда создания образа для жесткого диска (динамически расширяемый):
# qemu-img create -f qcow2 /var/lib/libvirt/images/hdd.qcow2 20G
Команда конвертирования образ диска из формата raw в qcow2:
# qemu-img convert -f raw -O qcow2 disk_hd.img disk_hd.qcow2

46.4. Менеджер виртуальных машин virt-manager

Менеджер виртуальных машин virt-manager предоставляет графический интерфейс для доступа к гипервизорам и ВМ в локальной и удаленных системах. С помощью virt-manager можно создавать ВМ. Кроме того, virt-manager выполняет управляющие функции:
  • выделение памяти;
  • выделение виртуальных процессоров;
  • мониторинг производительности;
  • сохранение и восстановление, приостановка и возобновление работы, запуск и завершение работы виртуальных машин;
  • доступ к текстовой и графической консоли;
  • автономная и живая миграция.
Для запуска менеджера виртуальных машин, в меню приложений необходимо выбрать СистемаМенеджер виртуальных машин.

Примечание

На управляющей машине должен быть установлен пакет virt-manager.
В главном окне менеджера, при наличии подключения к гипервизору, будут показаны все запущенные ВМ:
Главное окно менеджера виртуальных машин
Двойной щелчок на имени ВМ открывает её консоль.

Глава 47. Подключение к гипервизору

47.1. Управление доступом к libvirt через SSH

В дополнение к аутентификации SSH также необходимо определить управление доступом для службы libvirt в хост-системе.
Доступ к libvirt с удаленного узла
Для настройки подключения к удаленному серверу виртуализации на узле, с которого будет производиться подключение, необходимо сгенерировать SSH-ключ и скопировать его публичную часть на сервер. Для этого с правами пользователя, от имени которого будет создаваться подключение, требуется выполнить в консоли следующие команды:
$ ssh-keygen -t rsa
$ ssh-copy-id user@192.168.0.147
где 192.168.0.147 — IP-адрес сервера с libvirt.
В результате получаем возможность работы с домашними каталогами пользователя user на сервере с libvirt.
Для доступа к libvirt достаточно добавить пользователя user в группу vmusers на сервере, либо скопировать публичный ключ пользователю root и подключаться к серверу по ssh от имени root — root@server.

47.2. Подключение к сессии гипервизора с помощью virsh

Команда подключения к гипервизору:
virsh -c URI
Если параметр URI не задан, то libvirt попытается определить наиболее подходящий гипервизор.
Параметр URI может принимать следующие значения:
  • qemu:///system — подключиться к службе которая управляет KVM/QEMU-доменами и запущена под root. Этот вариант используется по умолчанию для пользователей virt-manager;
  • qemu:///session — подключиться к службе которая управляет KVM/QEMU-доменами и запущена от имени непривилегированного пользователя;
  • lxc:/// — подключиться к гипервизору для создания LXC контейнеров (должен быть установлен пакет libvirt-lxc).
Пример создания локального подключения:
$ virsh -c qemu:///system list --all
 ID   Имя      Состояние
--------------------------
 -    alt9.1   выключен
Подключение к удаленному гипервизору QEMU через протокол SSH:
$ virsh -c qemu+ssh://user@192.168.0.147/system
Добро пожаловать в virsh — интерактивный терминал виртуализации.

Введите  «help» для получения справки по командам
         «quit», чтобы завершить работу и выйти.

virsh #
где:
  • user — имя пользователя на удаленном хосте, который входит в группу vmusers;
  • 192.168.0.147 — IP адрес или имя хоста виртуальных машин.

47.3. Настройка соединения с удаленным гипервизором в virt-manager

На управляющей системе можно запустить virt-manager, выполнив следующую команду:
$ virt-manager -c qemu+ssh://user@192.168.0.147/system
где:
  • user — имя пользователя на удаленном хосте, который входит в группу vmusers;
  • 192.168.0.147 — IP адрес или имя хоста виртуальных машин.
virt-manager позволяет управлять несколькими удаленными хостами ВМ. Подключение virt-manager к удаленным хостам, также, можно настроить и в графическом интерфейсе менеджера виртуальных машин.
Для создания нового подключения необходимо в меню менеджера выбрать ФайлДобавить соединение….
В открывшемся окне следует выбрать сессию гипервизора, отметить пункт Подключиться к удаленному хосту с помощью SSH, ввести имя пользователя и адрес сервера и нажать кнопку Подключиться:
Окно соединений менеджера виртуальных машин

Глава 48. Создание виртуальных машин

Наиболее важным этапом в процессе использования виртуализации является создание ВМ. Именно при создании ВМ задается используемый тип виртуализации, способы доступа к ВМ, подключение к локальной сети и другие характеристики виртуального оборудования.
Установка ВМ может быть запущена из командной строки с помощью программ virsh и virt-install или из пользовательского интерфейса программы virt-manager.

48.1. Создание ВМ на основе файла конфигурации (утилита virsh)

ВМ могут быть созданы из файлов конфигурации. Для этого конфигурация ВМ должна быть описана в XML формате.
Команда создания ВМ из XML файла:
# virsh create guest.xml
Для получения файла конфигурации можно сделать копию существующего XML-файла ранее созданной ВМ, или использовать опцию dumpxml:
virsh dumpxml <domain>
Эта команда выводит XML-файл конфигурации ВМ в стандартный вывод (stdout). Можно сохранить данные, отправив вывод в файл.
Пример передачи вывода в файл guest.xml:
# virsh dumpxml alt9.1 > guest.xml
Можно отредактировать этот файл конфигурации, чтобы настроить дополнительны устройства или развернуть дополнительные ВМ.

Примечание

Подключение к ВМ по протоколу SPICE и VNC рассмотрено в разделе «Подключение к виртуальному монитору ВМ»

48.2. Создание ВМ с помощью virt-install

Минимальные требуемые опции для создания ВМ: --name, --ram, хранилище (--disk, --filesystem или --nodisks) и опции установки.
Чтобы использовать команду virt-install, необходимо сначала загрузить ISO-образ той ОС, которая будет устанавливаться.
Команда создания ВМ:
# virt-install --connect qemu:///system
--name alt-server \
--os-type=linux \
--os-variant=alt9.1 \
--cdrom /var/lib/libvirt/boot/alt-server-x86_64.iso \
--graphics vnc\
--disk pool=default,size=20,bus=virtio,format=qcow2 \
--ram 2048 \
--vcpus=2 \
--network network=default \
--hvm \
--virt-type=kvm
где:
  • --name alt-server — название ВМ;
  • --os-type=linux — тип ОС;
  • --os-variant=alt9.1 — версия ОС;
  • --cdrom /var/lib/libvirt/boot/alt-server-x86_64.iso — путь к ISO-образу установочного диска ОС;
  • --graphics vnc — графическая консоль;
  • --disk pool=default,size=20,bus=virtio,format=qcow2 — хранилище. ВМ будет создана в пространстве хранения объемом 20 ГБ, которое автоматически выделяется из пула хранилищ default. Образ диска для этой виртуальной машины будет создан в формате qcow2;
  • --ram 2048 — объем оперативной памяти;
  • --vcpus=2 — количество процессоров;
  • --network network=default — виртуальная сеть default;
  • --hvm — полностью виртуализированная система;
  • --virt-type=kvm — использовать модуль ядра KVM, который задействует аппаратные возможности виртуализации процессора.
Последние две опции команды virt-install оптимизируют ВМ для использования в качестве полностью виртуализированной системы (--hvm) и указывают, что KVM является базовым гипервизором (--virt-type) для поддержки новой ВМ. Обе этих опции обеспечивают определенную оптимизацию в процессе создания и установки операционной системы; если эти опции не заданы в явном виде, то вышеуказанные значения применяются по умолчанию.
Список доступных вариантов ОС можно получить, выполнив команду:
$ osinfo-query os
Запуск Live CD в ВМ без дисков:
# virt-install \
 --hvm \
 --name demo \
 --ram 500 \
 --nodisks \
 --livecd \
 --graphics vnc \
 --cdrom /var/lib/libvirt/boot/altlive.iso
Запуск /usr/bin/httpd в контейнере (LXC), с ограничением памяти в 512 МБ и двумя ядрами хост-системы:
# virt-install \
 --connect lxc:/// \
 --name httpd_guest \
 --ram 512 \
 --vcpus 2 \
 --init /usr/bin/httpd
Создать ВМ, используя существующий том хранилища:
# virt-install \
 --name demo \
 --ram 512 \
 --disk /home/user/VMs/mydisk.img \
 --import

48.3. Создание ВМ с помощью virt-manager

Новую ВМ можно создать, нажав кнопку Создать виртуальную машину в главном окне virt-manager, либо выбрав в меню ФайлСоздать виртуальную машину.
На первом шаге создания ВМ необходимо выбрать метод установки ОС и нажать кнопку Вперёд:
Создание ВМ. Выбор метода установки
В следующем окне для установки гостевой ОС требуется указать ISO-образ установочного диска ОС или CD/DVD-диск с дистрибутивом:
Создание ВМ. Выбор ISO образа
Данное окно будет выглядеть по-разному в зависимости от выбора, сделанного на предыдущем этапе. Здесь также можно указать версию устанавливаемой ОС.
На третьем шаге необходимо указать размер памяти и количество процессоров для ВМ:
Создание ВМ. Настройка ОЗУ и ЦПУ для ВМ
Эти значения влияют на производительность хоста и ВМ.
На следующем этапе настраивается пространство хранения данных:
Создание ВМ. Настройка пространства хранения данных
На последнем этапе можно задать название ВМ, выбрать сеть и нажать кнопку Готово:
Создание ВМ. Выбор сети
В результате созданная ВМ будет запущена и после завершения исходной загрузки начнется стандартный процесс установки ОС:
Установка ОС
Окружение локального рабочего стола способно перехватывать комбинации клавиш (например, Ctrl+Alt+F11) для предотвращения их отправки гостевой машине. Чтобы отправить такие последовательности, используется свойство «западания» клавиш virt-manager. Для перевода клавиши в нажатое состояние необходимо нажать клавишу модификатора (Ctrl или Alt) 3 раза. Клавиша будет считаться нажатой до тех пор пока не будет нажата любая клавиша, отличная от модификатора. Таким образом, чтобы передать гостевой системе комбинацию Ctrl+Alt+F11, необходимо последовательно нажать Ctrl+Ctrl+Ctrl+Alt+F11 или воспользоваться меню Отправить комбинацию клавиш.

Глава 49. Запуск и управление функционированием ВМ

49.1. Управление состоянием ВМ в командной строке

Команды управления состоянием ВМ:
  • start — запуск ВМ;
  • shutdown — завершение работы. Поведение выключаемой ВМ можно контролировать с помощью параметра on_shutdown (в файле конфигурации);
  • destroy — принудительная остановка. Использование virsh destroy может повредить гостевые файловые системы. Рекомендуется использовать опцию shutdown;
  • reboot — перезагрузка ВМ. Поведение перезагружаемой ВМ можно контролировать с помощью параметра on_reboot (в файле конфигурации);
  • suspend — приостановить ВМ. Когда ВМ находится в приостановленном состоянии, она потребляет системную оперативную память, но не ресурсы процессора;
  • resume — возобновить работу приостановленной ВМ;
  • save — сохранение текущего состояния ВМ. Эта команда останавливает ВМ, сохраняет данные в файл, что может занять некоторое время (зависит от объема ОЗУ ВМ);
  • restore — восстановление ВМ, ранее сохраненной с помощью команды virsh save. Сохраненная машина будет восстановлена из файла и перезапущена (это может занять некоторое время). Имя и идентификатор UUID ВМ останутся неизменными, но будет предоставлен новый идентификатор домена;
  • undefine — удалить ВМ (конфигурационный файл тоже удаляется);
  • autostart — добавить ВМ в автозагрузку;
  • autostart --disable — удалить из автозагрузки;
В результате выполнения следующих команд, ВМ alt-server будет остановлена и затем удалена:
# virsh destroy alt-server
# virsh undefine alt-server

49.2. Управление состоянием ВМ в менеджере виртуальных машин

Для запуска ВМ в менеджере виртуальных машин virt-manager, необходимо выбрать ВМ из списка и нажать на кнопку Включить виртуальную машину:
Включение ВМ
Для управления запущенной ВМ используются соответствующие кнопки панели инструментов virt-manager:
Кнопки управления состоянием ВМ
Управлять состоянием ВМ можно также выбрав соответствующий пункт в контекстном меню ВМ:
Контекстное меню ВМ

49.3. Подключение к виртуальному монитору ВМ

Доступ к рабочему столу ВМ может быть организован по протоколам VNC и SPICE.
К каждой из ВМ можно подключиться, используя один IP адрес и разные порты. Порт доступа к ВМ может быть назначен вручную или автоматически. Удаленный доступ к ВМ можно защитить паролем.

49.3.1. Использование протокола SPICE

Чтобы добавить поддержку SPICE в существующую ВМ, необходимо отредактировать её конфигурацию:
#  virsh edit alt-server
Добавить графический элемент SPICE, например:
<graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>
Добавить видеоустройство QXL:
<video>
    <model type='qxl'/>
</video>
После остановки и перезапуска ВМ она должна быть доступна через SPICE. Проверка параметров подключения к ВМ:
# virsh domdisplay alt-server
spice://127.0.0.1:5900
В данном примере доступ к ВМ будет возможен только с локального адреса (127.0.0.1). Для удаленного подключения к ВМ SPICE-сервер должен обслуживать запросы с общедоступных сетевых интерфейсов. Для возможности подключения с других машин в конфигурации ВМ ,необходимо указать адрес 0.0.0.0:
<graphics type='spice' port='5900' autoport='yes' listen='0.0.0.0' passwd='mypasswd'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
Изменение настроек доступа к рабочему столу в менеджере ВМ:
Менеджер ВМ. Вкладка «Дисплей Spice»
Для подключения к SPICE-серверу может использоваться встроенный в virt-manager просмотрщик или любой SPICE-клиент. Примеры подключений (на хосте, с которого происходит подключение, должен быть установлен пакет virt-viewer):
$ virt-viewer -c qemu+ssh://user@192.168.0.147/system -d alt-server

$ remote-viewer "spice://192.168.0.147:5900"

Примечание

При использовании любого SPICE-клиента подключение происходит к порту и адресу хоста KVM, а не к фактическому имени/адресу ВМ.

49.3.2. Использование протокола VNC

Пример настройки доступа к рабочему столу ВМ по протоколу VNC, в файле конфигурации ВМ:
<graphics type='vnc' port='5900' autoport='no' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
Изменение настроек доступа к рабочему столу в менеджере ВМ:
Менеджер ВМ. Вкладка «Дисплей VNC»
Проверка параметров подключения к ВМ:
# virsh domdisplay alt-server
vnc://localhost:0
Для подключения к VNC-серверу может использоваться встроенный в virt-manager просмотрщик или любой VNC-клиент. Примеры подключений (на хосте, с которого происходит подключение, должны быть соответственно установлены пакеты virt-viewer или tigervnc):
$ virt-viewer -c qemu+ssh://user@192.168.0.147/system -d alt-server

$ vncviewer 192.168.0.147:5900

Глава 50. Управление ВМ

50.1. Редактирование файла конфигурации ВМ

ВМ могут редактироваться либо во время работы, либо в автономном режиме. Эту функциональность предоставляет команда virsh edit. Например, команда редактирования ВМ с именем alt-server:
# virsh edit alt-server
В результате выполнения этой команды откроется окно текстового редактора, заданного переменной оболочки $EDITOR.

50.2. Получение информации о ВМ

Команда для получения информации о ВМ:
virsh dominfo <domain>
где [--domain] <строка> — имя, ID или UUID домена.
Пример вывода virsh dominfo:
# virsh dominfo alt-server
ID:             4
Имя:         alt-server
UUID:           c8170e81-92ab-44f3-bb6c-14155e11f848
Тип ОС:    hvm
Статус:   работает
CPU:            1
Время CPU: 7244,5s
Макс.память: 1048576 KiB
Занято памяти: 1048576 KiB
Постоянство: no
Автозапуск: выкл.
Управляемое сохранение: no
Модель безопасности: none
DOI безопасности: 0
Получение информации об узле:
virsh nodeinfo
Пример вывода virsh nodeinfo:
# virsh nodeinfo
Модель процессора: x86_64
CPU:                 4
Частота процессора: 979 MHz
Сокеты:        1
Ядер на сокет: 2
Потоков на ядро: 2
Ячейки NUMA:   1
Объём памяти: 8011152 KiB
Просмотр списка ВМ:
virsh list
Опции команды virsh list:
  • --inactive — показать список неактивных доменов;
  • --all — показать все ВМ независимо от их состояния.
Пример вывода virsh list:
# virsh list --all
 ID   Имя          Состояние
--------------------------
 4    alt-server   работает
Столбец «Состояние» может содержать следующие значения:
  • работает (running) — работающие ВМ, то есть те машины, которые используют ресурсы процессора в момент выполнения команды;
  • blocked — заблокированные, неработающие машины. Такой статус может быть вызван ожиданием ввода/вывода или пребыванием машины в спящем режиме;
  • приостановлен (paused) — приостановленные домены. В это состояние они переходят, если администратор нажал кнопку паузы в окне менеджера ВМ или выполнил команду virsh suspend. В приостановленном состоянии ВМ продолжает потреблять ресурсы, но не может занимать больше процессорных ресурсов;
  • выключен (shutdown) — ВМ, завершающие свою работу. При получении ВМ сигнала завершения работы, она начнет завершать все процессы (некоторые операционные системы не отвечают на такие сигналы);
  • dying — сбойные домены и домены, которые не смогли корректно завершить свою работу;
  • crashed — сбойные домены, работа которых была прервана. В этом состоянии домены находятся, если не была настроена их перезагрузка в случае сбоя.
Получение информации о виртуальных процессорах:
virsh vcpuinfo <domain>
Пример вывода:
# virsh vcpuinfo alt-server
Виртуальный процессор:  0
CPU:            1
Состояние: работает
Время CPU: 845,0s
Соответствие ЦП: y
Команда сопоставления виртуальных процессоров физическим:
virsh vcpupin <domain> [--vcpu <число>] [--cpulist <строка>] [--config] [--live] [--current]
Здесь:
  • [--domain] <строка> — имя, ID или UUID домена;
  • --vcpu <число> — номер виртуального процессора;
  • --cpulist <строка> — номера физических процессоров. Если номера не указаны, команда вернет текущий список процессоров;
  • --config — с сохранением после перезагрузки;
  • --live — применить к работающему домену;
  • --current — применить к текущему домену.
Пример вывода:
 # virsh vcpupin alt-server
 Виртуальный процессор:   Соответствие ЦП
-------------------------------------------
 0                        0-3
Команда изменения числа процессоров для домена (заданное число не может превышать значение, определенное при создании ВМ):
virsh setvcpus <domain> <count> [--maximum] [--config] [--live] [--current] [--guest] [--hotpluggable]
где:
  • [--domain] <строка> — имя, ID или UUID домена;
  • [--count] <число> — число виртуальных процессоров;
  • --maximum — установить максимальное ограничение на количество виртуальных процессоров, которые могут быть подключены после следующей перезагрузки домена;
  • --guest — состояние процессоров ограничивается гостевым доменом.
Команда изменения выделенного ВМ объема памяти:
virsh setmem <domain> <size> [--config] [--live] [--current]
где:
  • [--domain] <строка> — имя, ID или UUID домена;
  • [--size] <число> — целое значение нового размера памяти (по умолчанию в КБ).
Объем памяти, определяемый заданным числом, должен быть указан в килобайтах. Объем не может превышать значение, определенное при создании ВМ, но в то же время не должен быть меньше 64 МБ. Изменение максимального объема памяти может оказать влияние на функциональность ВМ только в том случае, если указанный размер меньше исходного. В таком случае использование памяти будет ограничено.
Команда изменения максимально допустимого размера выделяемой памяти:
virsh setmaxmem <domain> <size> [--config] [--live] [--current]
где:
  • [--domain] <строка> — имя, ID или UUID домена;
  • [--size] <число> — целое значение максимально допустимого размера памяти (по умолчанию в КБ).
Примеры изменения размера оперативной памяти и количества виртуальных процессоров соответственно:
# virsh setmaxmem --size 624000 alt-server
# virsh setmem --size 52240 alt-server
# virsh setvcpus --config alt-server 3 --maximum
Команда для получения информации о блочных устройствах работающей ВМ:
virsh domblkstat <domain> [--device <строка>] [--human]
где:
  • [--domain] <строка> — имя, ID или UUID домена;
  • --device <строка> — блочное устройство;
  • --human — форматировать вывод.
Команда для получения информации о сетевых интерфейсах работающей ВМ:
virsh domifstat <domain> <interface>
где:
  • [--domain] <строка> — имя, ID или UUID домена;
  • [--interface] <строка> — устройство интерфейса, указанное по имени или MAC-адресу.

50.3. Конфигурирование ВМ в менеджере виртуальных машин

С помощью менеджера виртуальных машин можно получить доступ к подробной информации о всех ВМ, для этого следует:
  1. В главном окне менеджера выбрать ВМ.
  2. Нажать кнопку Открыть:
    Окно менеджера виртуальных машин
  3. В открывшемся окне нажать кнопку Показать виртуальное оборудование:
    Окно параметров ВМ
  4. Появится окно просмотра сведений ВМ.
Для изменения требуемого параметра необходимо перейти на нужную вкладку, внести изменения и подтвердить операцию, нажав кнопку Применить:
Вкладка «Память»
Вкладка «Процессоры»

50.4. Мониторинг состояния

С помощью менеджера виртуальных машин можно изменить настройки контроля состояния ВМ.
Для этого в меню Правка следует выбрать пункт Параметры, в открывшемся окне Настройки на вкладке Статистика можно задать время обновления состояния ВМ в секундах:
Вкладка «Статистика»
На вкладке Консоль можно выбрать, как открывать консоль, и указать устройство ввода:
Вкладка «Консоль»

50.5. Управление виртуальными сетевыми интерфейсами и сетями

При базовых настройках используется виртуальная сеть недоступная извне.
Доступ по IP может быть осуществлен с компьютера, на котором поднят KVM. Изнутри доступ происходит через NAT.
Возможные варианты настройки сети:
  • NAT — это вариант по умолчанию. Внутренняя сеть, предоставляющая доступ к внешней сети с автоматическим применением NAT;
  • Маршрутизация (Routed) — аналогично режиму NAT внутренняя сеть, предоставляющая доступ к внешней сети, но без NAT. Предполагает дополнительные настройки таблиц маршрутизации во внешней сети;
  • Изолированная IPv4/IPv6 сеть (Isolated) — в этом режиме, ВМ подключенные к виртуальному коммутатору могут общаться между собой и с хостом. При этом их трафик не будет выходить за пределы хоста;
  • Bridge — подключение типа мост. Позволяет реализовать множество различных конфигураций, в том числе и назначение IP из реальной сети;
  • SR-IOV pool (Single-root IOV) — перенаправление одной PCI сетевых карт хост-машины на ВМ. Технология SR-IOV повышает производительность сетевой виртуализации, избавляя гипервизор от обязанности организовывать совместное использование физического адаптера и перекладывая задачу реализации мультиплексирования на сам адаптер. В этом случае обеспечивается прямая пересылка ввода/вывода с ВМ непосредственно на адаптер.

50.5.1. Управление виртуальными сетями в командной строке

Команды управления виртуальными сетями:
  • virsh net-autostart имя_сети — автоматический запуск заданной сети;
  • virsh net-autostart имя_сети --disable — отключить автозапуск заданной сети;
  • virsh net-create файл_XML — создание и запуск новой сети на основе существующего XML-файла;
  • virsh net-define файл_XML — создание нового сетевого устройства на основе существующего XML-файла (устройство не будет запущено);
  • virsh net-list — просмотр списка виртуальных сетей;
  • virsh net-dumpxml имя_сети —просмотр информации о заданной виртуальной сети;
  • virsh net-destroy имя_сети — удаление заданной сети;
  • virsh net-name UUID_сети — преобразование заданного идентификатора в имя сети;
  • virsh net-uuid имя_сети — преобразование заданного имени в идентификатор UUID;
  • virsh net-update имя_сети — обновить существующую конфигурацию сети;
  • virsh net-start имя_неактивной_сети — запуск неактивной сети;
  • virsh net-undefine имя_неактивной_сети — удаление определения неактивной сети.
# virsh net-list --all
 Имя       Состояние    Автозапуск   Постоянный
-------------------------------------------------
 default   не активен   no           yes

# virsh net-start default
Сеть default запущена

# virsh net-autostart default
Добавлена метка автоматического запуска сети default

# virsh net-list
 Имя       Состояние   Автозапуск   Постоянный
------------------------------------------------
 default   активен     yes          yes

# virsh net-dumpxml default
<network>
  <name>default</name>
  <uuid>0b37eff3-2234-4929-8a42-04a9cf35d3aa</uuid>
  <forward mode='nat' />
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:3e:12:c7'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>
Иногда бывает полезно выдавать клиенту один и тот же IP-адрес независимо от момента обращения. Пример добавления статического сопоставления MAC- и IP-адреса ВМ:
  1. Получить MAC-адрес ВМ (alt-server — имя ВМ):
    # virsh dumpxml alt-server | grep 'mac address'
            <mac address='52:54:00:ba:f2:76'/>
    
  2. Отредактировать XML-конфигурацию сети (default — имя сети):
    # virsh net-edit default
    
    После строки:
    <range start='192.168.122.2' end='192.168.122.254'/>
    
    Вставить строки с MAC-адресами виртуальных адаптеров:
    <host mac='52:54:00:ba:f2:76' name='alt-server' ip='192.168.122.50'/>
    
  3. Сохранить изменения и перезапустить виртуальную сеть:
    # virsh net-destroy default
    # virsh net-start default
    
Изменения внесённые с помощью команды virsh net-edit не вступят в силу в силу до тех пор, пока сеть не будет перезапущена, что приведет к потере всеми ВМ сетевого подключения к хосту до тех пор, пока их сетевые интерфейсы повторно не подключаться.
Изменения в конфигурацию сети, можно внести с помощью команды virsh net-update, которая требует немедленного применения изменений. Например, чтобы добавить запись статического хоста, можно использовать команду:
# virsh net-update default add ip-dhcp-host \
   "<host mac='52:54:00:ba:f2:76' name='alt-server' ip='192.168.122.50' />" \
   --live --config

50.5.2. Управление виртуальными сетями в менеджере виртуальных машин

В менеджере виртуальных машин virt-manager существует возможность настройки виртуальных сетей для обеспечения сетевого взаимодействия ВМ как между собой, так и с хостовой ОС.
Для настройки виртуальной сети с помощью virt-manager необходимо:
  1. В меню Правка выбрать Свойства подключения:
    Окно менеджера виртуальных машин. Меню «Правка»
  2. В открывшемся окне перейти на вкладку Виртуальные сети:
    Окно параметров виртуальной сети
  3. Доступные виртуальные сети будут перечислены в левой части окна. Для доступа к настройкам сети необходимо выбрать сеть.
Для добавления новой виртуальной сети следует нажать кнопку Добавить сеть Добавить сеть , расположенную в нижнем левом углу диалогового окна Свойства соединения.
В открывшемся окне следует ввести имя для новой сети и задать необходимые настройки: выбрать способ подключения виртуальной сети к физической, ввести пространство адресов IPv4 для виртуальной сети, указать диапазон DHCP, задав начальный и конечный адрес и нажать кнопку Готово:
Создание новой виртуальной сети

50.6. Управление хранилищами

API-интерфейс libvirt обеспечивает удобную абстракцию для размещения образов ВМ и файловых систем, которая носит название storage pools (пул хранилищ). Пул хранилищ — это локальный каталог, локальное устройство хранения данных (физический диск, логический том или хранилище на основе хост-адаптера шины SCSI [SCSI HBA]), файловая система NFS (network file system), либо сетевое хранилище блочного уровня, управляемое посредством libvirt и позволяющее создать и хранить один или более образов ВМ.
По умолчанию команды на базе libvirt используют в качестве исходного пула хранилищ для каталога файловой системы каталог /var/lib/libvirt/images на хосте виртуализации.
Образ диска — это снимок данных диска ВМ, сохраненный в том или ином формате. libvirt понимает несколько форматов образов. Так же возможна работа с образами CD/DVD дисков. Каждый образ хранится в том или ином хранилище.
Типы хранилищ, с которыми работает libvirt:
  • dir — каталог в файловой системе;
  • disk — физический диск;
  • fs — отформатированное блочное устройство;
  • gluster — файловая система Gluster;
  • isci — хранилище iSCSI;
  • logical — группа томов LVM;
  • mpath — регистратор многопутевых устройств;
  • netfs — экспорт каталога из сети;
  • rbd — блочное устройство RADOS/Ceph;
  • scsi — хост-адаптер SCSI;
  • sheepdog — файловая система Sheepdog;
  • zfs — пул ZFS.

50.6.1. Управление хранилищами в командной строке

Таблица 50.1. Утилита командной строки virsh. Команды управления хранилищами

Команда
Описание
pool-define
Определить неактивный постоянный пул носителей на основе файла XML
pool-create
Создать пул из файла XML
pool-define-as
Определить пул на основе набора аргументов
pool-create-as
Создать пул на основе набора аргументов
pool-dumpxml
Вывести файл конфигурации XML для заданного пула
pool-list
Вывести список пулов
pool-build
Собрать пул
pool-start
Запустить ранее определённый неактивный пул
pool-autostart
Автозапуск пула
pool-destroy
Разрушить (остановить) пул
pool-delete
Удалить пул
pool-edit
Редактировать XML-конфигурацию пула носителей
pool-info
Просмотр информации о пуле носителей
pool-refresh
Обновить пул
pool-undefine
Удалить определение неактивного пула
Команда virsh pool-define-as создаст файл конфигурации для постоянного пула хранения. Позже этот пул можно запустить командой virsh pool-start, настроить его на автоматический запуск при загрузке хоста, остановить командой virsh pool-destroy.
Команда virsh pool-create-as создаст временный пул хранения (файл конфигурации не будет создан), который будет сразу запущен. Этот пул хранения будет удалён командой virsh pool-destory. Временный пул хранения нельзя запустить автоматически при загрузке. Преобразовать существующий временный пул в постоянный, можно создав файл XML-описания:
virsh pool-dumpxml имя_пула > имя_пула.xml && virsh pool-define имя_пула.xml
Пример создания пула хранения на основе NFS (netfs):
# virsh pool-create-as NFS-POOL netfs \
--source-host 192.168.0.105 \
--source-path /export/storage \
--target /var/lib/libvirt/images/NFS-POOL
Пул NFS-POOL создан
Первый аргумент (NFS-POOL) идентифицирует имя нового пула, второй аргумент идентифицирует тип создаваемого пула. Аргумент опции --source-host идентифицирует хост, который экспортирует каталог пула хранилищ посредством NFS. Аргумент опции --source-path определяет имя экспортируемого каталога на этом хосте. Аргумент опции --target идентифицирует локальную точку монтирования, которая будет использоваться для обращения к пулу хранилищ (этот каталог должен существовать).

Примечание

Для возможности монтирования NFS хранилища необходимо запустить службы rpcbind и nfslock:
# systemctl start rpcbind
# systemctl start nfslock
После создания нового пула он будет указан в выводе команды virsh pool-list:
# virsh pool-list --all --details
 Имя        Состояние   Автозапуск   Постоянный   Размер      Распределение   Доступно
-----------------------------------------------------------------------------------------
 default    работает    yes          yes          37,15 GiB   2,94 GiB        34,21 GiB
 NFS-POOL   работает    no           no           29,40 GiB   7,26 GiB        22,14 GiB
В выводе команды видно, что опция Автозапуск (Autostart) для пула хранилищ NFS-POOL имеет значение no (нет), т. е. после перезапуска системы этот пул не будет автоматически доступен для использования, и что опция Постоянный (Persistent) также имеет значение no, т. е. после перезапуска системы этот пул вообще не будет определен. Пул хранилищ является постоянным только в том случае, если он сопровождается XML-описанием пула хранилищ, которое находится в каталоге /etc/libvirt/storage. XML-файл описания пула имеет такое же имя, как у пула хранилищ, с которым он ассоциирован.
Чтобы создать файл XML-описания для сформированного в ручном режиме пула, следует воспользоваться командой virsh pool-dumpxml, указав в качестве ее заключительного аргумента имя пула, для которого нужно получить XML-описание. Эта команда осуществляет запись в стандартное устройство вывода, поэтому необходимо перенаправить ее выходную информацию в соответствующий файл.
Следующая команда создаст файл XML-описания для созданного ранее пула NFS-POOL и определит постоянный пул на основе этого файла:
# virsh pool-dumpxml NFS-POOL > NFS-POOL.xml && virsh pool-define NFS-POOL.xml
Пул NFS-POOL определён на основе NFS-POOL.xml
Чтобы задать для пула хранилищ опцию Автозапуск (Autostart), можно воспользоваться командой virsh pool-autostart:
# virsh pool-autostart NFS-POOL
Добавлена метка автоматического запуска пула NFS-POOL
Маркировка пула хранилищ как автозапускаемого говорит о том, что этот пул хранилищ будет доступен после любого перезапуска хоста виртуализации (каталог /etc/libvirt/storage/autostart будет содержать символьную ссылку на XML-описание этого пула хранилищ).
Пример создания постоянного локального пула:
# virsh pool-define-as boot --type dir --target /var/lib/libvirt/boot
Пул boot определён

# virsh pool-list --all
 Имя        Состояние    Автозапуск
-------------------------------------
 default    активен      yes
 boot       не активен   no
 NFS-POOL   активен      yes

# virsh pool-build boot
Пул boot собран

# virsh pool-start boot
Пул boot запущен

# virsh pool-autostart boot
Добавлена метка автоматического запуска пула boot

# virsh pool-list --all
 Имя        Состояние    Автозапуск
-------------------------------------
 default    активен      yes
 boot       активен      yes
 NFS-POOL   активен      yes
Пример создания пула хранения на основе iSCSI:
# virsh pool-create-as --name iscsi_virtimages --type iscsi \
     --source-host 192.168.0.146 \
     --source-dev iqn.2021-05.alt.test:iscsi.target1 \
     --target /dev/disk/by-path
Пул iscsi_virtimages создан
Аргумент опции --source-host определяет имя хоста соответствующего сервера iSCSI, который экспортирует данный iSCSI LUN. Аргумент опции --source-dev определяет название iSCSI LUN. Аргумент опции --target идентифицирует локальную точку монтирования, которая будет использоваться для обращения к пулу хранилищ.

Примечание

Для возможности работы с устройством, подключенном по интерфейсу iSCSI должна быть запущена служба iscsid (должен быть установлен пакет open-iscsi):
# systemctl enable --now iscsid

50.6.2. Настройка хранилищ в менеджере виртуальных машин

Для настройки хранилищ с помощью virt-manager необходимо:
  1. В меню Правка выбрать Свойства подключения:
    Окно менеджера виртуальных машин. Меню «Правка»
  2. В открывшемся окне перейти на вкладку Пространство данных:
    Вкладка Пространство данных
Для добавления пула следует нажать кнопку Добавить пул Добавить пул , расположенную в нижнем левом углу диалогового окна Свойства соединения.
В открывшемся окне следует выбрать тип пула:
Создание пула хранения. Выбор типа пула
Далее необходимо задать параметры пула:
Создание пула хранения. Ввод параметров

Глава 51. Миграция ВМ

Под миграцией понимается процесс переноса ВМ с одного узла на другой.
Живая миграция позволяет перенести работу ВМ с одного физического хоста на другой без остановки ее работы.
Для возможности миграции ВМ, ВМ должна быть создана с использованием общего пула хранилищ (NFS, ISCSI, GlusterFS, CEPH).

Примечание

Живая миграция возможна даже без общего хранилища данных (с опцией --copy-storage-all). Но это приведет к большому трафику при копировании образа ВМ между серверами виртуализации и к заметному простою сервиса. Что бы миграция была по-настоящему «живой» с незаметным простоем необходимо использовать общее хранилище.

51.1. Миграция с помощью virsh

ВМ можно перенести на другой узел с помощью команды virsh. Для выполнения живой миграции нужно указать параметр --live. Команда переноса:
# virsh migrate --live VMName DestinationURL
где
  • VMName — имя перемещаемой ВМ;
  • DestinationURL — URL или имя хоста узла назначения. Узел назначения должен использовать тот же гипервизор и служба libvirt на нем должна быть запущена.
После ввода команды будет запрошен пароль администратора узла назначения.
Для выполнения живой миграции ВМ alt-server на узел 192.168.0.190 с помощью virsh, необходимо выполнить следующие действия:
  1. Убедиться, что ВМ запущена:
    # virsh list
     ID   Имя          Состояние
    ------------------------------
     7    alt-server   работает
    
  2. Выполнить следующую команду, чтобы начать перенос ВМ на узел 192.168.0.190 (после ввода команды будет запрошен пароль пользователя root системы назначения):
    # virsh migrate --live alt-server qemu+ssh://192.168.0.190/system
    
  3. Процесс миграции может занять некоторое время в зависимости от нагрузки и размера ВМ. virsh будет сообщать только об ошибках. ВМ будет продолжать работу на исходном узле до завершения переноса;
  4. Проверить результат переноса, выполнив на узле назначения команду:
    # virsh list
    

51.2. Миграция ВМ в менеджере виртуальных машин

Менеджер виртуальных машин virt-manager поддерживает возможность миграции ВМ между серверами виртуализации.
Для выполнения миграции, в virt-manager необходимо выполнить следующие действия:
  1. Подключить второй сервер виртуализации (ФайлДобавить соединение…);
  2. В контекстном меню ВМ (она должна быть запущена) выбрать пункт Миграция:
    Пункт Миграция в контекстном меню ВМ
  3. В открывшемся окне выбрать конечный узел и нажать кнопку Миграция:
    Миграция ВМ
При этом конфигурационный файл перемещаемой машины не переходит на новый узел, поэтому при ее выключении она вновь появится на старом хосте. В связи с этим, для совершения полной живой миграции, при котором конфигурация ВМ будет перемещена на новый узел, необходимо воспользоваться утилитой командной строки virsh:
# virsh migrate --live --persistent --undefinesource \
alt-server qemu+ssh://192.168.0.190/system

Глава 52. Снимки ВМ

Примечание

Снимок (snapshot) текущего состояния машины можно создать только если виртуальный жесткий диск в формате *.qcow2.

52.1. Управления снимками ВМ в консоли

Команда создания снимка (ОЗУ и диск) из файла XML:
# virsh snapshot-create <domain> [--xmlfile <строка>] [--disk-only] [--live]...
Команда создания снимка (ОЗУ и диск) напрямую из набора параметров:
# virsh snapshot-create-as <domain> [--name <строка>] [--disk-only] [--live]...
Пример создания снимка ВМ:
# virsh snapshot-create-as --domain alt-server --name alt-server-25may2021
Снимок домена alt-server-25may2021 создан
где
  • alt-server — имя ВМ;
  • alt-server-25may2021 — название снимка.
После того, как снимок ВМ будет сделан, резервные копии файлов конфигураций будут находиться в каталоге /var/lib/libvirt/qemu/snapshot/.
Пример создания снимка диска ВМ:
# virsh snapshot-create-as --domain alt-server --name 05may2021 -diskspec vda,file=/var/lib/libvirt/images/sn1.qcow2 --disk-only --atomic
Снимок домена 05may2021 создан
Просмотр существующих снимков для домена alt-server:
# virsh snapshot-list --domain alt-server
 Имя                    Время создания              Состояние
---------------------------------------------------------------
 05may2021              2021-05-05 11:39:41 +0200   shutoff
 alt-server-25may2021   2021-05-25 16:06:50 +0200   running
Восстановить ВМ из снимка:
# virsh snapshot-revert --domain alt-server --snapshotname 05may2021 –running
Удалить снимок:
# virsh snapshot-delete --domain alt-server --snapshotname 05may2021

52.2. Управления снимками ВМ в менеджере виртуальных машин

Для управления снимками ВМ в менеджере виртуальных машин virt-manager необходимо выполнить следующие действия:
  1. В главном окне менеджера выбрать ВМ.
  2. Нажать кнопку Открыть.
  3. В открывшемся окне нажать кнопку Управление снимками:
    Управление снимками ВМ
    Появится окно управления снимками ВМ.
Для создания нового снимка следует нажать кнопку Создать новый снимок Управление снимками ВМ , расположенную в нижнем левом углу окна управления снимками ВМ. В открывшемся окне следует указать название снимка и нажать кнопку Готово:
Создание снимка
Для того чтобы восстановить ВМ из снимка или удалить снимок, следует воспользоваться контекстным меню снимка:
Контекстное меню снимка

Глава 53. Регистрация событий libvirt

Настройка регистрации событий в libvirt, осуществляется в файле /etc/libvirt/libvirtd.conf. Логи сохраняются в каталоге /var/log/libvirt.
Функция журналирования в libvirt основана на трех ключевых понятиях:
  • сообщения журнала;
  • фильтры;
  • формат ввода.
Сообщения журнала — это информация, полученная во время работы libvirt. Каждое сообщение включает в себя уровень приоритета (отладочное сообщение — 1, информационное — 2, предупреждение — 3, ошибка — 4). По умолчанию, log_level=1, т. е. журналируются все сообщения.
Фильтры — это набор шаблонов и для записи сообщений в журнал. Если категория сообщения совпадает с фильтром, приоритет сообщения сравнивается с приоритетом фильтра, если она ниже сообщение отбрасывается, иначе сообщение записывается в журнал. Если сообщение не соответствует ни одному фильтру, то применяется общий уровень. Это позволяет, например, захватить все отладочные сообщения для QEmu, а для остальных, только сообщения об ошибках.
Формат для фильтра:
x:name  (log message only)
x:+name (log message + stack trace)
где
  • name — строка, которая сравнивается с заданной категорией, например, remote, qemu, или util.json;
  • + — записывать каждое сообщение с данным именем;
  • x — минимальный уровень ошибки (1, 2, 3, 4).
Пример фильтра:
Log_filtrers="3:remote 4:event"
Как только сообщение прошло через фильтрацию набора выходных данных, формат вывода определяет, куда отправить сообщение. Формат вывода также может фильтровать на основе приоритета, например, он может быть полезен для вывода всех сообщений в файл отладки.
  • x:stderr — вывод в STDERR;
  • x:syslog:name — использовать системный журнал для вывода и использовать данное имя в качестве идентификатора;
  • x:file:file_path — вывод в файл, с соответствующим filepath;
  • x:journal — вывод в systemd журнал.
Пример:
Log_outputs=”3:syslog:libvirtd 1:file:/tmp/libvirt.log”
Журналы работы виртуальных машин под KVM хранятся в /var/log/libvirt/qemu/. В этом каталоге libvirt хранит журнал для каждой виртуальной машины. Например, для машины с названием alt-server журнал будет находиться по адресу: /var/log/libvirt/qemu/alt-server.log.

Глава 54. Управление доступом в виртуальной инфраструктуре

Права пользователя могут управляться с помощью правил polkit.
В каталоге /usr/share/polkit-1/actions/ имеются два файла с описанием возможных действий для работы с ВМ, предоставленные разработчиками libvirt:
  • файл org.libvirt.unix.policy описывает мониторинг ВМ и управление ими;
  • в файле org.libvirt.api.policy перечислены конкретные действия (остановка, перезапуск и т. д.), которые возможны, если предыдущая проверка пройдена.
Перечисление конкретных свойств с комментариями доступно в файле /usr/share/polkit-1/actions/org.libvirt.api.policy.
В libvirt названия объектов и разрешений отображаются в имена polkit действий, по схеме:
org.libvirt.api.$объект.$разрешение
Например, разрешение search-storage-vols на объекте storage_pool отображено к действию polkit:
org.libvirt.api.storage-pool.search-storage-vols
Чтобы определить правила авторизации, polkit должен однозначно определить объект. Libvirt предоставляет ряд атрибутов для определения объектов при выполнении проверки прав доступа. Набор атрибутов изменяется в зависимости от типа объекта.
Пример тонкой настройки. Есть две виртуальные машины: alt1, alt2. Необходимо разрешить пользователю test (должен быть в группе vmusers) действия только с доменом alt1. Для этого необходимо выполнить следующие действия:
  1. Раскомментировать в файле /etc/libvirt/libvirtd.conf строку:
    access_drivers = [ "polkit" ]
    
  2. Перезапустить libvirt:
    systemctl restart libvirtd
    
  3. Создать файл /etc/polkit-1/rules.d/100-libvirt-acl.rules (имя произвольно) следующего вида:
    ==========================
    polkit.addRule(function(action, subject) {
    // разрешить пользователю test действия с доменом "alt1"
    if (action.id.indexOf("org.libvirt.api.domain.") ==0  &&
       subject.user == "test")
        {
            if (action.lookup("domain_name") == 'alt1')
            {
                return polkit.Result.YES;
            }
            else
            {
                return polkit.Result.NO;
            }
        }
    else {
    // разрешить пользователю test действия с
    //подключениями, хранилищем и прочим
            if (action.id.indexOf("org.libvirt.api.") == 0 &&
            subject.user == "test")
            {
                polkit.log("org.libvirt.api.Yes");
                return polkit.Result.YES;
            }
            else
            {
                return polkit.Result.NO;
            }
        }
    })
    ================================
    
  4. Перелогиниться.
В результате выполненных действий пользователю test машина alt1 видна, а машина alt2 — нет.
 Права можно настраивать более тонко, например, разрешив пользователю test запускать ВМ, но запретить ему все остальные действия с ней, для этого надо разрешить действие org.libvirt.api.domain.start:
==========================
polkit.addRule(function(action, subject)
{
    // разрешить пользователю test только запускать ВМ в
    // домене "alt1"
    if (action.id. == "org.libvirt.api.domain.start") &&
    subject.user == "test")
    {
        if (action.lookup("domain_name") == 'alt1')
        {
           return polkit.Result.YES;
        }
        else
        {
            return polkit.Result.NO;
        }
    }
});
==========================
Предоставить право запускать ВМ, только пользователям группы wheel:
if (action.id == "org.libvirt.api.domain.start")
{
    if (subject.isInGroup("wheel"))
    {
        return polkit.Result.YES;
    }
    else
    {
        return polkit.Result.NO;
    }
};
Предоставить право останавливать ВМ, только пользователям группы wheel:
if (action.id == "org.libvirt.api.domain.stop")
{
    if (subject.isInGroup("wheel"))
    {
        return polkit.Result.YES;
    }
    else
    {
        return polkit.Result.NO;
    }
};
Можно также вести файл журнала, используя правила polkit. Например, делать запись в журнал при старте ВМ:
if (action.id.match("org.libvirt.api.domain.start"))
{
    polkit.log("action=" + action);
    polkit.log("subject=" + subject);
    return polkit.Result.YES;
}
Запись в журнал при останове ВМ:
if (action.id.match("org.libvirt.api.domain.stop"))
{
    polkit.log("action=" + action);
    polkit.log("subject=" + subject);
    return polkit.Result.YES;
}

Часть VII. Kubernetes

Kubernetes — это система для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Поддерживает основные технологии контейнеризации (Docker, Rocket) и аппаратную виртуализацию.
Основные задачи Kubernetes:
  • развертывание контейнеров и все операции для запуска необходимой конфигурации (перезапуск остановившихся контейнеров, перемещение контейнеров для выделения ресурсов на новые контейнеры и т.д.).
  • масштабирование и запуск нескольких контейнеров одновременно на большом количестве хостов.
  • балансировка множества контейнеров в процессе запуска. Для этого Kubernetes использует API, задача которого заключается в логическом группировании контейнеров.
Утилиты для создания и управления кластером Kubernetes:
  • kubectl — создание и настройка объектов в кластере;
  • kubelet — запуск контейнеров на узлах;
  • kubeadm — настройка компонентов, составляющие кластер.

Глава 55. Установка и настройка Kubernetes

Для создания управляющего или вычислительного узла, при установке дистрибутива (см. главу Установка системы) в группе Контейнеры следует соответственно отметить пункт Сервисы Kubernetes для управляющего хоста или Сервисы Kubernetes для вычислительного узла (пункт Управление контейнерами Docker, при этом будет выбран автоматически):
Установка Kubernetes при установке системы

Примечание

На этапе «Подготовка диска» рекомендуется выбрать Server KVM/Docker/LXD/Podman/CRI-O (large /var/lib/) и не создавать раздел Swap.

Примечание

В данном руководстве рассмотрен процесс разворачивания кластера с использованием docker.

55.1. Создание кластера Kubernetes

Для создания кластера необходимо несколько машин (nodes). Одна из которых будет мастером. Системные требования:
  • 2 ГБ или больше ОЗУ на машину;
  • 2 ядра процессора или больше;
  • все машины должны быть доступны по сети друг для друга;
  • все машины должны успешно разрешать имена hostname друг друга (через DNS или hosts);
  • Swap должен быть выключен.

    Примечание

    Для отключения Swap нужно выполнить команду:
    # swapoff -a
    И удалить соответствующую строку в /etc/fstab.

55.1.1. Инициализация кластера

Для инициализации кластера запустить команду (на мастере):
# kubeadm init --pod-network-cidr=10.244.0.0/16 --ignore-preflight-errors=SystemVerification
где:
  • --pod-network-cidr=10.244.0.0/16 — адрес внутренней (разворачиваемой Kubernetes) сети, данное значение рекомендуется оставить для правильной работы Flannel;
  • --ignore-preflight-errors=SystemVerification — игнорировать ошибки проверки версии docker.
Если все сделано правильно, на экране отобразится команда, позволяющая присоединить остальные ноды кластера к мастеру:
…
Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.0.201:6443 --token cgmqh4.26l6pnhqagslwvae \
    --discovery-token-ca-cert-hash \
    sha256:9571e4fde1bed9ee43ed1cba98b5c2bca5184f99f54806f1a84657d161e9f0a1
Настроить kubernetes для работы от пользователя (на мастер-ноде):
  1. Создать каталог ~/.kube:
    $ mkdir ~/.kube
    
  2. Скопировать конфигурацию:
    # cp /etc/kubernetes/admin.conf ~<пользователь>/.kube/config
    
  3. Изменить владельца конфигурационного файла:
    # chown <пользователь>: ~<пользователь>/.kube/config
    

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

Развернуть сеть (Container Network Interface), запустив команду (на мастер-ноде):
$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
В выводе будут отображены имена всех созданных ресурсов. Проверить, что всё работает:
$ kubectl get pods --namespace kube-system
NAME                               READY   STATUS    RESTARTS   AGE
coredns-74ff55c5b-5rgmk            1/1     Running   0          38m
coredns-74ff55c5b-wjq4r            1/1     Running   0          38m
etcd-master01                      1/1     Running   0          37m
kube-apiserver-master01            1/1     Running   0          37m
kube-controller-manager-master01   1/1     Running   0          37m
kube-flannel-ds-2gl6g              1/1     Running   0          92s
kube-proxy-tjmjt                   1/1     Running   0          38m
kube-scheduler-master01            1/1     Running   0          37m
coredns должны находиться в состоянии Running. Количество kube-flannel и kube-proxy зависит от общего числа нод.

55.1.3. Добавление узлов (нод) в кластер

Подключить остальные узлы (ноды) в кластер. Для этого на узле выполнить команду:
# kubeadm join <ip адрес>:<порт> --token <токен>
 --discovery-token-ca-cert-hash sha256:<хэш> --ignore-preflight-errors=SystemVerification
Данная команда была выведена при выполнении команды kubeadm init на мастер-ноде. В данном случае:
# kubeadm join 192.168.0.201:6443 --token cgmqh4.26l6pnhqagslwvae \
    --discovery-token-ca-cert-hash \
    sha256:9571e4fde1bed9ee43ed1cba98b5c2bca5184f99f54806f1a84657d161e9f0a1
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

Примечание

Получить токен, если его нет, можно выполнив команду (на мастер-ноде):
$ kubeadm token list
TOKEN                     TTL      EXPIRES                    USAGES
cgmqh4.26l6pnhqagslwvae   20h      2021-06-25T11:52:05+02:00  authentication,signing
По умолчанию, срок действия токена — 24 часа. Если требуется добавить новый узел в кластер по окончанию этого периода, можно создать новый токен:
$ kubeadm token create
Если значение параметра --discovery-token-ca-cert-hash неизвестно, его можно получить, выполнив команду (на мастер-ноде):
$ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | \
   openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'
9571e4fde1bed9ee43ed1cba98b5c2bca5184f99f54806f1a84657d161e9f0a1
Для ввода IPv6-адреса в параметр <control-plane-host>:<control-plane-port>, адрес должен быть заключен в квадратные скобки:
[fd00::101]:2073
Проверить наличие нод (на мастер-ноде):
$ kubectl get nodes
NAME       STATUS   ROLES                  AGE    VERSION
docker03   Ready    <none>                 160m   v1.20.2
master01   Ready    control-plane,master   3h3m   v1.20.2
или
$ kubectl get nodes -o wide
Информация о кластере:
$ kubectl cluster-info
Kubernetes control plane is running at https://192.168.0.201:6443
KubeDNS is running at https://192.168.0.201:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Посмотреть подробную информацию о ноде:
$ kubectl describe node docker03

55.2. Тестовый запуск nginx

Deployment — это объект Kubernetes, представляющий работающее приложение в кластере.
Создать Deployment с nginx:
$ kubectl apply -f https://k8s.io/examples/application/deployment.yaml
deployment.apps/nginx-deployment created
Создать сервис, с помощью которого можно получить доступ к приложению из внешней сети. Для этого создать файл nginx-service.yaml, со следующим содержимым:
apiVersion: v1
    kind: Service
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      type: NodePort
      ports:
      - port: 80
        targetPort: 80
      selector:
        app: nginx
Запустить новый сервис:
$ kubectl apply -f nginx-service.yaml
service/nginx created
Просмотреть порт сервиса nginx:
$ kubectl get svc nginx
NAME    TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx   NodePort   10.105.18.148   <none>        80:30723/TCP   7s
Проверить работу nginx, выполнив команду (сервер должен вернуть код 200):
curl -I <ip адрес>:<порт>
где <ip адрес> — это адрес любой из нод, а <порт> — это порт сервиса, полученный с помощью предыдущей команды. В данном кластере возможна команда:
$ curl -I 192.168.0.204:30723
HTTP/1.1 200 OK
Server: nginx/1.14.2

Глава 56. Кластер высокой доступности Kubernetes

Kubernetes предлагает два основных способа реализации HA-кластера:
  • со стековой топологией (узлы etcd размещаются вместе с узлами плоскости управления);
  • с внешней etcd-топологией (etcd работает на отдельных узлах от плоскости управления).

56.1. Стековая (составная) топология etcd

Стековая (составная) топология etcd — это топология, в которой распределенный кластер хранения данных, предоставляемый etcd, размещается на вершине кластера, образованного узлами, управляемыми kubeadm, которые запускают компоненты плоскости управления.
Каждый узел плоскости управления запускает экземпляр kube-apiserver, kube-scheduler и kube-controller-manager. Kube-apiserver предоставляется рабочим узлам с помощью балансировщика нагрузки.
Каждый узел уровня управления создает локальный etcd, и этот etcd взаимодействует только с kube-apiserver этого узла. То же самое относится к локальным экземплярам kube-controller-manager и kube-scheduler.
Эту топологию проще настроить, чем кластер с внешними узлами etcd, и проще управлять репликацией. Но если один узел выходит из строя, будут потеряны и etcd, и экземпляр уровня управления, и избыточность нарушится. Этот риск можно снизить, добавив больше узлов плоскости управления. Поэтому для HA-кластера следует запустить как минимум три сгруппированных узла плоскости управления.
Это топология используется по умолчанию в kubeadm. Локальный etcd создается автоматически на узлах плоскости управления при использовании kubeadm init и kubeadm join --control-plane.

56.2. Внешняя etcd-топология

Внешняя etcd-топология — это топология, в которой кластер распределенного хранения данных, предоставляемый etcd, является внешним по отношению к кластеру, сформированному узлами, на которых выполняются компоненты плоскости управления.
Каждый узел плоскости управления во внешней топологии etcd запускает экземпляр kube-apiserver, kube-scheduler и kube-controller-manager. И kube-apiserver предоставляется рабочим узлам с помощью балансировщика нагрузки. Однако etcd работают на отдельных хостах, и каждый хост etcd взаимодействует с kube-apiserver каждого узла плоскости управления.
Эта топология разделяет плоскость управления и элемент etcd. Таким образом обеспечивается настройка HA, при которой потеря экземпляра уровня управления или etcd оказывает меньшее влияние и не влияет на избыточность кластера в такой степени, как многослойная топология.
Но для этой топологии требуется вдвое больше хостов, чем для многослойной топологии. Для HA-кластера с этой топологией требуется как минимум три хоста для узлов плоскости управления и три хоста для узлов etcd.

56.3. Настройка HA-кластера etcd с помощью kubeadm

В данном примере рассматривается процесс создания HA-кластера etcd состоящего из трех узлов, который можно использовать в качестве внешнего etcd при использовании kubeadm для настройки кластера kubernetes.
Рекомендации:
  • три хоста, которые могут общаться друг с другом через порты 2379 и 2380;
  • на каждом хосте должны быть установлены docker, kubelet и kubeadm;
  • каждый хост должен иметь доступ к реестру образов контейнера Kubernetes (k8s.gcr.io) или выводить/извлекать требуемый образ etcd с помощью kubeadm config images list/pull;
  • между хостами должна быть настроена возможность копирования файлов, например ssh и scp.
Основная идея при таком способе настройки кластера, состоит в том, чтобы генерировать все сертификаты на одном узле и распространять только необходимые файлы на другие узлы.

Примечание

kubeadm содержит все необходимое криптографические механизмы для создания сертификатов, никаких других криптографических инструментов для данного примера не требуется.
Настройка kubernetes:
  1. Настроить kubelet в качестве диспетчера служб для etcd.
    Так как etcd был создан первым, необходимо переопределить приоритет службы, создав новый файл модуля с более высоким приоритетом, чем предоставленный kubeadm файл модуля kubelet (на каждом хосте, на котором должен быть запущен etcd):
    # cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
    [Service]
    ExecStart=
    #  Replace "systemd" with the cgroup driver of your container runtime.
    #  The default value in the kubelet is "cgroupfs".
    ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
    Restart=always
    EOF
    
    # systemctl daemon-reload
    # systemctl restart kubelet
    
    Убедиться, что kubelet запущен:
    # systemctl status kubelet
    
  2. Создать файлы конфигурации для kubeadm.
    Создать и запустить скрипт, который сгенерирует файлы конфигурации для каждого хоста. Содержимое скрипта:
    #!/bin/sh
    # HOST0, HOST1, и HOST2 - IP-адреса хостов
    export HOST0=192.168.0.201
    export HOST1=192.168.0.205
    export HOST2=192.168.0.206
    
    # Create temp directories to store files that will end up on other hosts.
    mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
    
    ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
    NAMES=("infra0" "infra1" "infra2")
    
    for i in "${!ETCDHOSTS[@]}"; do
    HOST=${ETCDHOSTS[$i]}
    NAME=${NAMES[$i]}
    cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
    apiVersion: "kubeadm.k8s.io/v1beta2"
    kind: ClusterConfiguration
    etcd:
    local:
        serverCertSANs:
        - "${HOST}"
        peerCertSANs:
        - "${HOST}"
        extraArgs:
            initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380
            initial-cluster-state: new
            name: ${NAME}
            listen-peer-urls: https://${HOST}:2380
            listen-client-urls: https://${HOST}:2379
            advertise-client-urls: https://${HOST}:2379
            initial-advertise-peer-urls: https://${HOST}:2380
    EOF
    done
    
  3. Создать центр сертификации (CA).

    Примечание

    Если у вас уже есть CA, то необходимо скопировать сертификат (crt) и ключ CA в /etc/kubernetes/pki/etcd/ca.crt и /etc/kubernetes/pki/etcd/ca.key. После этого можно перейти к следующему шагу.
    Если у вас еще нет CA, следует запустить команду на хосте $HOST0 (там, где были сгенерированы файлы конфигурации для kubeadm):
    # kubeadm init phase certs etcd-ca
    [certs] Generating "etcd/ca" certificate and key
    
    При этом будут созданы два файла: /etc/kubernetes/pki/etcd/ca.crt и /etc/kubernetes/pki/etcd/ca.key.
  4. Создать сертификаты для каждого хоста.
    Для этого создать и запустить скрипт (на хосте $HOST0):
    #!/bin/sh
    export HOST0=192.168.0.201
    export HOST1=192.168.0.205
    export HOST2=192.168.0.206
    
    kubeadm init phase certs etcd-server --config=/tmp/${HOST1}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-peer --config=/tmp/${HOST1}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST1}/kubeadmcfg.yaml
    cp -R /etc/kubernetes/pki /tmp/${HOST1}/
    # cleanup non-reusable certificates
    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
    
    kubeadm init phase certs etcd-server --config=/tmp/${HOST2}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-peer --config=/tmp/${HOST2}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST2}/kubeadmcfg.yaml
    cp -R /etc/kubernetes/pki /tmp/${HOST2}/
    find /etc/kubernetes/pki -not -name ca.crt -not -name ca.key -type f -delete
    
    kubeadm init phase certs etcd-server --config=/tmp/${HOST0}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-peer --config=/tmp/${HOST0}/kubeadmcfg.yaml
    kubeadm init phase certs etcd-healthcheck-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
    kubeadm init phase certs apiserver-etcd-client --config=/tmp/${HOST0}/kubeadmcfg.yaml
    # No need to move the certs because they are for HOST0
    
    # clean up certs that should not be copied off this host
    find /tmp/${HOST2} -name ca.key -type f -delete
    find /tmp/${HOST1} -name ca.key -type f -delete
    
  5. Скопировать сертификаты и файлы конфигурации kubeadm на хосты.
    scp /tmp/${HOST}/kubeadmcfg.yaml user@${HOST}:
    scp -r /tmp/${HOST}/pki root@${HOST}:/etc/kubernetes/
    
    В данном примере:
    # scp /tmp/192.168.0.205/kubeadmcfg.yaml user@192.168.0.205:
    # scp -r /tmp/192.168.0.205/pki root@192.168.0.205:/etc/kubernetes/
    
  6. Должны существовать следующие файлы:
    • на хосте $HOST0 (там, где были сгенерированы файлы конфигурации для kubeadm и сертификаты):
      /tmp/${HOST0}
      └── kubeadmcfg.yaml
      ---
      /etc/kubernetes/pki
      ├── apiserver-etcd-client.crt
      ├── apiserver-etcd-client.key
      └── etcd
      ├── ca.crt
      ├── ca.key
      ├── healthcheck-client.crt
      ├── healthcheck-client.key
      ├── peer.crt
      ├── peer.key
      ├── server.crt
      └── server.key
      
    • на хосте $HOST1:
      $HOME
      └── kubeadmcfg.yaml
      ---
      /etc/kubernetes/pki
      ├── apiserver-etcd-client.crt
      ├── apiserver-etcd-client.key
      └── etcd
      ├── ca.crt
      ├── healthcheck-client.crt
      ├── healthcheck-client.key
      ├── peer.crt
      ├── peer.key
      ├── server.crt
      └── server.key
      
    • на хосте $HOST2:
      $HOME
      └── kubeadmcfg.yaml
      ---
      /etc/kubernetes/pki
      ├── apiserver-etcd-client.crt
      ├── apiserver-etcd-client.key
      └── etcd
      ├── ca.crt
      ├── healthcheck-client.crt
      ├── healthcheck-client.key
      ├── peer.crt
      ├── peer.key
      ├── server.crt
      └── server.key
      
  7. Создать статические манифесты модуля.
    На каждом хосте запустить команду kubeadm, чтобы сгенерировать статический манифест для etcd:
    root@HOST0# kubeadm init phase etcd local –config=/tmp/192.168.0.201/kubeadmcfg.yaml
    [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
    
    root@HOST1# kubeadm init phase etcd local --config=/home/user/kubeadmcfg.yaml
    [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
    
    root@HOST2# kubeadm init phase etcd local --config=/home/user/kubeadmcfg.yaml
    [etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
    

Часть VIII. Настройка системы

Глава 57. Центр управления системой

57.1. Описание

Для управления настройками установленной системы вы можете воспользоваться Центром управления системой. Центр управления системой (ЦУС) представляет собой удобный интерфейс для выполнения наиболее востребованных административных задач: добавление и удаление пользователей, настройка сетевых подключений, просмотр информации о состоянии системы и т.п.
Центр управления системой состоит из нескольких независимых диалогов-модулей. Каждый модуль отвечает за настройку определённой функции или свойства системы.

57.2. Применение центра управления системой

Вы можете использовать ЦУС для разных целей, например:
  • Настройки Даты и времени (datetime);
  • Управления выключением и перезагрузкой компьютера (ahttpd-power);
  • Управления Системными службами (services);
  • Просмотра Системных журналов (logs);
  • Конфигурирования Сетевых интерфейсов (net-eth);
  • Изменения пароля Администратора системы (root) (root);
  • Создания, удаления и редактирования учётных записей Пользователей (users);
  • Настройки ограничения Использования диска (квоты) (quota).
Вы всегда можете воспользоваться кнопкой Справка. Все модули ЦУС имеют справочную информацию.

57.3. Использование веб-ориентированного центра управления системой

ЦУС имеет веб-ориентированный интерфейс, позволяющий управлять данным компьютером с любого другого компьютера сети.
Для запуска веб-ориентированного интерфейса должен быть запущен сервис ahttpd и alteratord:
systemctl enable --now ahttpd
systemctl enable --now alteratord
Работа с ЦУС может происходить из любого веб-браузера. Для начала работы необходимо перейти по адресу https://ip-адрес:8080/.
Если для сервера задан IP-адрес 192.168.0.122, то интерфейс управления будет доступен по адресу: https://192.168.0.122:8080/.

Примечание

IP-адрес сервера можно узнать, введя команду:
$ ip addr
IP-адрес будет указан после слова inet:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 60:eb:69:6c:ef:47 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.122/24 brd 192.168.0.255 scope global enp0s3
Например, тут мы видим, что на интерфейсе enp0s3 задан IP-адрес 192.168.0.122.
При запуске центра управления системой необходимо ввести в соответствующие поля имя пользователя (root) и пароль пользователя:
Вход в систему
После этого будут доступны все возможности ЦУС на той машине, к которой было произведено подключение через веб-интерфейс.
Центр управления системой
Веб-интерфейс ЦУС можно настроить (кнопка Режим эксперта), выбрав один из режимов:
  • основной режим;
  • режим эксперта.
Выбор режима влияет на количество отображаемых модулей. В режиме эксперта отображаются все модули, а в основном режиме только наиболее используемые.
Центр управления системой содержит справочную информацию по всем включённым в него модулям. Об использовании самого интерфейса системы управления можно прочитать, нажав на кнопку Справка на начальной странице центра управления системой.
Центр управления системой содержит справочную информацию по всем включённым в него модулям. Об использовании самого интерфейса системы управления можно прочитать, нажав на кнопку Справка на начальной странице центра управления системой.

Предупреждение

После работы с центром управления системой, в целях безопасности, не оставляйте открытым браузер. Обязательно выйдите, нажав на кнопку Выйти.

Примечание

Подробнее об использовании Центра управления системой можно узнать в главе Работа с центром управления системой.

Часть IX. Работа с центром управления системой

Дальнейшие разделы описывают некоторые возможности использования Альт Сервер Виртуализации, настраиваемые в ЦУС.

Важно

Эта и последующие главы рекомендуются к прочтению опытным пользователям и системным администраторам.

Глава 58. Настройка подключения к Интернету

Помимо множества различных служб, которые Альт Сервер Виртуализации может предоставлять компьютерам сети, важно определить, будет ли сервер предоставлять общий доступ в Интернет для компьютеров домена или нет. В зависимости от этого сервер можно рассматривать как:
Сервер без подключения к сети Интернет
Типичный случай — это сервер с одним сетевым интерфейсом (одной сетевой картой), который и связывает его с компьютерами локальной сети. Такой сервер называется также сервер рабочей группы.
Шлюз
В этом случае сервер обычно имеет два сетевых интерфейса (например, две сетевые карты), одна из которых служит для подключения к локальной сети, а другая — для подключения к сети Интернет.
Как для обеспечения доступа в сеть Интернет самого Альт Сервер Виртуализации, так и для настройки общего выхода в Интернет для компьютеров сети необходимо настроить подключение к Интернету на самом сервере. Альт Сервер Виртуализации поддерживает самые разные способы подключения к сети Интернет:
  • Ethernet;
  • PPTP;
  • PPPoЕ;
  • и т.д.
Для настройки подключения воспользуйтесь одним из разделов ЦУС Сеть.
Доступные разделы:
Выберите раздел, соответствующий вашему типу подключения, и преступайте к настройке.

58.1. Конфигурирование сетевых интерфейсов

Конфигурирование сетевых интерфейсов осуществляется в модуле ЦУС Ethernet-интерфейсы (пакет alterator-net-eth) из раздела Сеть:
Настройка Ethernet-интерфейсов
В модуле Ethernet-интерфейсы можно заполнить следующие поля:
  • Имя компьютера — указать сетевое имя ПЭВМ в поле для ввода имени компьютера (это общий сетевой параметр, не привязанный, к какому-либо конкретному интерфейсу). Имя компьютера, в отличие от традиционного имени хоста в Unix (hostname), не содержит названия сетевого домена;
  • Интерфейсы — выбрать доступный сетевой интерфейс, для которого будут выполняться настройки;
  • Версия протокола IP — указать в выпадающем списке версию используемого протокола IP (IPv4, IPv6) и убедиться, что пункт Включить, обеспечивающий поддержку работы протокола, отмечен;
  • Конфигурация — выбрать способ назначения IP-адресов (службы DHCP, Zeroconf, вручную);
  • IP-адреса — пул назначенных IP-адресов из поля IP, выбранные адреса можно удалить нажатием кнопки Удалить;
  • IP — ввести IP-адрес вручную и выбрать в выпадающем поле предпочтительную маску сети, затем нажать кнопку Добавить для переноса адреса в пул поля IP-адреса;
  • Шлюз по умолчанию — в поле для ввода необходимо ввести адрес шлюза, который будет использоваться сетью по умолчанию;
  • DNS-серверы — в поле для ввода необходимо ввести список предпочтительных DNS-серверов, которые будут получать информацию о доменах, выполнять маршрутизацию почты и управлять обслуживающими узлами для протоколов в домене;
  • Домены поиска — в поле для ввода необходимо ввести список предпочтительных доменов, по которым будет выполняться поиск. Если в поле Домены поиска перечислить наиболее часто используемые домены (например, domain), то можно пользоваться неполными именами машин (computer вместо computer.domain).
IP-адрес и Маска сети — обязательные параметры каждого узла IP-сети. Первый параметр – уникальный идентификатор машины, от второго напрямую зависит, к каким машинам локальной сети данная машина будет иметь доступ. Если требуется выход во внешнюю сеть, то необходимо указать параметр Шлюз по умолчанию.
В случае наличия DHCP-сервера можно все вышеперечисленные параметры получить автоматически – выбрав в списке Конфигурация пункт Использовать DHCP:
Автоматическое получение настроек от DHCP-сервера
Если в компьютере имеется несколько сетевых карт, то возможна ситуация, когда при очередной загрузке ядро присвоит имена интерфейсов (enp0s3, enp0s8) в другом порядке. В результате интерфейсы получат не свои настройки. Чтобы этого не происходило, можно привязать интерфейс к имени по его аппаратному адресу (MAC) или по местоположению на системной шине.
Дополнительно для каждого интерфейса можно настроить сетевую подсистему (NetworkManager, Etcnet), а также должен ли запускаться данный интерфейс при загрузке системы:
Выбор сетевой подсистемы

58.2. Настройка общего подключения к сети Интернет

Пользователи корпоративных сетей обычно подключаются к сети Интернет через один общий канал. Для организации совместного доступа к сети Интернет стандартными средствами поддерживаются две технологии, которые могут использоваться как по отдельности, так и совместно:
Оба способа предполагают, что соединение с Интернет компьютера, через который предполагается настроить общий выход, предварительно сконфигурировано . Сделать это можно в разделе ЦУС Сеть.

58.2.1. Прокси-сервер

Отличительной особенностью использования прокси-сервера является то, что, помимо предоставления доступа к веб-сайтам, прокси-сервер кэширует загруженные страницы, а при повторном обращении к ним — отдаёт их из своего кэша. Это может существенно снизить потребление трафика.
У прокси-сервера есть два основных режима работы:
  • прозрачный;
  • обычный.
Для работы с прокси-сервером в прозрачном режиме не потребуется специальная настройка рабочих станций. Они лишь должны использовать сервер в качестве шлюза по умолчанию. Этого можно добиться, сделав соответствующие настройки на DHCP-сервере.
Для использования прокси-сервера в обычном режиме потребуется на каждом клиенте в настройках браузера указать данные прокси-сервера (IP-адрес и порт).
Преимуществом обычного режима работы, требующего перенастройки программ локальной сети, является возможность производить аутентификацию пользователей и контролировать их доступ во внешнюю сеть.
В различных браузерах местоположение формы настройки на прокси-сервер различное. Например, в браузере Firefox она доступна через меню ПравкаНастройкираздел Дополнительновкладка Сеть+кнопка Настроить… напротив текста «Настройка параметров соединения Firefox с Интернетом». Здесь следует выбрать Ручная настройка сервиса прокси и указать IP-адрес и порт прокси-сервера.
По умолчанию прокси-сервер не предоставляет доступ в Интернет никому кроме себя самого. Список сетей, обслуживаемых прокси-сервером можно изменить, нажав на кнопку «Разрешённые сети…» в модуле ЦУС Прокси-сервер (пакет alterator-squid) из раздела Серверы.
Модуль Прокси-сервер
Для того чтобы включить аутентификацию пользователей и контролировать их доступ во внешнюю сеть, необходимо выбрать обычный режим проксирования и способ аутентификации, отличный от Без аутентификации:
Модуль Настройка аутентификации пользователей
Прокси-сервер принимает запросы из локальной сети и, по мере необходимости, передаёт их во внешнюю сеть. Поступление запроса ожидается на определённом порту, который по умолчанию имеет стандартный номер 3128. Если по каким-то причинам не желательно использовать данный порт, то можно поменять его значение на любое другое.
Перед тем как выполнить перенаправление запроса, прокси-сервер проверяет принадлежность сетевого адрес узла, с которого запрос был отправлен к группе внутренних сетевых адресов. Для того чтобы запросы, отправленные из локальной сети, обрабатывались прокси-сервером, необходимо добавить соответствующую группу адресов (адрес подсети и адресную маску) в список внутренних сетей в разделе Разрешённые сети:
Настройка списка внутренних сетей
Вторым условием передачи запроса является принадлежность целевого порта к разрешённому диапазону. Посмотреть и отредактировать список разрешённых целевых портов можно в разделе Разрешённые протоколы:
Настройка списка разрешённых целевых портов
Прокси-сервер позволяет вести статистику посещений страниц в Интернете. Она доступна в модуле ЦУС Прокси-сервер (пакет alterator-squidmill) в разделе Статистика. Основное предназначение статистики — просмотр отчёта об объёме полученных из Интернета данных в привязке к пользователям (если включена аутентификация) или к IP-адресам клиентов.

Примечание

Статистика не собирается по умолчанию. Включить её сбор следует в модуле ЦУС Прокси-сервер (раздел Статистика). Для этого отметьте Включить сбор данных прокси-сервера и нажмите кнопку Применить.

Примечание

Для учёта пользователей в статистике нужно добавить хотя бы одно правило. Самое очевидное — запрет не аутентифицированных пользователей. Только после этого в статистике начнут показываться пользователи.

58.2.2. NAT

NAT (Network Address Translation, преобразование сетевых адресов) — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Таким образом, компьютеры локальной сети, имеющие IP-адреса, зарезервированные для использования исключительно в локальных сетях, могут использовать общий канал доступа к Интернет (общий внешний IP-адрес). При этом на компьютере-шлюзе, непосредственно подключённом к Интернет, выполняется преобразование адресов.
Настройка NAT осуществляется в модуле ЦУС Внешние сети (пакет alterator-net-iptables) из раздела Брандмауэр. Для минимальной настройки достаточно выбрать режим работы Шлюз (NAT), отметить правильный внешний сетевой интерфейс и нажать на кнопку Применить.
Настройка NAT

58.3. Автоматическое присвоение IP-адресов (DHCP-сервер)

DHCP (Dynamic Host Configuration Protocol) — протокол, позволяющий клиенту самостоятельно получить IP-адрес из зарезервированного диапазона адресов, а также дополнительную информацию о локальной сети (DNS-сервер сети, домен поиска, шлюз по умолчанию). Это облегчает администрирование клиентских машин, избавляя администратора домена от необходимости вручную настраивать сетевые интерфейсы на компьютерах локальной сети.
Чтобы настраивать DHCP-сервер, на машине должен быть хотя бы один статически сконфигурированный Ethernet-интерфейс.
Настройка DHCP-сервера осуществляется в модуле ЦУС DHCP-сервер (пакет alterator-dhcp) из раздела Серверы.
Для включения DHCP-сервера необходимо установить флажок Включить службу DHCP, указать начальный и конечный IP-адрес, а также шлюз по умолчанию (обычно, это IP-адрес сервера на сетевом интерфейсе, обслуживающем локальную сеть).
Настройка DHCP-сервера
Теперь при включении любой клиентской машины с настройкой получение ip и dns автоматически будет присваиваться шлюз 192.168.8.250, DNS 192.168.8.251 и адреса начиная с 192.168.8.50 по порядку включения до 192.168.8.60.
Иногда бывает полезно выдавать клиенту один и тот же IP-адрес независимо от момента обращения. В этом случае он определяется по аппаратному адресу (MAC-адресу) сетевой карты клиента. Для добавления своих значений в таблицу соответствия статических адресов введите IP-адрес и соответствующий ему MAC-адрес и нажмите кнопку Добавить.
Привязка IP-адреса к MAC-адресу
Выданные IP-адреса можно увидеть в списке Текущие динамически выданные адреса. Здесь также имеется возможность зафиксировать выданные адреса, за данными компьютерами. Для этого необходимо отметить хост, за которым нужно закрепить IP-адрес и нажать кнопку Зафиксировать адрес для выбранных компьютеров.
Список динамически выданных адресов
За дополнительной информацией по настройке обращайтесь к встроенной справке модуля ЦУС.

Глава 59. Доступ к службам сервера из сети Интернет

59.1. Внешние сети

Сервер предоставляет возможность организовать доступ к своим службам извне. Например, можно предоставить доступ к корпоративному веб-сайту из сети Интернет. Для обеспечения такой возможности необходимо разрешить входящие соединения на внешних интерфейсах. По умолчанию такие соединения блокируются.
Для разрешения внешних и внутренних входящих соединений предусмотрен раздел ЦУС Брандмауэр. В списке Разрешить входящие соединения на внешних интерфейсах модуля Внешние сети (пакет alterator-net-iptables) перечислены наиболее часто используемые службы, отметив которые, вы делаете их доступными для соединений на внешних сетевых интерфейсах. Если вы хотите предоставить доступ к службе, отсутствующей в списке, задайте используемые этой службой порты в соответствующих полях.
Настройки модуля Внешние сети
Можно выбрать один из двух режимов работы:
  • Роутер. В этом режиме перенаправление пакетов между сетевыми интерфейсами происходит без трансляции сетевых адресов.
  • Шлюз (NAT). В этом режиме будет настроена трансляция сетевых адресов (NAT) при перенаправлении пакетов на внешние интерфейсы. Использование этого режима имеет смысл, если у вас настроен, по крайней мере, один внешний и один внутренний интерфейс.

Примечание

В любом режиме включено только перенаправление пакетов с внутренних интерфейсов. Перенаправление пакетов с внешних интерфейсов всегда выключено.

Примечание

Все внутренние интерфейсы открыты для любых входящих соединений.
За дополнительной информацией по настройке обращайтесь к встроенной справке модуля ЦУС.

59.2. Список блокируемых хостов

Модуль ЦУС Список блокируемых хостов (пакет alterator-net-bl) предназначен для блокирования любого трафика с указанными узлами. Данный модуль позволяет блокировать любой сетевой трафик с указанных в списке узлов (входящий, исходящий и пересылаемый).
Блокирование трафика с указанных в списке узлов начинается после установки флажка Использовать чёрный список.
Список блокируемых хостов
Для добавления блокируемого узла необходимо ввести IP-адрес в поле Добавить IP адрес сети или хоста и нажать кнопку Добавить.
Для удаления узла из списка выберите его и нажмите кнопку Удалить.

Глава 60. Статистика

60.1. Сетевой трафик

Все входящие и исходящие с сервера сетевые пакеты могут подсчитываться, и выводится по запросу для анализа.
Модуль Сетевой трафик (пакет alterator-ulogd) из раздела Статистика предназначен для просмотра статистики входящих и исходящих с сервера сетевых пакетов. Данный модуль позволяет оценить итоговый объём полученных и переданных данных за всё время работы сервера, за определённый период времени и по каждой службе отдельно.
Для включения сбора данных необходимо установить флажок Включить сбор данных, и нажать кнопку Применить.
Веб-интерфейс модуля Сетевой трафик
Для просмотра статистики укажите период (в виде начальной и конечной дат). Дата указывается в формате YYYY-MM-DD (год-месяц-день) или выбирается из календаря справа от поля ввода даты. Из списка доступных сетевых интерфейсов необходимо выбрать интересующий и нажать на кнопку Показать.
Просмотр статистики входящих и исходящих пакетов
Трафик на указанном интерфейсе за заданный период показывается в виде:
  • служба (название протокола);
  • входящий трафик в килобайтах;
  • исходящий трафик в килобайтах.

60.2. Прокси-сервер

Пересылка каждого запроса во внешнюю сеть фиксируется прокси-сервером в специальном журнале. На основании этих данных автоматически формируются отчёты о статистике использования ресурсов сети, в том числе потраченного времени и количества переданных данных (трафика).
Статистика не собирается по умолчанию. Для включения сбора статистики и просмотра отчётов воспользуйтесь модулем ЦУС Прокси-сервер (пакет alterator-squidmill) из раздела Статистика.
Веб-интерфейс модуля Прокси-сервер
Для включения сбора статистики прокси-сервера установите флажок Включить сбор данных прокси-сервера.
В том случае, если на прокси-сервере производилась аутентификация пользователей, отчёты будут содержать данные об обращениях каждого пользователя. Иначе отчёты будут формироваться только на основании адресов локальной сети.
Для показа отчёта задайте условия фильтра и нажмите кнопку Показать. Данные в таблице будут отсортированы по объёму трафика в порядке убывания.
Для учёта пользователей в статистике необходимо добавить хотя бы одно правило. Самое очевидное правило — запрет неаутентифиуцированных пользователей. Только после этого в статистике начнут показываться пользователи.

Глава 61. Обслуживание сервера

Для безотказной работы всего домена очень важно следить за корректной работой его центрального звена — сервера под управлением Альт Сервер Виртуализации. Регулярный мониторинг состояния сервера, своевременное резервное копирование, обновление установленного ПО являются важной частью комплекса работ по обслуживанию сервера.

61.1. Мониторинг состояния системы

Для обеспечения бесперебойной работы сервера крайне важно производить постоянный мониторинг его состояния. Все события, происходящие с сервером, записываются в журналы, анализ которых помогает избежать сбоев в работе сервера и предоставляет возможность разобраться в причинах некорректной работы сервера.
Для просмотра журналов предназначен модуль ЦУС Системные журналы (пакет alterator-logs) из раздела Система). Интерфейс позволяет просмотреть различные типы журналов с возможностью перехода к более старым или более новым записям.
Различные журналы могут быть выбраны из списка Журналы.
Веб-интерфейс модуля Системные журналы
Каждый журнал может содержать довольно большое количество сообщений. Уменьшить либо увеличить количество выводимых строк можно, выбрав нужное значение в списке Показывать.

61.2. Системные службы

Для изменения состояния служб можно использовать модуль ЦУС Системные службы (пакет alterator-services) из раздела Система. Интерфейс позволяет изменять текущее состояние службы и, если необходимо, применить опцию запуска службы при загрузке системы.
Веб-интерфейс модуля Системные службы
После выбора названия службы из списка отображается описание данной службы, а также текущее состояние: Работает/Остановлена/Неизвестно.

61.3. Резервное копирование

Резервное копирование является важной частью работ по поддержанию работоспособности сервера и всего домена. Так как сервер является критичной частью сети, производите регулярное резервное копирование. При возникновении нештатных ситуаций, например, выхода из строя оборудования, вы сможете восстановить работоспособное состояние сервера из резервной копии.
Ниже перечислены модули, с помощью которых можно настроить резервное копирование.
План резервного копирования и дополнительные параметры настраиваются в модуле ЦУС Резервное копирование. Этот же модуль может использоваться и для восстановления данных.
Bacula — кроссплатформенное клиент-серверное программное обеспечение, позволяющее управлять резервным копированием, восстановлением, и проверкой данных по сети для компьютеров и операционных систем различных типов.
Функционально Bacula состоит из компонентов (служб), каждая из которых реализует определенные функции.
Взаимодействие служб Bacula
Структура:
  • Bacula Director — процесс управляющий системой в целом (управление, планирование, восстановление резервных копий).
  • Storage Director — запускается на сервере, отвечающем за «физическое» хранение данных.
  • File Director — сервис, запускаемый на каждом из клиентов.
  • Bconsole — консоль управления.
Копирование, восстановление, верификация и административные функции оформляются в виде задания (Job). В задании задается набор файлов (FileSet), который нужно копировать, компьютер (Client), с которого надо копировать файлы, время копирования (Schedule), пул (Pool), куда копировать и дополнительные директивы.
Задания на копирование данных определяются в конфигурационном файле Директора (Director) и там же определяется график автоматического запуска этих заданий. Директор выполняется постоянно как демон в фоновом режиме и запускает задания на копирование в соответствии с графиком. Администратор (пользователь) может также вручную запустить эти задания в любое время, используя Службу Консоль.
Файлы настройки Bacula форматированы на основе ресурсов, включающих директивы, обрамленные фигурными скобками "{}". Каждый компонент Bacula имеет индивидуальный файл в каталоге /etc/bacula.
Различные компоненты Bacula должны авторизовывать себя друг для друга. Это решается использованием директивы password. Например, пароль в ресурсе Storage файла /etc/bacula/bacula-dir.conf должен соответствовать паролю ресурса Director файла /etc/bacula/bacula-sd.conf.
В дистрибутиве установленная из пакетов Bacula уже настроена для резервного копирования конфигурации ОС. Основным диспетчером резервного копирования является Bacula Director. Дополнительно его настраивать не нужно.
Для того чтобы начать резервное копирование самого сервера или рабочей станции, необходимо выполнить следующие шаги:
  • перейти в раздел Сервер резервного копированияКлиенты
    Клиенты
  • указать имя узла (для сервера это будет localhost) и операционную систему. Нажать кнопку Создать;
  • указать пароль для клиента и включаемые и исключаемые каталоги;
  • нажать на кнопку Сохранить параметры;
  • нажать ссылку "Конфигурационный файл клиента" и сохраните файл <имя узла>-fd.bin на локальном компьютере;
  • скопировать полученный файл на рабочую станцию или сервер. Под Linux этот файл нужно сохранить под именем /etc/bacula/bacula-fd.conf;
  • запустить на компьютере, где создаётся резервная копия, службу bacula-fd (в дистрибутиве Альт Рабочая станция пакет bacula-client).

Примечание

Для клиента под управлением ОС Linux по умолчанию создаётся резервная копия всей файловой системы, кроме каталогов с временными и служебными файлами: /dev, /.fsck, /.journal, /media, /mnt, /opt, /proc, /srv, /sys, и /tmp.
В разделе Сервер резервного копированияРасписание указывается время проведения инкрементного резервного копирования для каждого клиента. Удостоверьтесь, что в это время на клиенте служба bacula-fd запущена. В этом же разделе можно отключить резервное копирование для выбранных клиентов.
Расписание резервного копирования
Модуль Архив (раздел Сервер резервного копирования) для выбранного клиента (выбирается из списка Клиенты) позволяет запустить создание резервной копии вне расписания, удалить все резервные копии или восстановить данные этого клиента.
Архив
Расширенные параметры восстановления позволяют задать целевой каталог восстановления.
Этот модуль также позволяет:
  • посмотреть общую информацию о доступном месте на диске;
  • посмотреть состояние и размер архива для каждого клиента;
  • принудительно запустить создание резервной копии;
  • удалить резервную копию клиента;
  • восстановить файл или каталог на выбранную дату.

61.4. Обновление системы

После установки системы крайне важно следить за обновлениями ПО. Обновления для Альт Сервер Виртуализации могут содержать как исправления, связанные с безопасностью, так и новый функционал или просто улучшение и ускорение алгоритмов. В любом случае настоятельно рекомендуется регулярно обновлять систему для повышения надёжности работы сервера.
Для автоматизации процесса установки обновлений предусмотрен модуль ЦУС Обновление системы (пакет alterator-updates) из раздела Система. Здесь можно включить автоматическое обновление через Интернет с одного из предлагаемых серверов или задать собственные настройки.
Модуль Обновление системы
Источник обновлений указывается явно (при выбранном режиме Обновлять систему автоматически из сети Интернет) или вычисляется автоматически (при выбранном режиме Обновление системы управляемое сервером и наличии в локальной сети настроенного сервера обновлений).
Процесс обновления системы будет запускаться автоматически согласно заданному расписанию.

61.5. Обновление систем, не имеющих выхода в Интернет

Для систем, не имеющих прямого выхода в Интернет, рекомендуется установка отдельного сервера обновлений на базе ОС Альт Сервер Виртуализации, находящегося вне защищенного контура и организация ограниченного доступа к этому серверу.
Модуль ЦУС Сервер обновлений (пакет alterator-mirror) из раздела Серверы предназначен для зеркалирования репозиториев и публикации их для обновлений рабочих станций и серверов.
Сервер обновлений — технология, позволяющая настроить автоматическое обновление программного обеспечения, установленного на клиентских машинах (рабочих местах), работающих под управлением Альт Рабочая станция.
По умолчанию локальное зеркало репозитория находится в /srv/public/mirror. Для того чтобы зеркалирование происходило в другую папку, необходимо эту папку примонтировать в папку /srv/public/mirror. Для этого в файл /etc/fstab следует вписать строку:
/media/disk/localrepo /srv/public/mirror none rw,bind,auto 0 0
где /media/disk/localrepo — папка-хранилище локального репозитория.
Настройка сервера обновлений
На странице модуля можно выбрать, как часто выполнять закачку пакетов, можно выставить время, когда начинать зеркалирование.
Здесь также можно выбрать репозитории, локальные срезы которых необходимы. При нажатии на название репозитория, появляются настройки этого репозитория. Необходимо выбрать источник (сайт, откуда будет скачиваться репозиторий), архитектуру процессора (если их несколько, то стоит выбрать соответствующие).
Настройки репозитория
Сервер обновлений предоставляет возможность автоматически настроить обновление клиентских машин в нужном режиме:
Локальное зеркало репозитория
В этом режиме на сервере создаётся копия удалённого репозитория, доступная клиентским машинам по протоколу FTP. Загрузка ПО клиентскими машинами производится с локального сервера. Наличие на локальном сервере зеркала репозитория при большом количестве машин в сети позволяет существенно сэкономить трафик.
Публикация репозитория
В этом случае реального зеркалирования (загрузки пакетов) не происходит. Публикуется URL внешнего сервера, содержащего репозиторий. Такая публикация позволяет клиентским машинам автоматически настроить свои менеджеры пакетов на использование внешнего сервера. Загрузка ПО клиентскими машинами производится с внешнего сервера.
Здесь также можно указать имена каталогов и файлов, которые будут исключены из синхронизации, что позволит уменьшить размер скачиваемых файлов и занимаемое репозиторием место на диске. Например, не скачивать пакеты с исходным кодом и пакеты с отладочной информацией:
SRPMS
*-debuginfo-*
Шаблоны указываются по одному в отдельной строке. Символ «*» используется для подстановки любого количества символов.
Настройка локального репозитория заканчивается нажатием на кнопку Применить.
Далее необходимо отредактировать файл /etc/httpd2/conf/extra-available/Directory_html_default.conf, изменив следующие строки:
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
Этим серверу apache будет разрешено обрабатывать символические ссылки.
Перезапустить веб-сервер apache:
# service httpd2 restart
Перейти в папку веб-сервера:
cd /var/www/html
Создать здесь символическую ссылку на репозиторий:
ln -s /srv/public/mirror mirror
На клиентских машинах необходимо настроить репозитории. Для этого необходимо запустить Synaptic, в параметрах выбрать репозитории. И далее настроить URL доступных репозиториев:
http://<ваш ip>/mirror/
Со стороны клиентских машин на них необходимо настроить модуль Обновление системы, отметив в нём Обновление системы управляемое сервером.

61.6. Локальные учётные записи

Модуль Локальные учётные записи (пакет alterator-users) из раздела Пользователи предназначен для администрирования системных пользователей.
Веб-интерфейс модуля alterator-users
Для создания новой учётной записи необходимо ввести имя новой учётной записи и нажать кнопку Создать, после чего имя отобразится в списке слева.
Для дополнительных настроек необходимо выделить добавленное имя, либо, если необходимо изменить существующую учётную запись, выбрать её из списка.

61.7. Администратор системы

В модуле Администратор системы (пакет alterator-root) из раздела Пользователи можно изменить пароль суперпользователя (root), заданный при начальной настройке системы.
В данном модуле (только в веб-интерфейсе) можно добавить публичную часть ключа RSA или DSA для доступа к серверу по протоколу SSH.
Веб-интерфейс модуля Администратор системы

61.8. Дата и время

В модуле Дата и время (пакет alterator-datetime) из раздела Система можно изменить дату и время на сервере, сменить часовой пояс, а также настроить автоматическую синхронизацию часов на самом сервере по протоколу NTP и предоставление точного времени по этому протоколу для рабочих станций локальной сети.
Веб-интерфейс модуля Дата и время
Системное время зависит от следующих факторов:
  • часы в BIOS — часы, встроенные в компьютер. Они работают, даже если он выключен;
  • системное время — часы в ядре операционной системы. Во время работы системы все процессы пользуются именно этими часами;
  • часовые пояса — регионы Земли, в каждом из которых принято единое местное время.
При запуске системы происходит активация системных часов и их синхронизация с аппаратными, кроме того, в определённых случаях учитывается значение часового пояса. При завершении работы системы происходит обратный процесс.
Если настроена синхронизация времени с NTP-сервером, то сервер сможет сам работать как сервер точного времени. Для этого достаточно отметить соответствующий пункт Работать как NTP-сервер.

61.9. Ограничение использования диска

Модуль Использование диска (пакет alterator-quota) в разделе Пользователи позволяет ограничить использование дискового пространства пользователями, заведёнными на сервере в модуле Пользователи.
Веб-интерфейс модуля Использование диска
Модуль позволяет задать ограничения (квоты) для пользователя при использовании определённого раздела диска. Ограничить можно как суммарное количество килобайт, занятых файлами пользователя, так и количество этих файлов.
Для управления квотами файловая система должна быть подключена с параметрами usrquota, grpquota. Для этого следует выбрать нужный раздел в списке Файловая система и установить отметку в поле Включено:
Задание ограничений для пользователя user на раздел /home
Для того чтобы задать ограничения для пользователя, необходимо выбрать пользователя в списке Пользователь, установить ограничения и нажать кнопку Применить.
При задании ограничений различают жёсткие и мягкие ограничения:
  • Мягкое ограничение: нижняя граница ограничения, которая может быть временно превышена. Временное ограничение — одна неделя.
  • Жёсткое ограничение: использование диска, которое не может быть превышено ни при каких условиях.
Значение 0 при задании ограничений означает отсутствие ограничений.

61.10. Выключение и перезагрузка компьютера

Иногда, в целях обслуживания или по организационным причинам необходимо корректно выключить или перезагрузить сервер. Для этого можно воспользоваться модулем ЦУС Выключение компьютера (пакет alterator-ahttpd-power) в разделе Система.
Веб-интерфейс модуля Выключение компьютера
Модуль Выключение компьютера позволяет:
  • выключить компьютер;
  • перезагрузить компьютер;
  • приостановить работу компьютера;
  • погрузить компьютер в сон.
Возможна настройка ежедневного применения данных действий в заданное время.
Так как выключение и перезагрузка — критичные для функционирования компьютера операции, то по умолчанию настройка выставлена в значение Продолжить работу. Для выключения, перезагрузки или перехода в энергосберегающие режимы нужно отметить соответствующий пункт и нажать Применить.
Для ежедневного автоматического выключения компьютера, перезагрузки, а также перехода в энергосберегающие режимы необходимо отметить соответствующий пункт и задать желаемое время. Например, для выключения компьютера следует отметить пункт Выключать компьютер каждый день в, задать время выключения в поле ввода слева от этого флажка и нажать кнопку Применить.

Примечание

Для возможности настройки оповещений на e-mail, должен быть установлен пакет state-change-notify-postfix:
# apt-get install state-change-notify-postfix
Для настройки оповещений необходимо отметить пункт При изменении состояния системы отправлять электронное письмо по адресу, ввести e-mail адрес и нажать кнопку Применить:
Веб-интерфейс модуля Выключение компьютера. Настройка оповещений
По указанному адресу, при изменении состоянии системы будут приходить электронные письма. Например, при включении компьютера, содержание письма будет следующее:
Tue Jun 16 11:46:59 EET 2020: The server.test.alt is about to start.
При выключении:
Tue Jun 16 12:27:02 EET 2020: The server.test.alt is about to shutdown.
Кнопка Сбросить возвращает сделанный выбор к безопасному значению по умолчанию: Продолжить работу, перечитывает расписания и выставляет отметки для ежедневного автоматического действия в соответствии с прочитанным.

Глава 62. Прочие возможности ЦУС

Возможности Альт Сервер Виртуализации не ограничиваются только теми, что были описаны выше. Вы всегда можете поискать другие модули, предоставляющие прочие возможности для настройки системы в веб-интерфейсе.
Установленные пакеты, которые относятся к ЦУС, можно посмотреть, выполнив команду:
rpm -qa | grep alterator*
Прочие пакеты для ЦУС можно найти, выполнив команду:
apt-cache search alterator*
Модули можно дополнительно загружать и удалять как обычные программы:
# apt-get install alterator-net-openvpn
# apt-get remove alterator-net-openvpn

Глава 63. Права доступа к модулям

Администратор системы (root) имеет доступ ко всем модулям, установленным в системе, и может назначать права доступа для пользователей к определенным модулям.
Для разрешения доступа пользователю к конкретному модулю, администратору в веб-интерфейсе ЦУС необходимо выбрать нужный модуль и нажать ссылку Параметры доступа к модулю, расположенную в нижней части окна модуля:
Ссылка Параметры доступа к модулю
В открывшемся окне, в списке Новый пользователь необходимо выбрать пользователя, который получит доступ к данному модулю, и нажать кнопку Добавить.
Параметры доступа к модулю
Для сохранения настроек необходимо перезапустить HTTP-сервер, для этого достаточно нажать кнопку Перезапустить HTTP-сервер.
Для удаления доступа пользователя к определенному модулю, администратору, в окне этого модуля необходимо нажать ссылку Параметры доступа к модулю, в открывшемся окне в списке пользователей которым разрешен доступ, должен выбрать пользователя, нажать кнопку Удалить и перезапустить HTTP-сервер.
Системный пользователь, пройдя процедуру аутентификации, может просматривать и вызывать модули, к которым он имеет доступ.

Часть X.  Установка пакетов для опытных пользователей

Введение

В современных системах на базе Linux существует огромное число общих ресурсов: разделяемых библиотек, содержащих стандартные функции, исполняемые файлы, сценарии и стандартные утилиты и т.д. Этими общими ресурсами пользуются сразу несколько программ. Удаление или изменение версии одного из составляющих систему компонентов может повлечь неработоспособность других, связанных с ним компонентов, или может привести к выводу из строя всей системы. В контексте системного администрирования проблемы такого рода называют нарушением целостности системы. Задача администратора — обеспечить наличие в системе согласованных версий всех необходимых программных компонентов (обеспечение целостности системы).
Для установки, удаления и обновления программ, а также поддержания целостности системы в Linux в первую очередь стали использоваться программы менеджеры пакетов (например, такие, как rpm). С точки зрения менеджера пакетов программное обеспечение представляет собой набор компонентов — программных пакетов. Пакеты содержат в себе набор исполняемых программ и вспомогательных файлов, необходимых для корректной работы программного обеспечения. Менеджеры пакетов облегчают установку программ: они позволяют проверить наличие необходимого для работы устанавливаемой программы компонента подходящей версии непосредственно в момент установки. Менеджеры пакетов производят необходимые процедуры для регистрации программы во всех операционных средах пользователя: сразу после установки программа становится доступна пользователю из командной строки и появляется, если это было предусмотрено, в меню приложений всех графических оболочек.
Часто компоненты, используемые различными программами, выделяют в отдельные пакеты и помечают, что для работы ПО, предоставляемого пакетом A, необходимо установить пакет B. В таком случае говорят, что пакет A зависит от пакета B или между пакетами A и B существует зависимость.
Отслеживание зависимостей между такими пакетами представляет собой важную задачу для любого дистрибутива. Некоторые компоненты пакетов могут быть взаимозаменяемыми, т.е. может обнаружиться несколько пакетов, предлагающих затребованный ресурс.
Ещё более сложной является задача контроля целостности и непротиворечивости установленного в системе ПО. Представим, что некие программы A и B требуют наличия в системе компонентов C версии 1.0. Обновление версии пакета A, требующее обновления компонентов C до новой версии (например, до версии 2.0, использующей новый интерфейс доступа), влечёт за собой обязательное обновление и программы B.
На практике менеджеры пакетов оказались неспособны эффективно устранить нарушения целостности системы и предотвратить все коллизии при установке или удалении программ. Особенно остро этот недостаток сказался на обновлении систем из централизованного репозитория, в котором пакеты непрерывно обновляются, дробятся на более мелкие и т.п. Именно этот недостаток стимулировал создание систем управления программными пакетами и поддержания целостности ОС.
Для автоматизации и контроля описанных выше процессов стала применяться Усовершенствованная система управления программными пакетами APT (от англ. Advanced Packaging Tool). Автоматизация и контроль достигаются путём создания одного или нескольких внешних репозиториев. В них хранятся доступные для установки пакеты программ.
В распоряжении APT находятся две базы данных: одна описывает установленные в системе пакеты, вторая — внешний репозиторий. APT отслеживает целостность установленной системы и, в случае обнаружения противоречий в зависимостях пакетов, разрешает конфликты, находит пути их корректного устранения, руководствуясь сведениями из внешних репозиториев.
Система APT состоит из нескольких утилит. Чаще всего используется утилита управления пакетами apt-get. Она автоматически определяет зависимости между пакетами и строго следит за её соблюдением при выполнении любой из следующих операций: установка, удаление или обновление пакетов.

Глава 64. Источники программ (репозитории)

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

Важно

Для одновременного подключения нескольких репозиториев необходимо отслеживать их совместимость друг с другом, т.е. их пакетная база должна отражать один определённый этап разработки. Совместное использование репозиториев, относящихся к разным дистрибутивам, или смешивание стабильного репозитория с нестабильной веткой разработки (Sisyphus) может привести к различным неожиданностям и трудностям при обновлении пакетов.
APT осуществляет взаимодействие с репозиториями при помощи различных протоколов доступа. Наиболее популярные — HTTP и FTP.
Для того чтобы APT мог использовать тот или иной репозиторий, информацию о нём необходимо поместить в файл /etc/apt/sources.list, либо в любой файл .list (например, mysources.list) в каталоге /etc/apt/sources.list.d/. Описания репозиториев заносятся в эти файлы в следующем виде:
rpm [подпись] метод:путь база название
rpm-src [подпись] метод:путь база название
Здесь:
  • rpm или rpm-src — тип репозитория (скомпилированные программы или исходные тексты);
  • [подпись] — необязательная строка-указатель на электронную подпись разработчиков. Наличие этого поля подразумевает, что каждый пакет из данного репозитория должен быть подписан соответствующей электронной подписью. Подписи описываются в файле /etc/apt/vendor.list;
  • метод — способ доступа к репозиторию: ftp, http, file, rsh, ssh, cdrom, copy;
  • путь — путь к репозиторию в терминах выбранного метода;
  • база — относительный путь к базе данных репозитория;
  • название — название репозитория.
Непосредственно после установки дистрибутива Альт Сервер Виртуализации в файлах /etc/apt/sources.list.d/*.list обычно указывается интернет-репозиторий, совместимый с установленным дистрибутивом.
После редактирования списка репозиториев в sources.list, необходимо обновить локальную базу данных APT о доступных пакетах. Это делается командой apt-get update.
Если в sources.list присутствует репозиторий, содержимое которого может изменяться (например, постоянно разрабатываемый репозиторий или репозиторий обновлений по безопасности), то прежде чем работать с APT, необходимо синхронизировать локальную базу данных с удалённым сервером командой apt-get update. Локальная база данных создаётся заново при каждом изменении в репозитории: добавлении, удалении или переименовании пакета.
При установке определённого пакета APT производит поиск самой новой версии этого пакета во всех известных ему репозиториях вне зависимости от способа доступа к ним. Так, если в репозитории, доступном в сети Интернет, обнаружена более новая в сравнении с компакт-диском версия программы, то APT начнёт загружать соответствующий пакет из сети Интернет. Поэтому, если подключение к сети Интернет отсутствует или ограничено низкой пропускной способностью канала или высокой стоимостью, то следует закомментировать строчки (добавить в начало строки символ #) в /etc/apt/sources.list, относящиеся к ресурсам в сети Интернет.

64.1. Редактирование репозиториев

64.1.1. Скрипт apt-repo

Для редактирования репозиториев можно воспользоваться скриптом apt-repo:
  • просмотреть список активных репозиториев:
    apt-repo
    
  • добавить репозиторий в список активных репозиториев:
    apt-repo add репозиторий
    
  • удалить или выключить репозиторий:
    apt-repo rm репозиторий
    
  • обновить информацию о репозиториях:
    apt-repo update
    
  • справка о команде apt-repo:
    man apt-repo
    
    или
    apt-repo --help
    

Примечание

Для выполнения большинства команд необходимы права администратора.
Типичный пример использования: удалить все источники и добавить стандартный репозиторий P9 (архитектура выбирается автоматически):
# apt-repo rm all
# apt-repo add p9

64.1.2. Скрипт apt-cdrom

Для добавления в sources.list репозитория на компакт-диске в APT предусмотрена специальная утилита — apt-cdrom. Чтобы добавить запись о репозитории на компакт-диске, достаточно вставить диск в привод и выполнить команду apt-cdrom add. После этого в sources.list появится запись о подключённом диске примерно такого вида:
rpm cdrom:[ALT Server V x86_64]/ ALTLinux main

Важно

Если при выполнении команды apt-cdrom add, вы получаете ошибку:
Не найдена точка монтирования /media/ALTLinux/ диска
Необходимо:
  • в файл /etc/fstab добавить строку:
    /dev/sr0 /media/ALTLinux udf,iso9660     ro,noauto,user,utf8,nofail,comment=x-gvfs-show  0 0
    
  • создать каталог для монтирования:
    # mkdir /media/ALTLinux
    
  • затем использовать команду добавления носителя:
    # apt-cdrom add
    

64.1.3. Добавление репозиториев вручную

Для изменения списка репозиториев можно отредактировать в любом текстовом редакторе файлы из каталога /etc/apt/sources.list.d/.

Примечание

Для изменения этих файлов необходимы права администратора.
В файле alt.list может содержаться такая информация:
# ftp.altlinux.org (ALT Linux, Moscow)

# ALT Linux Platform 9
#rpm [p9] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch x86_64 classic
#rpm [p9] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch x86_64-i586 classic
#rpm [p9] ftp://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch noarch classic

rpm [p9] http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch x86_64 classic
rpm [p9] http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch x86_64-i586 classic
rpm [p9] http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch noarch classic
По сути, каждая строчка соответствует некому репозиторию. Не активные репозитории — строки, начинающиеся со знака #. Для добавления нового репозитория, достаточно дописать его в этот или другой файл.
После обновления списка репозиториев следует обновить информацию о них (выполнить команду apt-get update или apt-repo update).

Глава 65. Поиск пакетов

Если точное название пакета неизвестно, то для его поиска можно воспользоваться утилитой apt-cache. Данная утилита позволяет искать пакет не только по имени, но и по его описанию.
Команда apt-cache search подстрока позволяет найти все пакеты, в именах или описании которых присутствует указанная подстрока. Например:
$ apt-cache search dictionary
stardict-wn - GCIDE - The Collaborative International Dictionary of English
firefox-ru - Russian (RU) Language Pack for Firefox
gnome-dictionary-applet - GNOME panel applet for gnome-dictionary
gnome-utils - Utilities for the GNOME 2.0 desktop
libgdict - GNOME Dictionary Library.
stardict-mueller7 - V.K. Mueller English-Russian Dictionary, 7 Edition: stardict format
stardict-slovnyk_be-en - Dictionary: Slovnyk Belarusian-English
stardict-slovnyk_be-ru - Dictionary: Slovnyk Belarusian-Russian
stardict-slovnyk_be-uk - Dictionary: Slovnyk Belarusian-Ukrainian
stardict-slovnyk_cs-ru - Dictionary: Slovnyk Czech-Russian
stardict-slovnyk_en-be - Dictionary: Slovnyk English-Belarusian
stardict-slovnyk_en-ru - Dictionary: Slovnyk English-Russian
stardict-slovnyk_en-uk - Dictionary: Slovnyk English-Ukrainian
stardict-slovnyk_es-ru - Dictionary: Slovnyk Spanish-Russian
stardict-slovnyk_ru-be - Dictionary: Slovnyk Russian-Belarusian
stardict-slovnyk_ru-cs - Dictionary: Slovnyk Russian-Czech
stardict-slovnyk_ru-en - Dictionary: Slovnyk Russian-English
stardict-slovnyk_ru-es - Dictionary: Slovnyk Russian-Spanish
stardict-slovnyk_ru-uk - Dictionary: Slovnyk Russian-Ukrainian
stardict-slovnyk_uk-be - Dictionary: Slovnyk Ukrainian-Belarusian
stardict-slovnyk_uk-en - Dictionary: Slovnyk Ukrainian-English
stardict-slovnyk_uk-ru - Dictionary: Slovnyk Ukrainian-Russian
words - A dictionary of English words for the /usr/share/dict directory
Для того чтобы подробнее узнать информацию о найденном пакете и получить его подробное описание, воспользуйтесь командой apt-cache show:
$ apt-cache show stardict-mueller7
Package: stardict-mueller7
Section: Text tools
Installed Size: 3095255
Maintainer: Anton V. Boyarshinov <boyarsh@altlinux.ru>
Version: 1.0-alt7
Pre-Depends: rpmlib(PayloadIsLzma)
Depends: stardict (>= 2.4.2)
Provides: stardict-mueller7 (= 1.0-alt7)
Architecture: noarch
Size: 3135276
MD5Sum: ea95c67ca323350b454fbc26533c3548
Filename: stardict-mueller7-1.0-alt7.noarch.rpm
Description: V.K. Mueller English-Russian Dictionary, 7 Edition: stardict format
 Electronic version of V.K. Mueller English-Russian Dictionary, 7 Edition
 in stardict format. You can use it with stardict client.
При поиске с помощью apt-cache можно использовать русскую подстроку. В этом случае будут найдены пакеты, имеющие описание на русском языке. К сожалению, описание на русском языке в настоящее время есть не у всех пакетов, но наиболее актуальные описания переведены.

Глава 66. Установка или обновление пакета

Важно

Для установки пакетов требуются привилегии администратора.
Установка пакета с помощью APT выполняется командой apt-get install имя_пакета.

Важно

Перед установкой и обновлением пакетов необходимо выполнить команду обновления индексов пакетов:
# apt-get update
apt-get позволяет устанавливать в систему пакеты, требующие для работы наличие других, пока ещё не установленных пакетов. В этом случае он определяет, какие пакеты необходимо установить. apt-get устанавливает их, пользуясь всеми доступными репозиториями.
Установка пакета stardict-mueller7 командой apt-get install stardict-mueller7 приведёт к следующему диалогу с APT:
# apt-get install stardict-mueller7
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие НОВЫЕ пакеты будут установлены:
  stardict-mueller7
0 будет обновлено, 1 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
Необходимо получить 0B/3135kB архивов.
После распаковки потребуется дополнительно 3095kB дискового пространства.
Совершаем изменения...
Preparing...                 ####################### [100%]
1: stardict-mueller7         ####################### [100%]
Running /usr/lib/rpm/posttrans-filetriggers
Завершено.
Команда apt-get install имя_пакета используется также и для обновления уже установленного пакета или группы пакетов. В этом случае apt-get дополнительно проверяет, есть ли обновлённая, в сравнении с установленной в системе, версия пакета в репозитории.
При помощи APT можно установить и отдельный rpm-пакет, не входящий в состав репозиториев (например, полученный из сети Интернет). Для этого достаточно выполнить команду
# apt-get install /путь/к/файлу.rpm
При этом APT проведёт стандартную процедуру проверки зависимостей и конфликтов с уже установленными пакетами.
Иногда в результате операций с пакетами без использования APT целостность системы нарушается, и apt-get отказывается выполнять операции установки, удаления или обновления. В этом случае необходимо повторить операцию, задав опцию -f, заставляющую apt-get исправить нарушенные зависимости, удалить или заменить конфликтующие пакеты. В этом случае необходимо внимательно следить за сообщениями, выводимыми apt-get. Любые действия в этом режиме обязательно требуют подтверждения со стороны пользователя.

Глава 67. Удаление установленного пакета

Для удаления пакета используется команда apt-get remove имя_пакета. Для того чтобы не нарушать целостность системы, будут удалены и все пакеты, зависящие от удаляемого. В случае удаления пакета, который относится к базовым компонентам системы, apt-get потребует дополнительное подтверждение с целью предотвращения возможной случайной ошибки.

Важно

Для удаления пакетов требуются привилегии администратора.
При попытке с помощью apt-get удалить базовый компонент системы, вы увидите следующий запрос на подтверждение операции:
# apt-get remove filesystem
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие пакеты будут УДАЛЕНЫ:
  ...
ВНИМАНИЕ: Будут удалены важные для работы системы пакеты
Обычно этого делать не следует. Вы должны точно понимать возможные последствия!
  ...
0 будет обновлено, 0 новых установлено, 2648 пакетов будет удалено и 0 не будет обновлено.
Необходимо получить 0B архивов.
После распаковки будет освобождено 8994MB дискового пространства.
Вы делаете нечто потенциально опасное!
Введите фразу 'Yes, do as I say!' чтобы продолжить.
Каждую ситуацию, в которой APT выдаёт такой запрос, необходимо рассматривать отдельно. Вероятность того, что после выполнения этой команды система окажется неработоспособной, очень велика.

Глава 68. Обновление системы

68.1. Обновление всех установленных пакетов

Для обновления всех установленных пакетов необходимо выполнить команды:
# apt-get update && apt-get dist-upgrade
Первая команда (apt-get update) обновит индексы пакетов. Вторая команда (apt-get dist-upgrade) позволяет обновить только те установленные пакеты, для которых в репозиториях, перечисленных в /etc/apt/sources.list, имеются новые версии.

Примечание

Несмотря на то, что команда apt-get upgrade существует, использовать её следует осторожно, либо не использовать вовсе.
Она позволяет обновить только те установленные пакеты, для которых в репозиториях, перечисленных в /etc/apt/sources.list, имеются новые версии.
Никакие другие пакеты при этой операции из системы удалены не будут. Этот способ полезен при работе со стабильными пакетами приложений, относительно которых известно, что они при смене версии изменяются несущественно.
Иногда, однако, происходит изменение в наименовании пакетов или изменение их зависимостей. Такие ситуации не обрабатываются командой apt-get upgrade, в результате чего происходит нарушение целостности системы: появляются неудовлетворённые зависимости. Для разрешения этой проблемы существует режим обновления в масштабе дистрибутива — apt-get dist-upgrade.
В случае обновления всего дистрибутива APT проведёт сравнение системы с репозиторием и удалит устаревшие пакеты, установит новые версии присутствующих в системе пакетов, отследит ситуации с переименованиями пакетов или изменения зависимостей между старыми и новыми версиями программ. Всё, что потребуется поставить (или удалить) дополнительно к уже имеющемуся в системе, будет указано в отчёте apt-get, которым APT предварит само обновление.

Примечание

Команда apt-get dist-upgrade обновит систему, но ядро ОС не будет обновлено.

68.2. Обновление ядра

Для обновления ядра ОС необходимо выполнить команду:
# update-kernel

Примечание

Если индексы сегодня еще не обновлялись перед выполнением команды update-kernel необходимо выполнить команду apt-get update.
Команда update-kernel обновляет и модули ядра, если в репозитории обновилось что-то из модулей без обновления ядра.
Новое ядро загрузится только после перезагрузки системы, которую рекомендуется выполнить немедленно.
Если с новым ядром что-то пойдёт не так, вы сможете вернуться к предыдущему варианту, выбрав его в начальном меню загрузчика.
После успешной загрузки на обновленном ядре можно удалить старое, выполнив команду:
# remove-old-kernels

Часть XI. Основы администрирования Linux

Глава 69. Общие принципы работы ОС

69.1. Процессы и файлы

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

69.1.1. Процессы функционирования ОС

Все программы, которые выполняются в текущий момент времени, называются процессами. Процессы можно разделить на два основных класса: системные процессы и пользовательские процессы.
Системные процессы — программы, решающие внутренние задачи ОС, например, организацию виртуальной памяти на диске или предоставляющие пользователям те или иные сервисы (процессы-службы).
Пользовательские процессы — процессы, запускаемые пользователем из командного интерпретатора для решения задач пользователя или управления системными процессами. Linux изначально разрабатывался как многозадачная система. Он использует технологии, опробованные и отработанные другими реализациями UNIX, которые существовали ранее.
Фоновый режим работы процесса — режим, когда программа может работать без взаимодействия с пользователем. В случае необходимости интерактивной работы с пользователем (в общем случае) процесс будет «остановлен» ядром, и работа его продолжается только после переведения его в «нормальный» режим работы.

69.1.2. Файловая система ОС

В ОС использована файловая система Linux, которая, в отличие от файловых систем DOS и Windows(™), является единым деревом. Корень этого дерева — каталог, называемый root (рут) и обозначаемый /.
Части дерева файловой системы могут физически располагаться в разных разделах разных дисков или вообще на других компьютерах — для пользователя это прозрачно. Процесс присоединения файловой системы раздела к дереву называется монтированием, удаление — размонтированием. Например, файловая система CD-ROM в дистрибутиве монтируется по умолчанию в каталог /media/cdrom (путь в дистрибутиве обозначается с использованием /, а не \, как в DOS/Windows).
Текущий каталог обозначается ./.

69.1.3. Структура каталогов

Корневой каталог /:
  • /bin — командные оболочки (shell), основные утилиты;
  • /boot — содержит ядро системы;
  • /dev — псевдофайлы устройств, позволяющие работать с устройствами напрямую. Файлы в /dev создаются сервисом udev
  • /etc — общесистемные конфигурационные файлы для большинства программ в системе;
  • /etc/rc?.d, /etc/init.d, /etc/rc.boot, /etc/rc.d — каталоги, где расположены командные файлы, выполняемые при запуске системы или при смене её режима работы;
  • /etc/passwd — база данных пользователей, в которой содержится информация об имени пользователя, его настоящем имени, личном каталоге, его зашифрованный пароль и другие данные;
  • /etc/shadow — теневая база данных пользователей. При этом информация из файла /etc/passwd перемещается в /etc/shadow, который недоступен для чтения всем, кроме пользователя root. В случае использования альтернативной схемы управления теневыми паролями (TCB), все теневые пароли для каждого пользователя располагаются в каталоге /etc/tcb/имя пользователя/shadow;
  • /home — домашние каталоги пользователей;
  • /lib — содержит файлы динамических библиотек, необходимых для работы большей части приложений, и подгружаемые модули ядра;
  • /lost+found — восстановленные файлы;
  • /media — подключаемые носители (каталоги для монтирования файловых систем сменных устройств);
  • /mnt — точки временного монтирования;
  • /opt — вспомогательные пакеты;
  • /proc — виртуальная файловая система, хранящаяся в памяти компьютера при загруженной ОС. В данном каталоге расположены самые свежие сведения обо всех процессах, запущенных на компьютере.
  • /root — домашний каталог администратора системы;
  • /run — файлы состояния приложений;
  • /sbin — набор программ для административной работы с системой (системные утилиты);
  • /selinux — виртуальная файловая система SELinux;
  • /srv — виртуальные данные сервисных служб;
  • /sys — файловая система, содержащая информацию о текущем состоянии системы;
  • /tmp — временные файлы.
  • /usr — пользовательские двоичные файлы и данные, используемые только для чтения (программы и библиотеки);
  • /var — файлы для хранения изменяющихся данных (рабочие файлы программ, очереди, журналы).
Каталог /usr:
  • /usr/bin — дополнительные программы для всех учетных записей;
  • /usr/sbin — команды, используемые при администрировании системы и не предназначенные для размещения в файловой системе root;
  • /usr/local — место, где рекомендуется размещать файлы, установленные без использования пакетных менеджеров, внутренняя организация каталогов практически такая же, как и корневого каталога;
  • /usr/man — каталог, где хранятся файлы справочного руководства man;
  • /usr/share — каталог для размещения общедоступных файлов большей части приложений.
Каталог /var:
  • /var/log — место, где хранятся файлы аудита работы системы и приложений;
  • /var/spool — каталог для хранения файлов, находящихся в очереди на обработку для того или иного процесса (очереди печати, непрочитанные или не отправленные письма, задачи cron т.д.).

69.1.4. Организация файловой структуры

Система домашних каталогов пользователей помогает организовывать безопасную работу пользователей в многопользовательской системе. Вне своего домашнего каталога пользователь обладает минимальными правами (обычно чтение и выполнение файлов) и не может нанести ущерб системе, например, удалив или изменив файл.
Кроме файлов, созданных пользователем, в его домашнем каталоге обычно содержатся персональные конфигурационные файлы некоторых программ.
Маршрут (путь) — это последовательность имён каталогов, представляющая собой путь в файловой системе к данному файлу, где каждое следующее имя отделяется от предыдущего наклонной чертой (слешем). Если название маршрута начинается со слеша, то путь в искомый файл начинается от корневого каталога всего дерева системы. В обратном случае, если название маршрута начинается непосредственно с имени файла, то путь к искомому файлу должен начаться от текущего каталога (рабочего каталога).
Имя файла может содержать любые символы за исключением косой черты (/). Однако следует избегать применения в именах файлов большинства знаков препинания и непечатаемых символов. При выборе имен файлов рекомендуется ограничиться следующими символами:
  • строчные и ПРОПИСНЫЕ буквы. Следует обратить внимание на то, что регистр всегда имеет значение;
  • символ подчеркивания (_);
  • точка (.).
Для удобства работы точку можно использовать для отделения имени файла от расширения файла. Данная возможность может быть необходима пользователям или некоторым программам, но не имеет значение для shell.

69.1.5. Имена дисков и разделов

Все физические устройства вашего компьютера отображаются в каталог /dev файловой системы дистрибутива (об этом — ниже). Диски (в том числе IDE/SATA/SCSI/SAS жёсткие диски, USB-диски) имеют имена:
  • /dev/sda — первый диск;
  • /dev/sdb — второй диск;
  • и т.д.
Диски обозначаются /dev/sdX, где X — a, b, c, d, e, … в зависимости от порядкового номера диска на шине.
Раздел диска обозначается числом после его имени. Например, /dev/sdb4 — четвертый раздел второго диска.

69.1.6. Разделы, необходимые для работы ОС

Для работы ОС на жестком диске (дисках) должны быть созданы, по крайней мере, два раздела: корневой (то есть тот, который будет содержать каталог /) и раздел подкачки (swap). Размер последнего, как правило, составляет от однократной до двукратной величины оперативной памяти компьютера. Если на диске много свободного места, то можно создать отдельные разделы для каталогов /usr, /home, /var.

69.2. Работа с наиболее часто используемыми компонентами

69.2.1. Виртуальная консоль

Система Альт Сервер Виртуализации предоставляет доступ к виртуальным консолям, с которых можно осуществлять одновременно несколько сеансов работы в системе (login session).
Только что установленная система Альт Сервер Виртуализации, возможно, предоставляет доступ только к первым шести виртуальным консолям, к которым можно обращаться, нажимая комбинации клавиш Alt+F1Alt+F6 (Ctrl+Alt+F1Ctrl+Alt+F6).

69.2.2. Командные оболочки (интерпретаторы)

Для управления ОС используются командные интерпретаторы (shell).
Зайдя в систему, Вы увидите приглашение — строку, содержащую символ «$» (далее этот символ будет обозначать командную строку). Программа ожидает ваших команд. Роль командного интерпретатора — передавать ваши команды операционной системе. По своим функциям он соответствует command.com в DOS, но несравненно мощнее. При помощи командных интерпретаторов можно писать небольшие программы — сценарии (скрипты). В Linux доступны следующие командные оболочки:
  • bash — самая распространенная оболочка под linux. Она ведет историю команд и предоставляет возможность их редактирования;
  • pdksh — клон korn shell, хорошо известной оболочки в UNIX™ системах.
Проверить, какая оболочка используется в данный момент можно, выполнив команду:
$ echo $SHELL
Оболочкой по умолчанию является Bash (Bourne Again Shell) — самая распространённая оболочка под Linux, которая ведет историю команд и предоставляет возможность их редактирования. В дальнейшем описании работы с Альт Сервер Виртуализации будут использоваться примеры с использованием этой оболочки.

69.2.3. Командная оболочка Bash

В Bash имеется несколько приемов для работы со строкой команд. Например, можно использовать следующие сочетания:
  • Ctrl+A — перейти на начало строки;
  • Ctrl+U — удалить текущую строку;
  • Ctrl+C — остановить текущую задачу.
Для ввода нескольких команд одной строкой можно использовать разделитель «;». По истории команд можно перемещаться с помощью клавиш («вверх») и («вниз»).
Чтобы найти конкретную команду в списке набранных, не пролистывая всю историю, можно нажать Ctrl+R и начать вводить символы ранее введенной команды.
Для просмотра истории команд можно воспользоваться командой history. Команды, присутствующие в истории, отображаются в списке пронумерованными. Чтобы запустить конкретную команду необходимо набрать:
!номер команды
Если ввести:
!!
запустится последняя из набранных команд.
В Bash имеется возможность самостоятельного завершения имен команд из общего списка команд, что облегчает работу при вводе команд, в случае, если имена программ и команд слишком длинны. При нажатии клавиши Tab Bash завершает имя команды, программы или каталога, если не существует нескольких альтернативных вариантов. Например, чтобы использовать программу декомпрессии gunzip, можно набрать следующую команду:
gu
Затем нажать клавишу Tab. Так как в данном случае существует несколько возможных вариантов завершения команды, то необходимо повторно нажать клавишу Tab, чтобы получить список имен, начинающихся с gu.
В предложенном примере можно получить следующий список:
$ gu
guile gunzip gupnp-binding-tool
Если набрать: n (gunzip — это единственное имя, третьей буквой которого является «n»), а затем нажать клавишу Tab, то оболочка самостоятельно дополнит имя. Чтобы запустить команду нужно нажать Enter.
Программы, вызываемые из командной строки, Bash ищет в каталогах, определяемых в системной переменной $PATH. По умолчанию в этот перечень каталогов не входит текущий каталог, обозначаемый ./ (точка слеш) (если только не выбран один из двух самых слабых уровней защиты). Поэтому, для запуска программы из текущего каталога, необходимо использовать команду (в примере запускается команда prog):
./prog

69.2.4. Команда

Простейшая команда состоит из одного «слова», например, команда cal, выводящая календарь на текущий месяц.
$ cal
     Май 2021
Пн Вт Ср Чт Пт Сб Вс
                1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

69.2.5. Команда и параметры

$ cal 1 2022
     Январь 2022
Пн Вт Ср Чт Пт Сб Вс
                1  2
 3  4  5  6  7  8  9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Команда cal 1 2022 состоит из двух частей — собственно команды cal и «остального». То, что следует за командой называется параметрами (или аргументами) и они вводятся для изменения поведения команды. В большинстве случаев, первое слово считается именем команды, а остальные — её параметрами.

69.2.6. Команда и ключи

Для решения разных задач одни и те же действия необходимо выполнять по-разному. Например, для синхронизации работ в разных точках земного шара лучше использовать единое для всех время (по Гринвичу), а для организации собственного рабочего дня — местное время (с учётом сдвига по часовому поясу и разницы зимнего и летнего времени). И то, и другое время показывает команда date, только для работы по Гринвичу ей нуж