PVE: различия между версиями

Текущая версия от 19:59, 12 апреля 2024

Что это такое

Proxmox Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора KVM и системы контейнерной изоляции LXC. Строго говоря, PVE это не система виртуализации, а инструментарий управления средой, в которой выполняются виртуальные окружения KVM и LXC. Основными компонентами среды являются:

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

Как это устроено

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

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

Веб-интерфейс пользователя PVE предназначен для решения следующих задач:

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

Кроме решения пользовательских задач, веб-интерфейс PVE можно использовать ещё и для встраивания в интегрированные системы управления — например, в панели управления хостингом. Для этого он имеет развитый RESTful API с JSON в качестве основного формата данных.

Для аутентификации пользователей веб-интерфейса можно использовать как собственные механизмы PVE, так и PAM. Использование PAM даёт возможность, например, интегрировать PVE в домен аутентификации.

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

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

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

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

Установка и настройка PVE

Альт Сервер Виртуализации 9/10

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

Примечание: Компоненты PVE будут установлены в систему, если при установке дистрибутива выбрать профиль Виртуальное окружение Proxmox.

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

PVE должен быть установлен на всех узлах. Следует убедиться, что каждый узел установлен с окончательным именем хоста и IP-конфигурацией. Изменение имени хоста и IP-адреса невозможно после создания кластера.

Примечание: Локальная установка — частный случай кластера из одного узла.

Настройка преобразования имен

Необходимо обеспечить взаимно однозначное прямое и обратное преобразование имен для всех узлов кластера. Крайне желательно использовать DNS, в крайнем случае, можно обойтись соответствующими записями в локальных файлах /etc/hosts:

# echo "192.168.88.186 pve01.localdomain pve01" >> /etc/hosts
# echo "192.168.88.90 pve02.localdomain pve02" >> /etc/hosts
# echo "192.168.88.70 pve03.localdomain pve03" >> /etc/hosts

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

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

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

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

Внимание! При использовании дистрибутива Альт Сервер Виртуализации 9/10 интерфейс vmbr0 создаётся и настраивается в процессе установки.

Для настройки 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

При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически).

Создание кластера PVE

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

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

На «головном» узле кластера необходимо выполнить команды инициализации конкретного кластера PVE, в данном случае — «pve», выполнив команды (это можно сделать и из веб-интерфейса «Центр обработки данных» → «Кластер» → «Создать кластер» («Datacenter» → «Cluster» → «Create claster»), запустив перед этим все необходимые службы (см.ниже)):

# systemctl start pve-cluster
# pvecm create pve

Проверка:

# pvecm status
Quorum information
------------------
Date:             Fri Sep 27 16:29:06 2019
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1/4
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.88.186 (local)

Команда создания кластера создает файл настройки /etc/pve/corosync.conf. По мере добавления узлов в кластер файл настройки будет автоматически пополняться информацией об узлах.

Для добавления узлов в кластер, необходимо на «подчинённых» узлах выполнить следующие команды:

# systemctl start pve-cluster
# pvecm add pve01

где pve01 — имя или IP-адрес «головного» узла. При добавлении узла в кластер, потребуется ввести пароль администратора главного узла кластера:

# pvecm add 192.168.88.186
Please enter superuser (root) password for '192.168.88.186':
                                                        Password for root@192.168.88.186: ***
Establishing API connection with host '192.168.88.186'
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-1573727779.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 lxcfs lxc-net lxc-monitord qmeventd pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pvescheduler ksmtuned
# systemctl enable corosync lxc lxcfs lxc-net lxc-monitord qmeventd pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests pvescheduler ksmtuned

Внимание! При использовании дистрибутивов Альт Сервер Виртуализации 9.2/10.0 все указанные службы добавляются и запускаются автоматически. Веб-интерфейс PVE должен быть доступен сразу после перезагрузки после установки дистрибутива.

Дальнейшие настройки кластера удобно делать через веб-интерфейс.

Веб-интерфейс PVE доступен по адресу https://<внешний-IP-адрес>:8006. Потребуется пройти аутентификацию (логин по умолчанию: root, пароль указывается в процессе установки):

Альт на базе 8-й платформы (p8)

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

На всех нодах:

# apt-get install pve-manager

Рассмотрим настройку кластера PVE. Локальную установку будем считать частным случаем кластера из одного узла.

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

Примечание: Если в файле options интерфейса не задан TYPE, pve-manager завершается с ошибкой.

Сначала на всех узлах кластера настроим Ethernet-мост в соответствии с руководством:

# ip=$(hostname -i)
# cat > /etc/net/ifaces/ens18/options << EOF
TYPE=eth
EOF
# mkdir -p /etc/net/ifaces/vmbr0
# cat > /etc/net/ifaces/vmbr0/options << EOF
BOOTPROTO=static
TYPE=bri
HOST='ens18'
CONFIG_WIRELESS=no
CONFIG_IPV4=yes
EOF
# cat > /etc/net/ifaces/vmbr0/ipv4address << EOF
$ip/21
EOF
# cat > /etc/net/ifaces/vmbr0/ipv4route << EOF
default via 10.88.8.1
EOF
# cat > /etc/net/ifaces/vmbr0/resolv.conf << EOF
search example.com test.com
nameserver 10.0.0.0
EOF
# cat <<EOF  > /etc/net/ifaces/vmbr0/brctl
stp AUTO off
setfd AUTO 0
EOF

Имя интерфейса, обозначенного здесь как ens18, следует указать в соответствии с реальной конфигурацией сервера.

Внимание! Данная последовательность команд приводит к желаемому результату только в том случае, если интерфейс, который является хостом для моста, ранее не настраивался. В противном случае необходимо также удалить или очистить ipv4address, ipv4route и resolv.conf, иначе могут возникнуть проблемы при дальнейшей настройке.

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

Внимание! При этом нужно учесть, что мост, созданный через веб-интерфейс, будет иметь имя br*, в то время как для PVE стандартом является vmbr*. Это может приводить к труднодиагностируемым и трудноразрешимым проблемам, препятствующим нормальному запуску PVE.

Далее необходимо обеспечить взаимно однозначное прямое и обратное преобразование имён для всех узлов кластера. Крайне желательно использовать DNS, но в крайнем случае можно обойтись соответствующими записями в локальных файлах /etc/hosts:

# echo "10.88.8.251 pve1.localdomain pve1" >> /etc/hosts
# echo "10.88.8.252 pve2.localdomain pve2" >> /etc/hosts
# echo "10.88.8.253 pve3.localdomain pve3" >> /etc/hosts

При этом имя машины НЕ должно присутствовать в файле /etc/hosts, разрешающимся в 127.0.0.1!

Настройка взаимодействия компонентов PVE

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

Для передачи команд между узлами кластера необходимо обеспечить взаимную беспарольную аутентификацию пользователя root. Это можно сделать вручную, а можно при добавлении нового узла в кластер PVE разрешить на «ведущем» узле вход пользователя root по паролю и ввести пароль. После этого взаимная беспарольная аутентификация root будет настроена автоматически утилитами PVE, и вход root по паролю можно будет снова отключить.

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

Теперь осталось настроить ещё два компонента системы, которые утилиты PVE пока не могут полностью автоматически настроить при запуске кластера. Это демон rrdcached, отвечающий за хранение данных мониторинга активности подсистем кластера, и corosync — комплекс ПО, обеспечивающий в пределах кластера элементы высокой доступности.

Выполнить на всех нодах:

# sh /usr/share/doc/pve-cluster/pve-firsttime
# rm -f /etc/corosync/corosync.conf

Для версии pve-cluster 6.0 и выше:

# rm -f /etc/corosync/corosync.conf

Конфигурационный файл corosync после этого будет создан автоматически при инициализации кластера PVE.

Запуск служб кластера

Запускаем службы кластера и настраиваем их автоматический запуск при старте узла:

# systemctl start ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
# systemctl enable ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target

Для версии 6.0 (в связи с заменой ntpd на chrony):

# systemctl start chronyd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
# systemctl enable chronyd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target

Также на версии 6.0 может потребоваться предварительно доустановить nfs-clients.

Далее, на «головном» (см. выше) узле кластера выполняем команды собственно инициализации конкретного кластера PVE, в данном случае — «mypve»:

# systemctl start pve-cluster
# ip=$(hostname -i)
# pvecm create pve --ring0_addr $ip

Внимание! Если после переустановки pve не возможно инициализировать кластер: cluster config '/etc/pve/corosync.conf' already exists удалите файл /etc/pve/corosync.conf.

Для версии pve-cluster 6.0 и выше:

# systemctl start pve-cluster
# ip=$(hostname -i)
# pvecm create pve

Если на данном этапе получили ошибку, загляните на форум за возможным решением

На «подчинённых» (см. выше) узлах:

Внимание! Если при добавлении узла возникает ошибка: * cluster config '/etc/pve/corosync.conf' already exists необходимо добавить опцию -force (В версии 6.0.7 данной опции нет, что подтверждает man)

# ip=$(hostname -i)
# systemctl start pve-cluster
# pvecm add 10.88.10.251 --ring0_addr $ip

Для версии pve-cluster 6.0 и выше:

# systemctl start pve-cluster
# pvecm add 10.88.10.251 --use_ssh

Далее, запускаем остальные службы и добавляем их в список служб, запускаемых при старте узла:

# systemctl start lxc lxc-net lxc-monitord pve-lxc-syscalld pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy ksmtuned
# systemctl enable corosync lxc lxc-net lxc-monitord pve-lxc-syscalld pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests ksmtuned

Дальнейшие настройки кластера удобно делать через веб интерфейс.

Применение PVE

В ходе работы с веб-интерфейсом PVE оператору приходится иметь дело со следующими основными объектами: физическими узлами, виртуальными окружениями, хранилищами данных и субъектами авторизации. Так как PVE является средством управления виртуальными окружениями, рассматривать взаимодействие компонентов мы будем относительно них. Виртуальные окружения под управлением PVE бывают двух типов: полностью виртуализированные, управляемые гипервизором KVM, и изолированные окружения выполняющиеся непосредственно на основном ядре ОС физического узла. Первые в терминах PVE называются ВМ (виртуальные машины), а вторые — CT (контейнеры, ConTainers).

Хранилища данных

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

Хранилищами данных удобно управлять через веб-интерфейс. В качестве бэкенда хранилищ PVE может использовать:

сетевые файловые системы, в том числе распределённые: NFS, CEPH, GlusterFS;
локальные системы управления дисковыми томами: LVM, ZFS;
удалённые (iSCSI) и локальные дисковые тома;
локальные дисковые каталоги.

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

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

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

Подключение общего хранилища iSCSI (Multipath) с использованием LVM

Настройка iSCSI-target на базе ALT подробно описана в этой статье.

Внимание! iSCSI initiator настраивается средствами ALT PVE.
Сервис iscsid запускается средствами ALT PVE и не должен присутствовать в автозагрузке.

Исходные данные:

настроенный кластер ALT PVE
настроенный iSCSI target

Для добавления iSCSI устройства надо зайти в веб-интерфейс ALT PVE в раздел «Центр обработки данных» → «Хранилище» → «Добавить» → «iSCSI» («Datacenter» → «Storage» → «Add» → «iSCSI»):

ID — имя добавляемого устройства, может быть любым, но изменить его позже нельзя;
Portal — адрес iSCSI сервера;
Цель (Target) — выпадающий список ресурсов, отдаваемых iSCSI сервером;
Узлы (Nodes) — каким нодам будет доступно данное хранилище;
Включить (Enable) — Вкл/Выкл хранилище;
Использовать LUN напрямую (Use LUNs directly) — использование LUN напрямую, отметку надо снять.

