Управление виртуальными машинами с помощью Cockpit

Cockpit мощный, но (пока) не идеальный. Текущая версия не предоставляет графического инструмента для этой цели. Системному администратору всё ещё приходится полагаться на инструменты командной строки, такие как qemu-img или утилиты virt-* из guestsfs-tools. К счастью, нам нужно использовать инструмент командной строки только для увеличения образа виртуального диска, пока виртуальная машина остановлена. После этого мы можем снова запустить виртуальную машину и использовать Cockpit виртуальной машины для перенастройки хранилища.

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

В разделе Filesystems центральной области содержимого [1] есть 2 файловые системы: root размером 11 ГиБ и boot размером 1 ГиБ. Дополнительная информация находится в правой колонке. Раздел Devices указывает группу томов размером 11 ГиБ [2]. Это означает, что корневая файловая система полностью заполняет эту группу томов. Раздел Drives перечисляет виртуальный диск размером 12 ГиБ [3]. Это означает, что этот диск полностью заполнен двумя файловыми системами.

После завершения работы vm2 мы можем увеличить виртуальный диск на 20 ГиБ до общего размера 32 ГиБ в терминале Cockpit хоста.

Как показывает информация, размер виртуального диска теперь составляет 32 ГиБ. Файл по-прежнему занимает только 2,01 ГиБ в каталоге благодаря динамическому формату файла qcow2.

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

После повторного запуска vm2 страница Storage теперь, что неудивительно, показывает диск размером 32 ГиБ, но больше ничего не изменилось. Таким образом, на диске теперь 20 ГиБ нераспределённого пространства.

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

Теперь у вас есть три варианта:

Здесь мы продолжим с вариантом 2. Он так же привержен логике Fedora Server, как и вариант 1, если не даже строже. С Cockpit это более удобный вариант, и в конечном счёте он выполняет те же действия, то есть создание логического тома с файловой системой и монтирование его в подходящем месте дерева каталогов. А вариант 3 концептуально худший из всех.

На странице Storage vm2 выберите виртуальный диск размером 32 ГиБ и на открывшейся новой странице нажмите кнопку «Create partition» прямо под разделом /dev/vda2 [1].

Вам нужно только изменить тип на «No filesystem» [2] и создать раздел. Проходит некоторое время, прежде чем в списке отображается третий раздел.

Вернитесь на страницу Storage. В верхней части правой колонки активируйте значок меню рядом с Devices и выберите «Create volume group».

В открывшейся форме введите имя группы томов, здесь по аналогии с fedora_fedora системной области — fedora_user, выберите только что созданный раздел /dev/vda3 и создайте группу томов. Форма закроется, и на странице Storage вы найдёте новое устройство — группу томов fedora_user размером 20,0 ГиБ.

Как уже упоминалось, в соответствии с концепцией хранилища Fedora Server, область данных, отдельная от системных данных, должна содержать служебные и пользовательские данные. Один из способов, совместимых с FHS, — смонтировать каталог /srv в отдельном логическом томе и хранить там соответствующие данные для всех служб. Другой способ — смонтировать известный выделенный каталог приложения в его собственном логическом томе. Например, в Fedora Server PostgreSQL хранит все свои данные в /var/lib/pgsql, а Apache httpd — в /var/www. Эти каталоги монтируются каждый в своём логическом томе, предпочтительно до установки программного обеспечения.

В качестве примера мы установим данные httpd в отдельный логический том. На случай, если программное обеспечение уже установлено, остановите httpd и временно переместите данные в сторону. Мы восстановим их позже. Каталог /var/www должен быть пустым.

Страница Storage виртуальной машины (vm2) отображает раздел Devices в верхней правой колонке, а внутри — группу томов fedora_user, которую мы настроили ранее. Нажатие на fedora_user открывает страницу конфигурации группы томов. Под блоком с подробностями группы томов находится список существующих логических томов этой группы томов. Справа от заголовка предоставляется ссылка «Create new logical volume», которая открывает форму конфигурации.

Замените предустановленное имя описательным термином, здесь, например, web service, и выберите подходящий размер. Благодаря динамическому распределению пространства формата qcow2 вы можете выбрать размер определённо немного щедрее. Однако последующее расширение с помощью Cockpit выполняется очень легко.

С помощью Purpose форма также предлагает возможность создать пул для «тонко резервируемых томов», который, в свою очередь, вмещает логические тома, динамически распределяющие пространство. В случае виртуальной машины это обычно не так полезно, как на физических машинах, потому что файлы образов дисков qcow2 уже обеспечивают своего рода тонкое резервирование. Но ваш опыт может отличаться.

После создания логического тома вы найдёте запись в списке «Logical volumes». Разверните строку с помощью значка треугольника. Вы найдёте кнопку Format. Связанная форма позволяет создать и смонтировать файловую систему за один проход.

Вам нужно только указать (описательное) имя и точку монтирования. После форматирования вы найдёте группу томов смонтированной и готовой к использованию.

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

Если вы переместили файлы в сторону в начале, теперь вы можете их восстановить. Для надёжности восстановите метки SELinux.