Ту же процедуру надо проделать для второго адреса iSCSI-сервера.

После этого на всех нодах появятся два блочных устройства.

Затем необходимо настроить Multipath по этой инструкции

Далее переходим в консоль на любой ноде для настройки LVM.

Для корректной работы LVM и Multipath говорим LVM не сканировать наши iSCSI-диски (sd*). В файл /etc/lvm/lvm.conf добавляем:

devices {
...
filter = [ "r|/dev/sd|" ]
...
}

Инициализируем блочные устройства для использования в LVM:

# pvcreate /dev/mapper/mpatha

Создаём группу томов 'sharedsv':

# vgcreate sharedsv /dev/mapper/mpatha

Далее переходим в веб-интерфейс ALT PVE в раздел «Центр обработки данных» → «Хранилище» → «Добавить» → «LVM» («Datacenter» → «Storage» → «Add» → «LVM»):

ID — имя добавляемого устройства, может быть любым, но изменить его позже нельзя;
Основное хранилище (Base Storage) — выбираем 'Existing volume groups';
Группа томов (Volume group) — выпадающий список LVM разделов, выбираем созданный нами 'sharedsv';
Содержимое (Content) — что разрешено хранить на данном хранилище;
Узлы (Nodes) — каким нодам будет доступно данное хранилище;
Включить (Enable) — Вкл/Выкл хранилище;
Общий доступ (Shared) — делает хранилище доступным для всех нод.

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

ВМ: виртуальные машины KVM

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

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

Прежде чем создать в интерфейсе PVE виртуальную машину (ВМ), необходимо определиться со следующими моментами:

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

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

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

Теперь, когда все предварительные действия выполнены, нажимаем в веб-интерфейсе PVE кнопку «Создать ВМ» в правом верхнем углу.

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

Создание ВМ с UEFI

Примечание: По умолчанию, в качестве прошивки, используется SeaBIOS, который эмулирует BIOS x86. Можно также выбрать OVMF, который эмулирует UEFI.

Создать ВМ стандартным способом.
Поменять тип прошивки на uefi (на вкладке «Оборудование» («Hardware») выбрать строку BIOS и поменять значение на «OVMF (UEFI)»):
Добавить в конфигурацию ВМ EFI Disk:

Диск EFI хранит EFIVARS, тут же хранится порядок загрузки. Этот диск будет включен в резервные копии и моментальные снимки, и может быть только один.
Результат:

Чтобы зайти в настройки UEFI нужно при запуске ВМ открыть консоль и нажать Esc:

Настройка сетевых подключений

Существует два основных способа подключения ВМ к сети:

через трансляцию сетевых адресов;
через ethernet-мост.

Первый способ рекомендуется к использованию в ситуациях, когда мы не планируем использовать виртуальную машину в качестве сервера каких-нибудь сетевых протоколов. Например, когда мы просто хотим протестировать процесс инсталляции ОС. Настройка механизма NAT доступна только в командной строке или через API, но не в веб-интерфейсе.

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

Второй способ подключения рекомендуется во всех остальных ситуациях. В этом случае, учитывая настройки, сделанные нами при установке PVE, сетевой интерфейс виртуальной машины будет подключён к тому же самому виртуальному коммутатору, что и сетевой интерфейс физического узла. То есть, настройки сетевой подсистемы виртуальной машины зависят от конфигурации той самой сети, в которой находится физический узел. Например, если в этой сети работает сервер DHCP, который сможет выдать нужный адрес виртуальной машине, можно указать автоматический вариант конфигурации. Если нет — придётся настраивать вручную. В отличие от первого способа, где ручной вариант настроек не предполагается (хотя, и возможен).

VirtIO

Настраивая сетевое подключение, обращаем внимание также и на то, что в списке сетевых карт, которые может эмулировать гипервизор KVM, есть пункт «VirtIO (paravirtualized)». Это специальный интерфейс, задачей которого является снижение накладных расходов на эмуляцию физической сетевой карты и реализацию драйвера для работы с ней. Между производителями современных операционных систем и произоводителями современных гипервизоров существует договорённость о поддержке единого интерфейса VirtIO, который со стороны гостевой ОС выглядит как очень простая и производительная сетевая карта, а со стороны гипервизора — как прямой интерфейс к сетевому драйверу гостевой ОС. Таким образом, производительность существенно вырастает за счёт того, что не нужно больше эмулировать несуществующее железо. Если про гостевую ОС точно известно, что она поддерживает VirtIO, имеет смысл использовать именно эту «сетевую карту».

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

Удалённый доступ к виртуальной машине

После того, как выбор параметров виртуальной машины закончен и нажата кнопка «Завершить», виртуальная машина создана. Теперь нужно получить удалённый доступ к её консоли. В PVE для удалённый доступ к «физической» консоли виртуальной машины используется протокол VNC. В качестве клиента выступает приложение на Javascript, интегрированное в окно браузера.

Миграция виртуальных машин из VMware в ALT PVE

Этот раздел описывает миграцию виртуальных машин из VMware в ALT PVE, на примере виртуальной машины с Windows 7.

Подготовка операционной системы Windows

Необходимо сделать так, чтобы система грузилась с дисков в режиме IDE.

Подготовка образа диска

Предположим что файл с образом диска называется win7.vmdk.

С помощью vmware-vdiskmanager (утилита поставляется в комплекте с VMWare Workstation) необходимо преобразовать ваш образ диска в тип "single growable virtual disk". Для этого в перейдите в папку с образами дисков и выполните следующую команду:

"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager" -r win7.vmdk -t 0 win7-pve.vmdk

Подключение образа диска к виртуальной машине на основе Directory Storage

Создайте новую виртуальную машину KVM, используя веб-интерфейс ALT PVE, но не запускайте её. Посмотрите VMID, созданной виртуальной машины (например, 100).

Скопируйте преобразованный образ win7-pve.vmdk в директорию с образами виртуальных машин /var/lib/vz/images/VMID (для этого можно воспользоваться WinSCP).

Преобразуйте файл win7-pve.vmdk в qemu формат:

# qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2

Для подключения образа диска к созданной виртуальной машине вам необходимо добавить в конфигурационный файл /etc/pve/nodes/node01/qemu-server/VMID.conf виртуальной машины следующую строчку:

unused0: locald:100/win7-pve.qcow2

где:

100 — VMID;
locald — имя хранилища в ALT PVE.

Далее перейдите в веб-интерфейс ALT PVE на вкладку «Оборудование» («Hardware»), созданной виртуальной машины. В списке устройств вы увидите неиспользуемый жёсткий диск, щелкните на него, выберете режим IDE и нажмите кнопку «Добавить» («Add»):

Подключение образа диска к виртуальной машине на основе LVM Storage

Создайте виртуальную машину, используя веб-интерфейс ALT PVE, с диском большего размера, чем диск в образе vmdk.

Посмотреть размер диска в образе можно, выполнив команду:

# qemu-img info win7-pve.vmdk 
image: win7-pve.vmdk
file format: vmdk
virtual size: 127G (136365211648 bytes)
disk size: 8.5G
cluster_size: 65536
Format specific information:
    cid: 3098509145
    parent cid: 4294967295
    create type: monolithicSparse
    extents:
        [0]:
            virtual size: 136365211648
            filename: win7-pve.vmdk
            cluster size: 65536
            format:

В данном случае необходимо создать диск в режиме IDE размером не меньше 127GB. Не запускайте виртуальную машину.

Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.

Перейдите в консоль ноды кластера и посмотрите как называется 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

Подключение образа диска к виртуальной машине на основе CEPH Storage

Создайте виртуальную машину используя веб-интерфейс ALT PVE с диском большего размера, чем диск в образе vmdk.

Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.

Перейдите в консоль ноды кластера. Имя нужного пула можно посмотреть на вкладке Datacenter->Storage->rbd-storage:

Нам необходимо отобразить образ из пула CEPH в локальное блочное устройство:

# rbd map rbd01/vm-100-disk-1
/dev/rbd0

Далее необходимо сконвертировать образ vdmk в raw-формат непосредственно на отображенное устройство:

# qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/rbd0

Проблемы с образом VMware

Кроме того образ диска может быть в формате flat, тогда при попытке конвертировать его вы получите ошибку "Operation not permitted". Вы можете посмотреть настоящий формат вашего .vdmk файла с помощью команды file. Если файл в формате flat то вы получите примерно такой вывод:

# file myVMwFlatImage-pre.vmdk
myVMwFlatImage-pre.vmdk: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
  startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 208845,
  16563015 sectors, code offset 0x48

Очень просто конвертировать такой файл из .vdmk в .qcow2 просто убрав параметр "-f vdmk" из предыдущей команды, предоставив qemu-img автоматически определить формат исходного файла:

# qemu-img convert myVMwFlatImage-pve.vmdk -O qcow2 myVMwFlatImage-pve.qcow2

Если ваша виртуальная машина KVM стартует, но не грузится с ошибкой "booting from hard disk...boot failed: not a bootable disk", то попробуйте при конвертировании вместо типа диска "single growable virtual disk" тип "preallocated virtual disk". Для этого в командной строке запустите vmvare-vdiskmanager без параметров, Вы увидите справку по работе с командой. Тип диска при конвертации задает параметр -t <disk-type>:

Disk types:
      0                   : single growable virtual disk
      1                   : growable virtual disk split in 2GB files
      2                   : preallocated virtual disk
      3                   : preallocated virtual disk split in 2GB files
      4                   : preallocated ESX-type virtual disk
      5                   : compressed disk optimized for streaming

Нам нужно выбрать тип 2:

vmware-vdiskmanager -r whatever.vmdk -t 2 whatever-pve.vmdk

Имейте ввиду, что при этом vmware-vdiskmanager создаст два файла. Первый файл whatever-pve.vmdk очень маленький, это обычный текстовый файл со ссылкой на образ. Второй файл whatever-pve-flat.vmdk, который имеет размер всего вашего виртуального диска и именно его надо конвертировать в kvm.

Адаптация новой виртуальной машины KVM

Проверьте режим работы жесткого диска для Windows — IDE, для Linux SCSI
Режим VIRTIO жесткого диска:
- Режим VIRTIO также доступен для Windows, но сразу загрузиться в этом режиме система не может
- Загрузитесь сначала в режиме IDE и выключите машину, добавьте еще один диск в режиме VIRTIO и включите машину, Windows установит нужные драйвера
- Выключите машину
- Измените режим основного диска с IDE на VIRTIO
- Загрузите систему, которая должна применить VIRTIO драйвер и выдать сообщение, что драйвер от RedHat
Включите виртуальную машину
Первое включение займет какое-то время пока будут загружены необходимые драйвера
Драйвера VIRTIO для Windows можно скачать здесь

Контейнеры (CT)

В отличие от виртуальной машины, которая с точки зрения ОС, запущенной на физическом узле, представляет собой один процесс гипервизора, процессы контейнера выполняются на том же самом ядре, что и остальные процессы ОС. То есть, если мы запустим ВМ и CT на одном и том же физическом узле PVE, процессы CT будут выполняться «рядом» с процессами гипервизора. Разница будет только в применении к процессам контейнеров механизмов изоляции — пространств имён (Namespaces) и групп управления (CGroups) — работающих на уровне ядра Linux.

Существует несколько реализаций изолированных контейнеров, базирующихся на этих механизмах. Например OpenVZ и LXC, которые отличаются развитостью и проработанностью механизмов управления. В PVE версий 4+ используется реализация LXC (до 3 версии использовалась OpenVZ), обёрнутая дополнительным собственным пользовательским интерфейсом, делающим процесс создания и обслуживания контейнеров ещё более удобным.

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

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

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

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

Второй уровень уникальности контейнера — строго говоря, не обязательный — это сетевые настройки: IP-адрес и имя узла. Обеспечивать уникальность на этом уровне не обязательно, так как у нас может быть несколько контейнеров с одинаковым именем узла, адресом IP, и даже MAC-адресом. Просто они будут запускаться в разное время. Но следить за этим будет уже не PVE, а оператор. PVE только обеспечивает возможность задания сетевых настроек контейнера при его создании.

Основная задача CT, в отличие от ВМ — не запуск полноценной ОС в виртуальной машине, а запуск отдельного приложения или сетевой службы в изолированном окружении. Поэтому доступ для обслуживания CT, как правило, удобнее осуществлять через обычный терминал — то есть, уже без участия интерфейса PVE. Для этого внутри контейнера настраивают серверную часть SSH, VNC или наоборот — клиентскую часть X-протокола. Впрочем, веб-интерфейс предоставляет для CT, так же, кстати, как и для физических узлов консоль. Обычную текстовую консоль UNIX.

Где взять готовые контейнеры

Загрузить при помощи встроенной утилиты pveam
Загрузить вручную с сайта Proxmox
Загрузить шаблоны LXC с официального сайта
Загрузить готовое окружение для решения конкретной задачи (на базе Debian) отсюда
Создать контейнер самому

Внимание! Следует учитывать, что будут работать не все контейнеры, созданные для LXC, т.к. система, на базе которой создан контейнер, должна поддерживаться скриптами PVE.

Обслуживание виртуальных окружений

Кроме создания, удаления и получения доступа к консоли существует ещё ряд важных задач по работе с виртуальными окружениями, которые веб-интерфейс PVE позволяет успешно решать. Это в первую очередь сбор статистики по расходованию ресурсов кластера PVE, управление доступом к объектам виртуальной инфраструктуры, и обеспечение бесперебойной работы в случае сбоев.

Статистика

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

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

Управление доступом

Как уже упоминалось в руководстве по установке, PVE может использовать любые базы данных пользовательских учётных записей, доступные через механизм PAM. Например, базы локальных пользователей физических узлов кластера. Кроме того, у PVE есть ещё и своя база данных учётных записей пользователей и групп. Все эти пользователи и группы являются полноправными субъектами доступа к объектам кластера. Объектами доступа являются физические узлы и хранилища данных. Полномочия субъектов доступа настраиваются через механизм ролей.

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

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

См. также Proxmox Backup Server

На радость системным администраторам PVE имеет встроенную систему резервного копирования. Добавить очередной пункт в расписание снятия резервных копий состояния виртуальных окружений и хранилищ данных можно буквально «в несколько кликов».

Важно не забыть предварительно добавить хранилище, у которого будет роль хранилища для резервных копий.

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

Снимки (снапшоты)

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

Ссылки

ПО уровня предприятия

1C • 1C 7.7 • AnyDesk • Apache Kafka • Api.php • BricsCAD • Chromium-gost • Cisco Anyconnect VPN Client • Citrix Workspace app • Citrix XenServer • Dr.Web • DraftSight • Dropbox • Enterprise Software • FineReader • Hyper-V • Jitsi Meet • Kaspersky Endpoint Security • Lotus Domino • Lotus Notes • Maple • MatLab • Micro Cap • Monit • MSSQL • NetTest • Nextcloud • Nuxeo • OpenMeetings • OracleALS40 • OwnCloud9 • PVE • PyCharm • QuestaSim • SAP GUI for Java • SAP R3 • SCOM • SecureCRT • Skype • Skype/isolation • Soft/ЯндексБраузер • Theme-mate-windows • TrueConf • Vargus • Vibe • VipNet Client • ViPNet Coordinator • ViPNet Coordinator/СПТ7 • ViPNet CSP • Vivado/Vitis • Winbox • Yandex.Disk • Zimbra • Zoom • АЦК Финансы • Битрих24 • Гарант Аэро • ГОСТ в OpenSSL • Континент-АП • КриптоПро • Лисси-Софт • Совместимость программного обеспечения • СправкиБК • Спутник Браузер • ТамТам • Установка VMware View Client • ЭП

@@ Строка 1: / Строка 1: @@
-= Что это такое =
+== Что это такое ==
 Proxmox Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора [[ruwp:KVM|KVM]] и системы контейнерной изоляции [[ruwp:LXC|LXC]]. Строго говоря, PVE это не система виртуализации, а инструментарий управления средой, в которой выполняются виртуальные окружения KVM и LXC. Основными компонентами среды являются:
@@ Строка 6: / Строка 6: @@
 * виртуальные сетевые коммутаторы, к которым подключаются сетевые интерфейсы виртуальных окружений.
-= Как это устроено =
+== Как это устроено ==
 Собственно PVE состоит из веб-интерфейса, распределённого хранилища данных конфигурации виртуальных окружений, а также утилит конфигурирования, работающих в командной строке. Все эти инструменты предназначены только для управления средой выполнения виртуальных окружений. За формирование среды отвечают компоненты системы, не входящие непосредственно в состав PVE. В первую очередь это сетевая и дисковая подсистемы, а также механизмы аутентификации.
-== Веб-интерфейс ==
+=== Веб-интерфейс ===
 Веб-интерфейс пользователя PVE предназначен для решения следующих задач:
@@ Строка 21: / Строка 21: @@
 Для аутентификации пользователей веб-интерфейса можно использовать как собственные механизмы PVE, так и PAM. Использование PAM даёт возможность, например, интегрировать PVE в домен аутентификации.