Теперь самое время установить соответствующие программы. Программное обеспечение, предоставляемое дистрибутивом Fedora в виде rpm, устанавливается в соответствующие системные каталоги с помощью инструмента dnf. Внешнее программное обеспечение следует устанавливать в /opt или /usr/local, чтобы держать его отдельно от файлов дистрибутива и предотвратить любое потенциальное взаимное вмешательство. В соответствии с логикой хранилища вам также следует создать отдельный логический том и смонтировать его в /opt. Примером этого может служить сервер приложений Wildfly, который хранит программу, конфигурацию и, возможно, данные в одном месте.

Расширение виртуального (системного) диска — не единственный способ предоставить дополнительное хранилище и не обязательно лучший. В случае образов виртуальных дисков создание выделенного виртуального диска вместо создания логических томов является надёжной, часто лучшей альтернативой. Это добавляет больше гибкости. Например, в случае упомянутой выше виртуальной машины «холодного резерва» системный администратор может назначить (виртуальный) диск со всем текущим набором данных другой виртуальной машине менее чем за минуту.

Cockpit поддерживает создание дополнительных виртуальных дисков (но, к сожалению, не изменение существующего). На странице подробностей виртуальной машины в разделе Disks вы найдёте кнопку Add Disk. Она открывает форму для заполнения.

В приведённом выше примере мы создаём диск размером 30 ГБ для Web service. Add создаёт образ диска в /var/lib/libvirt/images и добавляет его на страницу подробностей виртуальной машины в Cockpit. Вы можете проверить в окне терминала с помощью lsblk. Он показывает диск vdb пока без каких-либо разделов.

Cockpit хоста просто создаёт новый (виртуальный) жёсткий диск и «вставляет» его в виртуальную машину. Конфигурация и настройка жёсткого диска происходят внутри виртуальной машины. Их Cockpit может выполнить это очень легко. Откройте новую вкладку в браузере, откройте Cockpit виртуальной машины и выберите там Storage.

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

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

Возможно, вы настроили виртуальную машину только с публичным интерфейсом, чтобы предоставить некоторую публичную службу. Согласно общим рекомендациям она использует mac-vlan в качестве эффективного типа подключения. В графическом интерфейсе Cockpit виртуальной машины он отображается как «type: direct» и «Source: enp1s0», физический интерфейс хоста [1].

Через некоторое время вам может потребоваться доступ к службе, предоставляемой хостом, например, к службе базы данных. Поскольку публичный интерфейс использует mac-vlan, прямое взаимодействие между хостом и виртуальной машиной невозможно (из-за технических ограничений этого типа). Кроме того, вы можете захотеть защитить это взаимодействие и его данные от публичного доступа. Решение состоит в том, чтобы добавить виртуальной машине интерфейс, который подключается к внутренней виртуальной сети libvirt с именем default и использованием virbr0.

С Cockpit это всего лишь нажатие на ссылку «Add network interface» справа от заголовка раздела [2] и заполнение простой формы.

В случае внутреннего интерфейса оставьте всё как предложено, но просто активируйте «Always attach», чтобы он автоматически становился доступным после перезагрузки. Используйте кнопку «Add» для создания интерфейса.

Интерфейс появляется ниже публичного интерфейса. А внутри виртуальной машины ip a показывает дополнительное подключение «enp7s0». Cockpit всё настраивает самостоятельно, дальнейшее участие системного администратора не требуется.

Возможно, вы настроили виртуальную машину только с внутренним интерфейсом, который прекрасно работает как (единственный) интерфейс enp1s0. Теперь вам нужен вместо этого публичный доступ. Самый простой способ — отредактировать определение интерфейса в Cockpit.

В разделе network страницы подробностей виртуальной машины есть только один интерфейс с 3 кнопками: Delete, Unplug и Edit. Последняя открывает форму свойств интерфейса.

Форма показывает определение текущей внутренней сети. Просто измените Interface type с «Virtual network» на «Direct attachment» и Source с «default» на «enp1s0», физический интерфейс хоста. Сохраните выбор и перезагрузитесь. Предполагая, что DHCP работает, виртуальная машина имеет прекрасно работающее подключение к публичной сети, включая разрешение имён и конфигурацию брандмауэра по умолчанию. В противном случае вам придётся определить статическую сетевую конфигурацию.

Даже если вам нужен публичный интерфейс в дополнение к существующему внутреннему интерфейсу, вы можете предпочесть отредактировать существующий интерфейс и позже добавить новый внутренний интерфейс. Таким образом вы следуете общепринятой практике всегда настраивать публичный интерфейс как «первый», то есть enp1s0 или eth0.

В качестве примера виртуальная машина оснащена двумя интерфейсами: публичным (enp1s0) и внутренним (enp7s0).

Вероятно, вы не хотите публичный интерфейс, а хотите, чтобы машина была хорошо защищена от публичной сети. Поэтому вы удаляете публичный интерфейс. Простое нажатие на Delete удалит этот интерфейс из виртуальной машины (после подтверждения). Если вы проверите сетевую конфигурацию внутри машины, nmcli device show перечислит только одно устройство, привязанное к существующему подключению. А ip a перечислит только lo и enp7s0.

nmcli conn show всё ещё перечисляет подключение enp1s0, но без привязанного устройства. Причина в том, что это был первый интерфейс, явно настроенный во время установки. Поэтому он был сохранён в /etc/NetworkManager/system-connected, и файл всё ещё там (хотя и без каких-либо параметров конфигурации устройства). Cockpit не удаляет файл конфигурации.