-== Хранилище данных ==
+=== Хранилище данных ===
-В случае локальной установки PVE для размещения данных виртуальных окружений можно дополнительно ничего не настраивать и использовать локальную файловую систему сервера. Но в случае кластера из нескольких серверов имеет смысл настроить сетевую или распределённую сетевую файловую систему, обеспечивающую параллельный доступ к файлам со всех серверов, на которых выполняются процессы виртуальных окружений. В качестве таких файловых систем могут выступать, например, [[ruwp:NFS|NFS]] или [[ruwp:CEPH|CEPH]].
+В случае локальной установки PVE для размещения данных виртуальных окружений можно дополнительно ничего не настраивать и использовать локальную файловую систему сервера. Но в случае кластера из нескольких серверов имеет смысл настроить сетевую или распределённую сетевую файловую систему, обеспечивающую параллельный доступ к файлам со всех серверов, на которых выполняются процессы виртуальных окружений. В качестве таких файловых систем могут выступать, например, [[NFS]] или [[Ceph|CEPH]].
-==== Подключение общего хранилища iSCSI (Multipath) с использованием LVM ====
-Настройка iSCSI-target на базе ALT подробно описана в [[GFS2 на iSCSI с Multipath#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_iSCSI_target|этой статье]].<br>
-{{Attention|iSCSI initiator настраивается средствами ALT PVE.<br> Сервис iscsid запускается средствами ALT PVE и не должен присутствовать в атозагрузке}}
-Исходные данные:<br>
-* Настроенный кластер ALT PVE
-* Настроенный iSCSI target
-Для добавления iSCSI устройства надо зайти в web-интерфейс ALT PVE в раздел Datacenter -> Storage -> Add -> iSCSI:<br>
-[[Файл:Add iSCSI.png|Добавление iSCSI-устройства]]
-*ID: Имя добавляемого устройства, может быть любым, но изменить его позже нельзя
-*Portal: Адрес iSCSI сервера
-*Target: Выпадающий список ресурсов, отдаваемых iSCSI сервером
-*Nodes: Каким нодам будет доступно данное хранилище
-*Enable: Вкл/Выкл хранилище
-*Use LUNs directly: Использование LUN напрямую, галочку надо снять
-Ту же процедуру надо проделать для второго адреса iSCSI сервера.<br>
-После этого на всех нодах появятся два блочных устройства.<br>
-Далее необходимо настроить Multipath по этой [[GFS2 на iSCSI с Multipath#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0_Multipath|инструкции]]<br>
-Далее переходим в консоль на любой ноде для настройки LVM.<br>
-Для корректной работы LVM и Multipath говорим LVM не сканировать наши iSCSI-диски (sd*):<br>
-В файл {{path|/etc/lvm/lvm.conf}} добавляем:
-<pre>devices {
-...
-filter = [ "r|/dev/sd|" ]
-...
-}</pre>
-Инициализируем блочные устройства для использования в LVM:
-<pre># pvcreate /dev/mapper/mpatha</pre>
-Создаём группу томов 'sharedsv':
-<pre># vgcreate sharedsv /dev/mapper/mpatha</pre>
-Далее переходим в web-интерфейс ALT PVE в раздел Datacenter -> Storage -> Add -> LVM:<br>
-[[Файл:ALT PVE add LVM.png]]
-*ID: Имя добавляемого устройства, может быть любым, но изменить его позже нельзя
-*Base Storage: Выбираем 'Existing volume groups'
-*Volume group: Выпадающий список LVM разделов, выбираем созданный нами 'sharedsv'
-*Content: Что разрешено хранить на данном хранилище
-*Nodes: Каким нодам будет доступно данное хранилище
-*Enable: Вкл/Выкл хранилище
-*Shared: Делает хранилище доступным для всех нод
-При таком подключении LVM хранилище общедоступно, виртуальные машины могут хранить на нем образы дисков и доступна Online-миграция виртуальных машин между нодами.
-== Сетевая подсистема ==
+=== Сетевая подсистема ===
 В отличие от хранилища данных, сетевая подсистема требует специальной настройки даже в случае локальной установки PVE. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному же устройству, обеспечивающему соединение с общей сетью передачи данных. Обычно в качестве такого устройства выступает Ethernet-мост.
-= Установка и настройка PVE =
+== Установка и настройка PVE ==
-В качестве сервера для развёртывания PVE нужно использовать серверверный дистрибутив Альт на базе 8-й платформы и доустановить необходимые пакеты штатным способом любым штатным способом ({{cmd|apt-get}}, {{cmd|aptitude}}, {{cmd|synaptic}}) установить пакет {{cmd|pve-manager}}. Все необходимые компоненты при этом будут установлены автоматически. Также следует убедиться в том, что пакет systemd обновлён до версии, находящейся в репозитории P8.
+=== Альт Сервер Виртуализации 9/10 ===
+В качестве сервера для развертывания PVE удобно использовать дистрибутив [[Альт_Сервер_Виртуализации_10|Альт Сервер Виртуализации]] (Сервер виртуализации). Он уже содержит все необходимые компоненты.
+{{Note| Компоненты PVE будут установлены в систему, если при установке дистрибутива выбрать профиль '''Виртуальное окружение Proxmox'''.}}
+==== Настройка узлов кластера ====
+PVE должен быть установлен на всех узлах. Следует убедиться, что каждый узел установлен с окончательным именем хоста и IP-конфигурацией. Изменение имени хоста и IP-адреса невозможно после создания кластера.
+{{Note|Локальная установка — частный случай кластера из одного узла. }}
+===== Настройка преобразования имен =====
+Необходимо обеспечить взаимно однозначное прямое и обратное преобразование имен для всех узлов кластера. Крайне желательно использовать DNS, в крайнем случае, можно обойтись соответствующими записями в локальных файлах {{path|/etc/hosts}}:
+<syntaxhighlight lang="bash"># echo "192.168.88.186 pve01.localdomain pve01" >> /etc/hosts
+# echo "192.168.88.90 pve02.localdomain pve02" >> /etc/hosts
+# echo "192.168.88.70 pve03.localdomain pve03" >> /etc/hosts</syntaxhighlight>
+{{Note| Имя машины не должно присутствовать в файле {{path|/etc/hosts}} разрешающимся в 127.0.0.1. }}
+===== Настройка сетевой подсистемы =====
+На всех узлах кластера необходимо настроить Ethernet-мост.
+{{Attention|Мосту должно быть назначено имя vmbr0 и оно должно быть одинаково на всех узлах.}}
+{{Attention|При использовании дистрибутива Альт Сервер Виртуализации 9/10 интерфейс vmbr0 создаётся и настраивается в процессе установки.}}
+Для настройки Ethernet-моста с именем vmbr0, можно выполнить следующие команды:
+<syntaxhighlight lang="bash"># 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
+</syntaxhighlight>
+Имя интерфейса, обозначенного здесь как enp0s3, следует указать в соответствии с реальной конфигурацией сервера.
+IP-адрес для интерфейса будет взят из {{path|/etc/net/ifaces/enp0s3/ipv4address}}.
+В опции HOST файла {{path|/etc/net/ifaces/vmbr0/options}} нужно указать те интерфейсы, которые будут входить в мост. Если в него будут входить интерфейсы, которые до этого имели IP-адрес (например, enp0s3), то этот адрес должен быть удален (например, можно закомментировать содержимое файла {{path|/etc/net/ifaces/enp0s3/ipv4address}}).
+Для того, чтобы изменения вступили в силу необходим перезапуск сервиса network:
+<syntaxhighlight lang="bash"># systemctl restart network</syntaxhighlight>
+При старте сети сначала поднимаются интерфейсы, входящие в мост, затем сам мост (автоматически).
+==== Создание кластера PVE ====
+Кластер не создается автоматически на только что установленном узле PVE. Он должен быть создан через интерфейс командной строки с любого из узлов PVE, который будет частью кластера. После того как кластер создан и узлы добавлены в этот кластер, большая часть управления может выполняться через графический интерфейс.
+Для правильного функционирования кластера необходимо как минимум три узла. С тремя узлами возможен кворум, который позволяет кластерам обеспечивать работоспособность и функционирование должным образом.
+На «головном» узле кластера необходимо выполнить команды инициализации конкретного кластера PVE, в данном случае — «pve», выполнив команды (это можно сделать и из веб-интерфейса «Центр обработки данных» → «Кластер» → «Создать кластер» («Datacenter» → «Cluster» → «Create claster»), запустив перед этим все необходимые службы (см.ниже)):
+<syntaxhighlight lang="bash"># systemctl start pve-cluster
+# pvecm create pve
+</syntaxhighlight>
+Проверка:
+<syntaxhighlight lang="bash"># pvecm status
+Quorum information
+------------------
+Date:             Fri Sep 27 16:29:06 2019
+Quorum provider:  corosync_votequorum
+Nodes:            1
+Node ID:          0x00000001
+Ring ID:          1/4
+Quorate:          Yes
+Votequorum information
+----------------------
+Expected votes:   1
+Highest expected: 1
+Total votes:      1
+Quorum:           1
+Flags:            Quorate
+Membership information
+----------------------
+Nodeid      Votes Name
+x00000001          1 192.168.88.186 (local)
+</syntaxhighlight>
+Команда создания кластера создает файл настройки {{path|/etc/pve/corosync.conf}}. По мере добавления узлов в кластер файл настройки будет автоматически пополняться информацией об узлах.
+Для добавления узлов в кластер, необходимо на «подчинённых» узлах выполнить следующие команды:
+<syntaxhighlight lang="bash"># systemctl start pve-cluster
+# pvecm add pve01
+</syntaxhighlight>
+где pve01 — имя или IP-адрес «головного» узла.
+При добавлении узла в кластер, потребуется ввести пароль администратора главного узла кластера:
+<syntaxhighlight lang="bash"># pvecm add 192.168.88.186
+Please enter superuser (root) password for '192.168.88.186':
+                                                        Password for root@192.168.88.186: ***
+Establishing API connection with host '192.168.88.186'
+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-1573727779.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.
+</syntaxhighlight>
+После добавления узлов в кластер, файл настройки кластера в {{path|/etc/pve/corosync.conf}} должен содержать информацию об узлах кластера.
+На всех узлах кластера необходимо запустить службы кластера и добавить их в список служб, запускаемых при старте узла:
+<syntaxhighlight lang="bash"># systemctl start lxc lxcfs lxc-net lxc-monitord qmeventd pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pvescheduler ksmtuned
+# systemctl enable corosync lxc lxcfs lxc-net lxc-monitord qmeventd pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests pvescheduler ksmtuned
+</syntaxhighlight>
+{{Attention|При использовании дистрибутивов Альт Сервер Виртуализации 9.2/10.0 все указанные службы добавляются и запускаются автоматически. Веб-интерфейс PVE должен быть доступен сразу после перезагрузки после установки дистрибутива.}}
+Дальнейшие настройки кластера удобно делать через веб-интерфейс.
+Веб-интерфейс PVE доступен по адресу https://<внешний-IP-адрес>:8006. Потребуется пройти аутентификацию (логин по умолчанию: root, пароль указывается в процессе установки):
+[[Изображение:Pve_auth.png|Аутентификация в веб-интерфейсе PVE]]
+=== Альт на базе 8-й платформы (p8) ===
+В качестве сервера для развёртывания PVE нужно использовать серверный дистрибутив Альт на базе 8-й платформы и доустановить необходимые пакеты штатным способом любым штатным способом ({{cmd|apt-get}}, {{cmd|aptitude}}, {{cmd|synaptic}}) установить пакет {{pkg|pve-manager}}. Все необходимые компоненты при этом будут установлены автоматически. Также следует убедиться в том, что пакет {{pkg|systemd}} обновлён до версии, находящейся в репозитории [[P8]].
+На всех нодах:
+<syntaxhighlight lang="bash"># apt-get install pve-manager</syntaxhighlight>
 Рассмотрим настройку кластера PVE. Локальную установку будем считать частным случаем кластера из одного узла.
-== Настройка сетевой подсистемы ==
+==== Настройка сетевой подсистемы ====
-: Если в файле options интерфейса не задан TYPE=, pve-manager завершается с ошибкой
+{{Note|Если в файле options интерфейса не задан TYPE, pve-manager завершается с ошибкой.}}
 Сначала на всех узлах кластера настроим Ethernet-мост в соответствии с [[Etcnet#Настройка Ethernet-моста|руководством]]:
-<pre>
+<syntaxhighlight lang="bash">
-# mkdir /etc/net/ifaces/vmbr0
+# ip=$(hostname -i)
-# mv /etc/net/ifaces/eth0/* /etc/net/ifaces/vmbr0/
+# cat > /etc/net/ifaces/ens18/options << EOF
-# cp /etc/net/ifaces/vmbr0/options /etc/net/ifaces/eth0/
+TYPE=eth
-# cat <<EOF > /etc/net/ifaces/vmbr0/options
+EOF
+# mkdir -p /etc/net/ifaces/vmbr0
+# cat > /etc/net/ifaces/vmbr0/options << EOF
 BOOTPROTO=static
+TYPE=bri
+HOST='ens18'
 CONFIG_WIRELESS=no
 CONFIG_IPV4=yes
-HOST='eth0'
+EOF
-ONBOOT=yes
+# cat > /etc/net/ifaces/vmbr0/ipv4address << EOF
-TYPE=bri
+$ip/21
+EOF
+# cat > /etc/net/ifaces/vmbr0/ipv4route << EOF
+default via 10.88.8.1
+EOF
+# cat > /etc/net/ifaces/vmbr0/resolv.conf << EOF
+search example.com test.com
+nameserver 10.0.0.0
 EOF
 # cat <<EOF  > /etc/net/ifaces/vmbr0/brctl
@@ Строка 92: / Строка 191: @@
 setfd AUTO 0
 EOF
-</pre>
+</syntaxhighlight>
-Имя интерфейса, обозначенного здесь как eth0, следует указать в соответствии с реальной конфигурацией сервера.
-При установленных пакетах {{pkg|alterator-net-eth}} и {{pkg|alterator-net-bridge}} вместо всего этого можно просто воспользоваться web-интерфейсом.
+Имя интерфейса, обозначенного здесь как ens18, следует указать в соответствии с реальной конфигурацией сервера.
-Основная часть разработки PVE ведётся под ОС Debian, и в связи с этим в свежих версиях PVE иногда возникают забавные нюансы. Так в текущей версии конфигурация Ethernet-мостов и информация о временны́х зонах считывается из специфичных для Debian и его производных конфигурационных файлов {{path|/etc/network/interfaces}} и {{path|/etc/timezone}}. Поэтому, пока ошибка не исправлена, настройки придётся продублировать:
+{{Attention|Данная последовательность команд приводит к желаемому результату только в том случае, если интерфейс, который является хостом для моста, ранее не настраивался. В противном случае необходимо также удалить или очистить ipv4address, ipv4route и resolv.conf, иначе могут возникнуть проблемы при дальнейшей настройке.   }}
-<pre>
+При установленных пакетах {{pkg|alterator-net-eth}} и {{pkg|alterator-net-bridge}} вместо всего этого можно просто воспользоваться веб-интерфейсом.
-# mkdir /etc/network
+{{Attention|При этом нужно учесть, что мост, созданный через веб-интерфейс, будет иметь имя br*, в то время как для PVE стандартом является vmbr*. Это может приводить к труднодиагностируемым и трудноразрешимым проблемам, препятствующим нормальному запуску PVE.}}
-# printf "\nauto vmbr0\n\tiface vmbr0 inet static\n\taddress 10.0.0.251\n\tnetmask 255.255.255.0\n\tgateway 10.0.0.1\n\tbridge_ports eth0\n\tbridge_stp off\n\tbridge_fd 0\n" >> /etc/network/interfaces
-# . /etc/sysconfig/clock
-# echo $ZONE > /etc/timezone
-# ln -sf /usr/share/zoneinfo/$ZONE /etc/localtime
-</pre>
 Далее необходимо обеспечить взаимно однозначное прямое и обратное преобразование имён для всех узлов кластера. Крайне желательно использовать DNS, но в крайнем случае можно обойтись соответствующими записями в локальных файлах {{path|/etc/hosts}}:
+<syntaxhighlight lang="bash">
+# echo "10.88.8.251 pve1.localdomain pve1" >> /etc/hosts
+# echo "10.88.8.252 pve2.localdomain pve2" >> /etc/hosts
+# echo "10.88.8.253 pve3.localdomain pve3" >> /etc/hosts
+</syntaxhighlight>
-<pre>
+При этом имя машины '''НЕ''' должно присутствовать в файле {{path|/etc/hosts}}, разрешающимся в 127.0.0.1!
-# echo "10.0.0.251 pve1.localdomain pve1" >> /etc/hosts
-# echo "10.0.0.252 pve2.localdomain pve2" >> /etc/hosts
-</pre>
-При этом имя машины '''НЕ''' должно присутствовать в файле /etc/hosts, разрешающимся в 127.0.0.1!
-== Настройка взаимодействия компонентов PVE ==
+==== Настройка взаимодействия компонентов PVE ====
-В качестве транспорта для передачи команд между узлами кластера применяется протокол SSH. Если мы настраиваем локальную установку PVE, ничего специального делать не нужно, а если узлов в кластере будет несколько, необходимо на каждом узле разрешить передачу переменной окружения {{path|LC_PVE_TICKET}}:
+В качестве транспорта для передачи команд между узлами кластера применяется протокол SSH.
-<pre>
+Для передачи команд между узлами кластера необходимо обеспечить взаимную беспарольную аутентификацию пользователя root. Это можно сделать вручную, а можно при добавлении нового узла в кластер PVE разрешить на «ведущем» узле вход пользователя root по паролю и ввести пароль. После этого взаимная беспарольная аутентификация root будет настроена автоматически утилитами PVE, и вход root по паролю можно будет снова отключить.
-# N=$(($(sed -n '/^AcceptEnv/{=}' /etc/openssh/sshd_config | tail -1) + 1)); sed -i "${N}i AcceptEnv LC_PVE_TICKET\n" /etc/openssh/sshd_config
-# N=$(($(sed -n '/^[[:space:]]*SendEnv/{=}' /etc/openssh/ssh_config | tail -1) + 1)); sed -i "${N}i \ \ \ \ SendEnv LC_PVE_TICKET\n" /etc/openssh/ssh_config
-# systemctl restart sshd
-</pre>
-Кроме того, для передачи команд между узлами кластера необходимо обеспечить взаимную беспарольную аутентификацию пользователя root. Это можно сделать вручную, а можно при добавлении нового узла в кластер PVE разрешить на «ведущем» узле вход пользователя root по паролю и ввести пароль. После этого взаимная беспарольная аутентификация root будет настроена автоматически утилитами PVE, и вход root по паролю можно будет снова отключить.
 Важно понимать, что в сконфигурированном кластере PVE все узлы равноправны. «Ведущим», «головным» и так далее один из узлов становится только в момент добавления в кластер нового узла. После добавления новый узел может стать таким же ведущим при проведении следующей процедуры добавления очередного узла в кластер.
@@ Строка 132: / Строка 218: @@
 Теперь осталось настроить ещё два компонента системы, которые утилиты PVE пока не могут полностью автоматически настроить при запуске кластера. Это демон {{cmd|rrdcached}}, отвечающий за хранение данных мониторинга активности подсистем кластера, и {{cmd|corosync}} — комплекс ПО, обеспечивающий в пределах кластера элементы высокой доступности.
-<pre>
+Выполнить на всех нодах:
-# cp /usr/share/doc/pve-cluster/rrdcached.sysconfig /etc/sysconfig/rrdcached
+<syntaxhighlight lang="bash">
-# mkdir -p /var/lib/rrdcached/{db,journal}
+# sh /usr/share/doc/pve-cluster/pve-firsttime
+# rm -f /etc/corosync/corosync.conf
+</syntaxhighlight>
+Для версии pve-cluster 6.0  и выше:
+<syntaxhighlight lang="bash">
 # rm -f /etc/corosync/corosync.conf
-</pre>
+</syntaxhighlight>
 Конфигурационный файл {{cmd|corosync}} после этого будет создан автоматически при инициализации кластера PVE.
-== Запуск служб кластера ==
+==== Запуск служб кластера ====
 Запускаем службы кластера и настраиваем их автоматический запуск при старте узла:
-<pre>
+<syntaxhighlight lang="bash">
-# systemctl start syslogd ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
+# systemctl start ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
-# systemctl enable syslogd ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
+# systemctl enable ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
-</pre>
+</syntaxhighlight>
+Для версии 6.0 (в связи с заменой ntpd на chrony):
+<syntaxhighlight lang="bash">
+# systemctl start chronyd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
+# systemctl enable chronyd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target
+</syntaxhighlight>
+Также на версии 6.0 может потребоваться предварительно доустановить {{pkg|nfs-clients}}.
 Далее, на «головном» (см. выше) узле кластера выполняем команды собственно инициализации конкретного кластера PVE, в данном случае — «mypve»:
+<syntaxhighlight lang="bash">
+# systemctl start pve-cluster
+# ip=$(hostname -i)
+# pvecm create pve --ring0_addr $ip
+</syntaxhighlight>
-<pre>
+{{Attention|Если после переустановки pve не возможно инициализировать кластер: cluster config '/etc/pve/corosync.conf' already exists удалите файл {{path|/etc/pve/corosync.conf}}. }}
+Для версии pve-cluster 6.0 и выше:
+<syntaxhighlight lang="bash">
 # systemctl start pve-cluster
-# pvecm create mypve
+# ip=$(hostname -i)
-</pre>
+# pvecm create pve
+</syntaxhighlight>
+Если на данном этапе получили ошибку, загляните на форум за [https://forum.altlinux.org/index.php?topic=43400.0 возможным решением]
 На «подчинённых» (см. выше) узлах:
+{{Attention|Если при добавлении узла возникает ошибка: * cluster config '/etc/pve/corosync.conf' already exists
-<pre>
+ необходимо добавить опцию -force  (В версии 6.0.7 данной опции нет, что подтверждает man) }}
-# systemctl start corosync pve-cluster
+<syntaxhighlight lang="bash">
-# pvecm add <головной_узел>
+# ip=$(hostname -i)
-</pre>
+# systemctl start pve-cluster
+# pvecm add 10.88.10.251 --ring0_addr $ip
+</syntaxhighlight>
+Для версии pve-cluster 6.0 и выше:
+<syntaxhighlight lang="bash">
+# systemctl start pve-cluster
+# pvecm add 10.88.10.251 --use_ssh
+</syntaxhighlight>
 Далее, запускаем остальные службы и добавляем их в список служб, запускаемых при старте узла:
-<pre>
+<syntaxhighlight lang="bash">
-# systemctl start lxc lxc-net lxc-monitord pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy
+# systemctl start lxc lxc-net lxc-monitord pve-lxc-syscalld pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy ksmtuned
-# systemctl enable corosync lxc lxc-net lxc-monitord pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests
+# systemctl enable corosync lxc lxc-net lxc-monitord pve-lxc-syscalld pve-cluster pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy pve-guests ksmtuned
-</pre>
+</syntaxhighlight>
 Дальнейшие настройки кластера удобно делать через веб интерфейс.
@@ Строка 173: / Строка 287: @@
 [[Файл:Pve-first-login.png|900px|Экран входа пользователя в веб-интерфейс PVE]]
-= Применение PVE =
+== Применение PVE ==
-В ходе работы с веб-интерфейсом PVE оператору приходится иметь дело со следующими основными объектами: физическими узлами, виртуальными окружениями, хранилищами данных и субъектами авторизации. Так как PVE является средством управления виртуальными окружениями, рассматривать взаимодействие компонентов мы будем относительно них. Виртуальные окружения под управлением PVE бывают двух типов: полностью виртуализированные, управляемые гипервизором kvm, и изолированные окружения выполняющиеся непосредственно на основном ядре ОС физического узла. Первые в терминах PVE называются VM (виртуальные машины), а вторые — CT (контейнеры, ConTainers). Начнём с VM.
-== VM: виртуальные машины kvm ==
-Виртуальные машины, управляемые гипервизором kvm, с точки зрения операционной системы физического узла, на котором они выполняются, представляют собой один процесс гипервизора kvm. Они взаимодействуют с физическим оборудованием не напрямую, а только через гипервизор. Всё оборудование, которое доступно операционной системе внутри виртуальной машины, включая процессор и память, является виртуальным. Даже виртуальная сетевая карта подключается виртуальным кабелем к виртуальному коммутатору. Дисковые контроллеры тоже являются виртуальными, а дисковые накопители обычно представляют собой файлы на файловой системе физического узла, на котором выполняется процесс гипервизора.
+В ходе работы с веб-интерфейсом PVE оператору приходится иметь дело со следующими основными объектами: физическими узлами, виртуальными окружениями, хранилищами данных и субъектами авторизации. Так как PVE является средством управления виртуальными окружениями, рассматривать взаимодействие компонентов мы будем относительно них. Виртуальные окружения под управлением PVE бывают двух типов: полностью виртуализированные, управляемые гипервизором KVM, и изолированные окружения выполняющиеся непосредственно на основном ядре ОС физического узла. Первые в терминах PVE называются ВМ (виртуальные машины), а вторые — CT (контейнеры, ConTainers).
 === Хранилища данных ===
-В случае, когда PVE управляет не одним физическим узлом, а кластером физических узлов, должна обеспечиваться возможность миграции VM с одного физического узла на другой. Миграция представляет собой заморозку состояния VM на одном узле, перенос данных и конфигурации на другой узел, и разморозку состояния VM на новом месте. Так как виртуальные дисковые накопители VM могут занимать значительный объём, удобно в пределах среды виртуализации PVE оперировать не локальными файловыми системами физических узлов, а хранилищами данных, доступными со всех узлов кластера. Кроме того, очень удобно, когда образы загрузочных инсталляционных дисков ОС, которые мы развёртываем на виртуальных машинах, также были доступны сразу на всех узлах кластера. Чтобы не приходилось копировать сотни мегабайт файлов .iso с машины на машину, когда нам захочется развернуть несколько однотипных VM на разных физических узлах.
+В случае, когда PVE управляет не одним физическим узлом, а кластером физических узлов, должна обеспечиваться возможность миграции ВМ с одного физического узла на другой. Миграция представляет собой заморозку состояния ВМ на одном узле, перенос данных и конфигурации на другой узел, и разморозку состояния ВМ на новом месте. Так как виртуальные дисковые накопители ВМ могут занимать значительный объём, удобно в пределах среды виртуализации PVE оперировать не локальными файловыми системами физических узлов, а хранилищами данных, доступными со всех узлов кластера. Кроме того, очень удобно, когда образы загрузочных инсталляционных дисков ОС, которые мы развёртываем на виртуальных машинах, также были доступны сразу на всех узлах кластера. Чтобы не приходилось копировать сотни мегабайт файлов .iso с машины на машину, когда нам захочется развернуть несколько однотипных ВМ на разных физических узлах.
 Хранилищами данных удобно управлять через веб-интерфейс. В качестве бэкенда хранилищ PVE может использовать:
@@ Строка 202: / Строка 312: @@
 Сразу после инициализации кластера в пределах каждого из узлов нам доступно одно локальное хранилище данных. Этого уже вполне достаточно для начала работы.
-=== Создание виртуальной машины ===
+==== Подключение общего хранилища iSCSI (Multipath) с использованием LVM ====
+Настройка iSCSI-target на базе ALT подробно описана в [[GFS2_на_iSCSI_с_Multipath#Настройка_iSCSI_target|этой статье]].
+{{Attention|iSCSI initiator настраивается средствами ALT PVE.<br> Сервис iscsid запускается средствами ALT PVE и не должен присутствовать в автозагрузке.}}
+Исходные данные:
+* настроенный кластер ALT PVE
+* настроенный iSCSI target
+Для добавления iSCSI устройства надо зайти в веб-интерфейс ALT PVE в раздел «Центр обработки данных» → «Хранилище» → «Добавить» → «iSCSI» («Datacenter» → «Storage» → «Add» → «iSCSI»):
+[[Файл:Add iSCSI.png|Добавление iSCSI-устройства]]
+*ID — имя добавляемого устройства, может быть любым, но изменить его позже нельзя;
+*Portal — адрес iSCSI сервера;
+*Цель (Target) — выпадающий список ресурсов, отдаваемых iSCSI сервером;
+*Узлы (Nodes) — каким нодам будет доступно данное хранилище;
+*Включить (Enable) — Вкл/Выкл хранилище;
+*Использовать LUN напрямую (Use LUNs directly) — использование LUN напрямую, отметку надо снять.
+Ту же процедуру надо проделать для второго адреса iSCSI-сервера.
+После этого на всех нодах появятся два блочных устройства.
+Затем необходимо настроить Multipath по этой [[GFS2_на_iSCSI_с_Multipath#Настройка_Multipath|инструкции]]
+Далее переходим в консоль на любой ноде для настройки LVM.
+Для корректной работы LVM и Multipath говорим LVM не сканировать наши iSCSI-диски (sd*). В файл {{path|/etc/lvm/lvm.conf}} добавляем:
+<syntaxhighlight lang="text">devices {
+...
+filter = [ "r|/dev/sd|" ]
+...
+}</syntaxhighlight>
+Инициализируем блочные устройства для использования в LVM:
+<syntaxhighlight lang="bash"># pvcreate /dev/mapper/mpatha</syntaxhighlight>
+Создаём группу томов 'sharedsv':
+<syntaxhighlight lang="bash"># vgcreate sharedsv /dev/mapper/mpatha</syntaxhighlight>
+Далее переходим в веб-интерфейс ALT PVE в раздел «Центр обработки данных» → «Хранилище» → «Добавить» → «LVM» («Datacenter» → «Storage» → «Add» → «LVM»):
-Прежде чем создать в интерфейсе PVE виртуальную машину (VM), необходимо определиться со следующими моментами:
+[[Файл:ALT PVE add LVM.png]]
+*ID — имя добавляемого устройства, может быть любым, но изменить его позже нельзя;
+*Основное хранилище (Base Storage) — выбираем 'Existing volume groups';
+*Группа томов (Volume group) — выпадающий список LVM разделов, выбираем созданный нами 'sharedsv';
+*Содержимое (Content) — что разрешено хранить на данном хранилище;
+*Узлы (Nodes) — каким нодам будет доступно данное хранилище;
+*Включить (Enable) — Вкл/Выкл хранилище;
+*Общий доступ (Shared) — делает хранилище доступным для всех нод.
+При таком подключении LVM-хранилище общедоступно, виртуальные машины могут хранить на нем образы дисков и доступна Online-миграция виртуальных машин между нодами.
+=== ВМ: виртуальные машины KVM ===
+Виртуальные машины, управляемые гипервизором KVM, с точки зрения операционной системы физического узла, на котором они выполняются, представляют собой один процесс гипервизора KVM. Они взаимодействуют с физическим оборудованием не напрямую, а только через гипервизор. Всё оборудование, которое доступно операционной системе внутри виртуальной машины, включая процессор и память, является виртуальным. Даже виртуальная сетевая карта подключается виртуальным кабелем к виртуальному коммутатору. Дисковые контроллеры тоже являются виртуальными, а дисковые накопители обычно представляют собой файлы на файловой системе физического узла, на котором выполняется процесс гипервизора.
+==== Создание виртуальной машины ====
+Прежде чем создать в интерфейсе PVE виртуальную машину (ВМ), необходимо определиться со следующими моментами:
 * откуда будет загружен инсталлятор ОС, которую мы будем устанавливать внутрь виртуальной машины;
-* на каком физическом узле будет выполняться процесс гипервизора kvm;
+* на каком физическом узле будет выполняться процесс гипервизора KVM;
 * на каком хранилище данных будут располагаться образы дисков виртуальной машины.
-Все остальные параметры VM относятся к конфигурации виртуального компьютера и могут быть определены по ходу процесса создания VM.
+Все остальные параметры ВМ относятся к конфигурации виртуального компьютера и могут быть определены по ходу процесса создания ВМ.
 Так как хранилища данных у нас пока только локальные, определимся с физическим узлом на котором будет создано виртуальное окружение. Чтобы установить ОС на виртуальную машину, расположенную на этом узле, нужно обеспечить возможность загрузки инсталлятора на этой виртуальной машине. Для этого загрузим ISO-образ инсталлятора в хранилище данных выбранного физического узла. Это также удобно делать через веб-интерфейс.
@@ Строка 216: / Строка 379: @@
 [[Файл:Pve-iso-pick.png|900px|Загрузка файла .iso в хранилище данных]]
-Теперь, когда все предварительные действия выполнены, нажимаем в веб-интерфейсе PVE кнопку «Создать VM» в правом верхнем углу.
+Теперь, когда все предварительные действия выполнены, нажимаем в веб-интерфейсе PVE кнопку «Создать ВМ» в правом верхнем углу.
 [[Файл:Pve-vm-create-basic.png|900px|Добавление новой виртуальной машины]]
-Процесс создания VM оформлен в виде «мастера», привычного для пользователей систем управления виртуальными машинами. Проходя по очереди по вкладкам, выбираем, соответственно, уникальное имя VM, шаблон настроек ОС, файл .iso, с которого будет загружаться инсталлятор ОС, тип дискового контроллера, формат и размер образа виртуального жёсткого диска, хранилище данных, на котором он будет располагаться, количество ядер процессора и размер оперативной памяти и так далее. Отдельное внимание обратим на настройки типа подключения дисковых накопителей настройки доступа к сети.
+Процесс создания ВМ оформлен в виде «мастера», привычного для пользователей систем управления виртуальными машинами. Проходя по очереди по вкладкам, выбираем, соответственно, уникальное имя ВМ, шаблон настроек ОС, файл .iso, с которого будет загружаться инсталлятор ОС, тип дискового контроллера, формат и размер образа виртуального жёсткого диска, хранилище данных, на котором он будет располагаться, количество ядер процессора и размер оперативной памяти и так далее. Отдельное внимание обратим на настройки типа подключения дисковых накопителей настройки доступа к сети.
+===== Создание ВМ с UEFI =====
+{{Note|По умолчанию, в качестве прошивки, используется SeaBIOS, который эмулирует BIOS x86. Можно также выбрать OVMF, который эмулирует UEFI.}}
-=== Настройка сетевых подключений ===
+# Создать ВМ стандартным способом.
+# Поменять тип прошивки на uefi (на вкладке «Оборудование» («Hardware») выбрать строку BIOS и поменять значение на «OVMF (UEFI)»):
+#:[[Файл:Pve-ovmf1.png|PVE. Настройка BIOS]]
+# Добавить в конфигурацию ВМ EFI Disk:
+#:[[Файл:Pve-efi-disk.png|PVE. Добавление диска EFI]]
+#:Диск EFI хранит EFIVARS, тут же хранится порядок загрузки. Этот диск будет включен в резервные копии и моментальные снимки, и может быть только один.
+# Результат:
+#:[[Файл:Pve-ovmf2.png|PVE. ВМ с UEFI]]
-Существует два основных способа подключения VM к сети:
+Чтобы зайти в настройки UEFI нужно при запуске ВМ открыть консоль и нажать '''Esc''':
+[[Файл:Pve-ovmf3.png|800px|PVE. Настройки UEFI]]
+==== Настройка сетевых подключений ====
+Существует два основных способа подключения ВМ к сети:
 * через трансляцию сетевых адресов;
 * через ethernet-мост.
-Первый способ рекомендуется к использованию в ситуациях, когда мы не планируем использовать виртуальную машину в качестве сервера каких-нибудь сетевых протоколов. Например, когда мы просто хотим протестировать процесс инсталляции ОС. Механизм NAT будет настроен автоматически, без дополнительных действий оператора, достаточно будет просто в процессе создания виртуальной машины поставить радиокнопку на вкладке «Сеть» в положение «NAT mode».
+Первый способ рекомендуется к использованию в ситуациях, когда мы не планируем использовать виртуальную машину в качестве сервера каких-нибудь сетевых протоколов. Например, когда мы просто хотим протестировать процесс инсталляции ОС. Настройка механизма NAT доступна только в командной строке или через API, но не в веб-интерфейсе.
-В процессе настройки гостевой ОС нужно будет выбрать автоматический вариант настройки сетевых адресов по протоколу DHCP. Со стороны гипервизора kvm будет поднят сервер DHCP, который выдаст гостевой системе сетевой адрес и маршруты. Также, со стороны гипервизора будет автоматически настроена трансляция всех адресов выданных встроенным сервером DHCP. Таким образом приложения, работающие в гостевой ОС, получат доступ ко всем сетям, к которым имеет доступ ОС физического узла, причём со стороны этих сетей они будут маскироваться под адресом самого физического узла.
+В процессе настройки гостевой ОС нужно будет выбрать автоматический вариант настройки сетевых адресов по протоколу DHCP. Со стороны гипервизора KVM будет поднят сервер DHCP, который выдаст гостевой системе сетевой адрес и маршруты. Также, со стороны гипервизора будет автоматически настроена трансляция всех адресов выданных встроенным сервером DHCP. Таким образом приложения, работающие в гостевой ОС, получат доступ ко всем сетям, к которым имеет доступ ОС физического узла, причём со стороны этих сетей они будут маскироваться под адресом самого физического узла.
 Второй способ подключения рекомендуется во всех остальных ситуациях. В этом случае, учитывая настройки, сделанные нами при установке PVE, сетевой интерфейс виртуальной машины будет подключён к тому же самому виртуальному коммутатору, что и сетевой интерфейс физического узла. То есть, настройки сетевой подсистемы виртуальной машины зависят от конфигурации той самой сети, в которой находится физический узел. Например, если в этой сети работает сервер DHCP, который сможет выдать нужный адрес виртуальной машине, можно указать автоматический вариант конфигурации. Если нет — придётся настраивать вручную. В отличие от первого способа, где ручной вариант настроек не предполагается (хотя, и возможен).
@@ Строка 237: / Строка 417: @@
 [[Файл:Pve-vm-create-net.png|900px|Настройки доступа в сеть виртуальной машины]]
-=== VirtIO ===
+==== VirtIO ====
-Настраивая сетевое подключение, обращаем внимание также и на то, что в списке сетевых карт, которые может эмулировать гипервизор kvm, есть пункт «VirtIO (paravirtualized)». Это специальный интерфейс, задачей которого является снижение накладных расходов на эмуляцию физической сетевой карты и реализацию драйвера для работы с ней. Между производителями современных операционных систем и произоводителями современных гипервизоров существует договорённость о поддержке единого интерфейса VirtIO, который со стороны гостевой ОС выглядит как очень простая и производительная сетевая карта, а со стороны гипервизора — как прямой интерфейс к сетевому драйверу гостевой ОС. Таким образом, производительность существенно вырастает за счёт того, что не нужно больше эмулировать несуществующее железо. Если про гостевую ОС точно известно, что она поддерживает VirtIO, имеет смысл использовать именно эту «сетевую карту».
+Настраивая сетевое подключение, обращаем внимание также и на то, что в списке сетевых карт, которые может эмулировать гипервизор KVM, есть пункт «VirtIO (paravirtualized)». Это специальный интерфейс, задачей которого является снижение накладных расходов на эмуляцию физической сетевой карты и реализацию драйвера для работы с ней. Между производителями современных операционных систем и произоводителями современных гипервизоров существует договорённость о поддержке единого интерфейса VirtIO, который со стороны гостевой ОС выглядит как очень простая и производительная сетевая карта, а со стороны гипервизора — как прямой интерфейс к сетевому драйверу гостевой ОС. Таким образом, производительность существенно вырастает за счёт того, что не нужно больше эмулировать несуществующее железо. Если про гостевую ОС точно известно, что она поддерживает VirtIO, имеет смысл использовать именно эту «сетевую карту».
 Кстати, реализация VirtIO существует также и для другого интерфейса между виртуальной ОС и гипервизором, критичного к скорости передачи данных — для дисковых накопителей. Там рекомендации точно такие же — если уверенность в поддержке со стороны гостевой ОС есть, включаем.
-=== Удалённый доступ к виртуальной машине ===
+==== Удалённый доступ к виртуальной машине ====
 После того, как выбор параметров виртуальной машины закончен и нажата кнопка «Завершить», виртуальная машина создана. Теперь нужно получить удалённый доступ к её консоли. В PVE для удалённый доступ к «физической» консоли виртуальной машины используется протокол VNC. В качестве клиента выступает приложение на Javascript, интегрированное в окно браузера.
-=== Миграция виртуальных машин из VMware в ALT PVE  ===
+==== Миграция виртуальных машин из VMware в ALT PVE  ====
-Этот раздел описывает миграцию виртуальных машин из VMware в ALT PVE, на примере виртуальной машины с Windows 7.<br>
+Этот раздел описывает миграцию виртуальных машин из VMware в ALT PVE, на примере виртуальной машины с Windows 7.
-'''Подготовка операционной системы Windows'''<br>
+===== Подготовка операционной системы Windows =====
-Необходимо сделать так, чтобы система грузилась с дисков в режиме IDE.<br>
+Необходимо сделать так, чтобы система грузилась с дисков в режиме IDE.
-'''Подготовка образа диска'''<br>
+===== Подготовка образа диска =====
-Предположим что файл с образом диска называется win7.vmdk<br>
+Предположим что файл с образом диска называется win7.vmdk.
-С помощью vmware-vdiskmanager (утилита поставляется в комплекте с VMWare Workstation) Вам необходимо преобразовать Ваш образ диска в тип "single growable virtual disk". Для этого в перейдите в папку с образами дисков и выполните следующую команду:
+С помощью vmware-vdiskmanager (утилита поставляется в комплекте с VMWare Workstation) необходимо преобразовать ваш образ диска в тип "single growable virtual disk". Для этого в перейдите в папку с образами дисков и выполните следующую команду:
 <pre>"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager" -r win7.vmdk -t 0 win7-pve.vmdk</pre>
-'''Подключение образа диска к виртуальной машине на основе Directory Storage'''<br>
+===== Подключение образа диска к виртуальной машине на основе Directory Storage =====
-Создайте новую виртуальную машину KVM, используя web-интерфейс ALT PVE, но не запускайте её. Посмотрите VMID, созданной виртуальной машины (например 100).<br>
+Создайте новую виртуальную машину KVM, используя веб-интерфейс ALT PVE, но не запускайте её. Посмотрите VMID, созданной виртуальной машины (например, 100).
-Скопируйте преобразованный образ win7-pve.vmdk в директорию с образами виртуальных машин <pre>/var/lib/vz/images/VMID</pre> (для этого можно воспользоваться WinSCP).<br>
+Скопируйте преобразованный образ win7-pve.vmdk в директорию с образами виртуальных машин {{path|/var/lib/vz/images/VMID}} (для этого можно воспользоваться WinSCP).
 Преобразуйте файл win7-pve.vmdk в qemu формат:
-<pre># qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2</pre>
+<syntaxhighlight lang="bash"># qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2</syntaxhighlight>
-Для подключения образа диска к созданной виртуальной машине Вам необходимо добавить в конфигурационный файл {{path|/etc/pve/nodes/node01/qemu-server/VMID.conf}} виртуальной машины следующую строчку:
-<pre>unused0: locald:100/win7-pve.qcow2.qcow2</pre>
+Для подключения образа диска к созданной виртуальной машине вам необходимо добавить в конфигурационный файл {{path|/etc/pve/nodes/node01/qemu-server/VMID.conf}} виртуальной машины следующую строчку:
-где 100 это VMID, а locald это имя хранилища в ALT PVE. Далее перейдите в web-интерфейс ALT PVE на вкладку Hardware, созданной виртуальной машины. В списке устройств вы увидите неиспользуемый жесткий диск, щелкните на него, выберете режим IDE и нажмите кнопку Add:<br>
+<syntaxhighlight lang="text">unused0: locald:100/win7-pve.qcow2</syntaxhighlight>
-[[Файл:Alt pve add disk.jpg|600px]]<br>
+где:
-'''Подключение образа диска к виртуальной машине на основе LVM Storage'''<br>
+* 100 — VMID;
-Создайте виртуальную машину используя web-интерфейс ALT PVE с диском большего размера,чем диск в образе vmdk. Посмотреть размер диска в образе можно командой:
+* locald — имя хранилища в ALT PVE.
-<pre># qemu-img info win7-pve.vmdk
+Далее перейдите в веб-интерфейс ALT PVE на вкладку «Оборудование» («Hardware»), созданной виртуальной машины. В списке устройств вы увидите неиспользуемый жёсткий диск, щелкните на него, выберете режим IDE и нажмите кнопку «Добавить» («Add»):
+[[Файл:Alt pve add disk.jpg|600px]]
+===== Подключение образа диска к виртуальной машине на основе LVM Storage =====
+Создайте виртуальную машину, используя веб-интерфейс ALT PVE, с диском большего размера, чем диск в образе vmdk.
+Посмотреть размер диска в образе можно, выполнив команду:
+<syntaxhighlight lang="bash"># qemu-img info win7-pve.vmdk
 image: win7-pve.vmdk
 file format: vmdk
@@ Строка 280: / Строка 472: @@
              filename: win7-pve.vmdk
              cluster size: 65536
-             format:</pre>
+             format:</syntaxhighlight>
-В данном случае необходимо создать диск в режиме IDE размером не меньше 127GB, не запускайте виртуальную машину.<br>
-Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.<br>
+В данном случае необходимо создать диск в режиме IDE размером не меньше 127GB. Не запускайте виртуальную машину.
-Перейдите в консоль ноды кластера и посмотрите как называется LVM диск созданной виртуальной машины (он должен быть в статусе ACTIVE):
-<pre># lvscan
+Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.
-   ACTIVE            '/dev/sharedsv/vm-101-disk-1' [130,00 GiB] inherit</pre>
-Далее необходимо сконвертировать образ vdmk в raw формат непосредственно на LVM-устройство:
+Перейдите в консоль ноды кластера и посмотрите как называется LVM-диск созданной виртуальной машины (он должен быть в статусе ACTIVE):
-<pre># qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/sharedsv/vm-101-disk-1</pre>
-'''Подключение образа диска к виртуальной машине на основе CEPH Storage'''<br>
+<syntaxhighlight lang="bash"># lvscan
-Создайте виртуальную машину используя web-интерфейс ALT PVE с диском большего размера,чем диск в образе vmdk.<br>
+   ACTIVE            '/dev/sharedsv/vm-101-disk-1' [130,00 GiB] inherit</syntaxhighlight>
-Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.<br>
+Далее необходимо сконвертировать образ vdmk в raw-формат непосредственно на LVM-устройство:
-Перейдите в консоль ноды кластера. Имя нужного пула можно посмотреть на вкладке Datacenter->Storage->rbd-storage:<br>
+<syntaxhighlight lang="bash"># qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/sharedsv/vm-101-disk-1</syntaxhighlight>
-[[Файл:Alt pve rbd pool.jpg|500px]]<br>
+===== Подключение образа диска к виртуальной машине на основе CEPH Storage =====
+Создайте виртуальную машину используя веб-интерфейс ALT PVE с диском большего размера, чем диск в образе vmdk.
+Скопируйте преобразованный образ win7-pve.vmdk на нужную ноду кластера.
+Перейдите в консоль ноды кластера. Имя нужного пула можно посмотреть на вкладке Datacenter->Storage->rbd-storage:
+[[Файл:Alt pve rbd pool.jpg|500px]]
 Нам необходимо отобразить образ из пула CEPH в локальное блочное устройство:
-<pre># rbd map rbd01/vm-100-disk-1
+<syntaxhighlight lang="bash"># rbd map rbd01/vm-100-disk-1
-/dev/rbd0</pre>
+/dev/rbd0</syntaxhighlight>
-Далее необходимо сконвертировать образ vdmk в raw формат непосредственно на отображенное устройство:
+Далее необходимо сконвертировать образ vdmk в raw-формат непосредственно на отображенное устройство:
-<pre># qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/rbd0</pre>
+<syntaxhighlight lang="bash"># qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/rbd0</syntaxhighlight>
-'''Проблемы с образом VMware'''<br>
+===== Проблемы с образом VMware =====
-Кроме того Ваш образ диска может быть в формате flat, тогда при попытке конвертировать его вы получите ошибку "Operation not permitted". Вы можете посмотреть настоящий формат вашего .vdmk файла с помощью команды "file". Если файл в формате flat то вы получите примерно такой вывод:
+Кроме того образ диска может быть в формате flat, тогда при попытке конвертировать его вы получите ошибку "Operation not permitted". Вы можете посмотреть настоящий формат вашего .vdmk файла с помощью команды {{cmd|file}}. Если файл в формате flat то вы получите примерно такой вывод:
-<pre># file myVMwFlatImage-pre.vmdk
+<syntaxhighlight lang="bash"># file myVMwFlatImage-pre.vmdk
 myVMwFlatImage-pre.vmdk: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
    startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 208845,
-   16563015 sectors, code offset 0x48</pre>
+   16563015 sectors, code offset 0x48</syntaxhighlight>
 Очень просто конвертировать такой файл из .vdmk в .qcow2 просто убрав параметр "-f vdmk" из предыдущей команды, предоставив qemu-img автоматически определить формат исходного файла:
-<pre># qemu-img convert myVMwFlatImage-pve.vmdk -O qcow2 myVMwFlatImage-pve.qcow2</pre>
+<syntaxhighlight lang="bash"># qemu-img convert myVMwFlatImage-pve.vmdk -O qcow2 myVMwFlatImage-pve.qcow2</syntaxhighlight>
 Если ваша виртуальная машина KVM стартует, но не грузится с ошибкой "booting from hard disk...boot failed: not a bootable disk", то попробуйте при конвертировании вместо типа диска "single growable virtual disk"  тип "preallocated virtual disk". Для этого в командной строке запустите vmvare-vdiskmanager без параметров, Вы увидите справку по работе с командой. Тип диска при конвертации задает параметр -t <disk-type>:
-<pre>Disk types:
+<syntaxhighlight lang="bash">Disk types:
                    : single growable virtual disk
                    : growable virtual disk split in 2GB files
@@ Строка 313: / Строка 513: @@
                    : preallocated virtual disk split in 2GB files
                    : preallocated ESX-type virtual disk
-                   : compressed disk optimized for streaming</pre>
+                   : compressed disk optimized for streaming</syntaxhighlight>
 Нам нужно выбрать тип 2:
-<pre>vmware-vdiskmanager -r whatever.vmdk -t 2 whatever-pve.vmdk</pre>
+<syntaxhighlight lang="bash">vmware-vdiskmanager -r whatever.vmdk -t 2 whatever-pve.vmdk</syntaxhighlight>
-Имейте ввиду, что при этом vmware-vdiskmanager создаст два файла. Первый файл {{path|whatever-pve.vmdk}} очень маленький, это обычный текстовый файл со ссылкой на образ. Второй файл {{path|whatever-pve-flat.vmdk}}, который имеет размер всего Вашего виртуального диска и именно его надо конвертировать в kvm.<br>
+Имейте ввиду, что при этом vmware-vdiskmanager создаст два файла. Первый файл {{path|whatever-pve.vmdk}} очень маленький, это обычный текстовый файл со ссылкой на образ. Второй файл {{path|whatever-pve-flat.vmdk}}, который имеет размер всего вашего виртуального диска и именно его надо конвертировать в kvm.<br>
-'''Адаптация новой виртуальной машины KVM'''
+===== Адаптация новой виртуальной машины KVM =====
-*Проверьте режим работы жесткого диска для Windows - IDE, для Linux SCSI
+*Проверьте режим работы жесткого диска для Windows — IDE, для Linux SCSI
 *Режим VIRTIO жесткого диска:
 **Режим VIRTIO также доступен для Windows, но сразу загрузиться в этом режиме система не может
@@ Строка 327: / Строка 527: @@
 *Включите виртуальную машину
 *Первое включение займет какое-то время пока будут загружены необходимые драйвера
-*Драйвера VIRTIO для Windows можно скачать [https://fedoraproject.org/wiki/Windows_Virtio_Drivers здесь]
+*Драйвера VIRTIO для Windows можно скачать [https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md здесь]
-== Контейнеры (CT) ==
+=== Контейнеры (CT) ===
-В отличие от виртуальной машины, которая с точки зрения ОС, запущенной на физическом узле, представляет собой один процесс гипервизора, процессы контейнера выполняются на том же самом ядре, что и остальные процессы ОС. То есть, если мы запустим VM и CT на одном и том же физическом узле PVE, процессы CT будут выполняться «рядом» с процессами гипервизора. Разница будет только в применении к процессам контейнеров механизмов изоляции — пространств имён (Namespaces) и групп управления (CGroups) — работающих на уровне ядра Linux.
+В отличие от виртуальной машины, которая с точки зрения ОС, запущенной на физическом узле, представляет собой один процесс гипервизора, процессы контейнера выполняются на том же самом ядре, что и остальные процессы ОС. То есть, если мы запустим ВМ и CT на одном и том же физическом узле PVE, процессы CT будут выполняться «рядом» с процессами гипервизора. Разница будет только в применении к процессам контейнеров механизмов изоляции — пространств имён (Namespaces) и групп управления (CGroups) — работающих на уровне ядра Linux.
 Существует несколько реализаций изолированных контейнеров, базирующихся на этих механизмах. Например [https://openvz.org OpenVZ] и [https://linuxcontainers.org LXC], которые отличаются развитостью и проработанностью механизмов управления. В PVE версий 4+ используется реализация LXC (до 3 версии использовалась OpenVZ), обёрнутая дополнительным собственным пользовательским интерфейсом, делающим процесс создания и обслуживания контейнеров ещё более удобным.
-Процесс создания контейнера во многом схож с процессом создания виртуальной машины. Разница в том, что создание контейнера соответствует созданию VM и одновременно установке туда операционной системы. Эквивалентом инсталляционному диску является шаблон, из которого разворачивается контейнер. Это архив, содержащий корневую файловую систему будущего контейнера. Примеры шаблонов контейнеров можно найти на [http://download.proxmox.com/images/system/ сайте разработчиков PVE] и в [https://openvz.org/Download/template/precreated коллекции шаблонов OpenVZ].
+Процесс создания контейнера во многом схож с процессом создания виртуальной машины. Разница в том, что создание контейнера соответствует созданию ВМ и одновременно установке туда операционной системы. Эквивалентом инсталляционному диску является шаблон, из которого разворачивается контейнер. Это архив, содержащий корневую файловую систему будущего контейнера. Примеры шаблонов контейнеров можно найти на [http://download.proxmox.com/images/system/ сайте разработчиков PVE] и в [https://openvz.org/Download/template/precreated коллекции шаблонов OpenVZ].
 Важно помнить, что [[Шаблоны для развёртывания CT в PVE|шаблоны, пригодные для развёртывания CT в PVE]], имеют собственную нотацию имён, отличающуюся от таковых, например, в OpenVZ. Поэтому перед загрузкой очередного шаблона в хранилище PVE не забываем переименовать его соответствующим образом.
@@ Строка 343: / Строка 543: @@
 Почти весь процесс «инсталляции» сводится к распаковке шаблона. Оставшаяся часть процесса инсталляции заключается в том, чтобы придать распакованному образу корневой файловой системы уникальные черты, отличающие его от других таких же контейнеров, созданных, возможно, из этого же самого шаблона.
-Уникальность контейнера обеспечивается на двух уровнях: первый уровень это уникальный идентификатор контейнера в пределах ОС физического узла, в которой разворачиваются контейнеры. Это число, как правило больше ста. PVE автоматизированным образом ведёт учёт идентификаторов и при создании контейнера не позволит выбрать уже занятый. Кстати, в пределах кластера PVE идентификаторы VM и СТ составляют единое пространство идентификаторов.
+Уникальность контейнера обеспечивается на двух уровнях: первый уровень это уникальный идентификатор контейнера в пределах ОС физического узла, в которой разворачиваются контейнеры. Это число, как правило больше ста. PVE автоматизированным образом ведёт учёт идентификаторов и при создании контейнера не позволит выбрать уже занятый. Кстати, в пределах кластера PVE идентификаторы ВМ и СТ составляют единое пространство идентификаторов.
 Второй уровень уникальности контейнера — строго говоря, не обязательный — это сетевые настройки: IP-адрес и имя узла. Обеспечивать уникальность на этом уровне не обязательно, так как у нас может быть несколько контейнеров с одинаковым именем узла, адресом IP, и даже MAC-адресом. Просто они будут запускаться в разное время. Но следить за этим будет уже не PVE, а оператор. PVE только обеспечивает возможность задания сетевых настроек контейнера при его создании.
@@ Строка 349: / Строка 549: @@
 [[Файл:Pve-ct-create-net.png|900px|Сетевые настройки контейнера]]
-Основная задача CT, в отличие от VM — не запуск полноценной ОС в виртуальной машине, а запуск отдельного приложения или сетевой службы в изолированном окружении. Поэтому доступ для обслуживания CT, как правило, удобнее осуществлять через обычный терминал — то есть, уже без участия интерфейса PVE. Для этого внутри контейнера настраивают серверную часть SSH, VNC или наоборот — клиентскую часть X-протокола. Впрочем, веб-интерфейс предоставляет для CT, так же, кстати, как и для физических узлов консоль. Обычную текстовую консоль UNIX.
+Основная задача CT, в отличие от ВМ — не запуск полноценной ОС в виртуальной машине, а запуск отдельного приложения или сетевой службы в изолированном окружении. Поэтому доступ для обслуживания CT, как правило, удобнее осуществлять через обычный терминал — то есть, уже без участия интерфейса PVE. Для этого внутри контейнера настраивают серверную часть SSH, VNC или наоборот — клиентскую часть X-протокола. Впрочем, веб-интерфейс предоставляет для CT, так же, кстати, как и для физических узлов консоль. Обычную текстовую консоль UNIX.
 [[Файл:Pve-node-console.png|900px|Доступ к консоли через веб-интерфейс]]
-== Обслуживание виртуальных окружений ==
+==== Где взять готовые контейнеры ====
+# Загрузить при помощи встроенной утилиты {{cmd|pveam}}
+# Загрузить вручную с [http://download.proxmox.com/images/system/ сайта Proxmox]
+# Загрузить шаблоны LXC с [https://uk.images.linuxcontainers.org/images/ официального сайта]
+# Загрузить готовое окружение для решения конкретной задачи (на базе Debian) [http://mirror.turnkeylinux.org/turnkeylinux/images/proxmox/ отсюда]
+# Создать контейнер самому
+{{Attention|Следует учитывать, что будут работать не все контейнеры, созданные для LXC, т.к. система, на базе которой создан контейнер, должна поддерживаться скриптами PVE. }}
+=== Обслуживание виртуальных окружений ===
 Кроме создания, удаления и получения доступа к консоли существует ещё ряд важных задач по работе с виртуальными окружениями, которые веб-интерфейс PVE позволяет успешно решать. Это в первую очередь сбор статистики по расходованию ресурсов кластера PVE, управление доступом к объектам виртуальной инфраструктуры, и обеспечение бесперебойной работы в случае сбоев.
-=== Статистика ===
+==== Статистика ====
 В течение всего времени работы кластера PVE собирает статистику по широкому спектру параметров, характеризующих различные виды нагрузки на физические узлы, хранилища данных и виртуальные окружения. Статистическая информация собирается, хранится, и может быть в любой момент представлена в виде графиков и диаграмм.
@@ Строка 365: / Строка 576: @@
 Такой наглядный способ представления может быть полезен не только для оценки текущего состояния работы системы, но и для оценки тенденций изменения характера нагрузок. Поэтому, при выборе узла, на который мы планируем добавить очередное виртуальное окружение в кластер, бывает полезно заглянуть не только в выпадающий список узлов со значениями текущих показателей нагрузки, но и в графики распределения нагрузки по времени суток и дням недели. Может оказаться, что узел, наименее нагруженный в данный момент, бо́льшую часть времени работает под максимальной нагрузкой.
-=== Управление доступом ===
+==== Управление доступом ====
 Как уже упоминалось в руководстве по установке, PVE может использовать любые базы данных пользовательских учётных записей, доступные через механизм PAM. Например, базы локальных пользователей физических узлов кластера. Кроме того, у PVE есть ещё и своя база данных учётных записей пользователей и групп. Все эти пользователи и группы являются полноправными субъектами доступа к объектам кластера. Объектами доступа являются физические узлы и хранилища данных. Полномочия субъектов доступа настраиваются через механизм ролей.
@@ Строка 373: / Строка 584: @@
 Для упрощения разграничения доступа в PVE существует ещё один уровень объектов доступа, функционально аналогичный группам — пулы. В состав пула могут входить виртуальные окружения и некоторые виды хранилищ данных. Доступ к пулам регулируется так же через механизм назначения ролей.
-=== Резервное копирование ===
+==== Резервное копирование ====
+См. также [[PVE/Backup_Server|Proxmox Backup Server]]
 На радость системным администраторам PVE имеет встроенную систему резервного копирования. Добавить очередной пункт в расписание снятия резервных копий состояния виртуальных окружений и хранилищ данных можно буквально «в несколько кликов».
-[[Файл:Pve-backup-setup.png|900px|Настройка расписания резервного копирования]]
+[[Файл:Pve-backup-setup.png|Настройка расписания резервного копирования]]
 Важно не забыть предварительно добавить хранилище, у которого будет роль хранилища для резервных копий.
@@ Строка 383: / Строка 596: @@
 Формат и режим снятия резервных копий могут быть разными. Это могут быть образы остановленных виртуальных окружений, находящихся в консистентном состоянии, или снапшоты, сделанные «на лету». В последнем случае работоспособность сервисов, запущенных внутри виртуального окружения, после восстановления из резервной копии не гарантируется.
-=== Снапшоты ===
+==== Снимки (снапшоты) ====
-Кроме снятия резервных копий, снапшоты используются и просто для фиксации состояния виртуального окружения. Для фиксации снапшотов есть специальный пункт в меню виртуального окружения в интерфейсе PVE.
+Кроме снятия резервных копий, снимки используются и просто для фиксации состояния виртуального окружения. Для фиксации снимков есть специальный пункт в меню виртуального окружения в интерфейсе PVE.
 [[Файл:Pve-snapshot-setup.png|900px|Снятие снапшота]]
-= Ссылки =
+== Ссылки ==
 * [http://www.proxmox.com/ Официальный сайт]
 * [[:ruwp:Proxmox_Virtual_Environment|Proxmox VE]]
@@ Строка 395: / Строка 608: @@
 [[Категория:Admin]]
 [[Категория:Миграция]]
+[[Категория:Виртуализация]]
 {{Category navigation|title=ПО уровня предприятия|category=Enterprise Software|sortkey={{SUBPAGENAME}}}}