Работа с lxc контейнерами

Введение

Существует проверенная временем связка для прокси сервера — squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

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

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

Введение

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

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

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

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

Расскажу о том, почему мне захотелось посмотреть на контейнеры вместо виртуальных машин, которые использую повсеместно уже много лет.

Как уже написал ранее, привлекает возможность использовать ресурсы хостовой машины напрямую. Взял системный диск с корнем / на 1Тб и все контейнеры его используют пока есть место.
Легкий бэкап и доступ к файлам в контейнерах. Посмотреть файлы в контейнере можно просто зайдя в директорию контейнера с хостовой машины. Они все хранятся в открытом виде. Так их очень удобно бэкапить с помощью rsync, или каким-то другим способом.
Легко копировать, разворачивать, управлять контейнерами. Они занимают мало места, можно руками с хоста поправить какой-то конфиг в системе контейнера.

Например, у меня есть достаточно мощные VDS серверы от ihor. 2 ядра, 8 гигов, 150Гб диск. Иногда то, что там размещается, не использует полностью ресурсы виртуальной машины. Хочется как-то их занять, но при этом никак не затрагивать основные проекты на виртуальной машине. Иногда хочется какие-то тестовые среды создавать для сайтов и пробовать новые версии софта. Для этого надо отдельную виртуалку брать. Вместо этого я решил попробовать lxc контейнеры.

Использовать lxc контейнеры в плане сети можно двумя способами:

Заказывать каждому контейнеру отдельный внешний IP, настраивать для контейнера bridge на реальном сетевом интерфейсе и выпускать его напрямую в интернет. Этот вариант подходит, если есть ip адреса или не жалко для них денег. Так работать удобнее всего.
Настраивать виртуальный bridge, настраивать NAT и проброс портов с хостовой машины внутрь контейнеров. Не очень удобно, но тем не менее вполне рабочий вариант.

Я расскажу про оба способа, так как проверял и то и другое. Настраивать все будем на CentOS 7.

Если у вас еще нет своего сервера с CentOS 8, то рекомендую мои материалы на эту тему:

Установка CentOS 8.
Настройка CentOS.

Введение

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

Как уже написал ранее, привлекает возможность использовать ресурсы хостовой машины напрямую. Взял системный диск с корнем / на 1Тб и все контейнеры его используют пока есть место.
Легкий бэкап и доступ к файлам в контейнерах. Посмотреть файлы в контейнере можно просто зайдя в директорию контейнера с хостовой машины. Они все хранятся в открытом виде. Так их очень удобно бэкапить с помощью rsync, или каким-то другим способом.
Легко копировать, разворачивать, управлять контейнерами. Они занимают мало места, можно руками с хоста поправить какой-то конфиг в системе контейнера.

Например, у меня есть достаточно мощные VDS серверы от timeweb. 2 ядра, 8 гигов, 150Гб диск. Иногда то, что там размещается, не использует полностью ресурсы виртуальной машины. Хочется как-то их занять, но при этом никак не затрагивать основные проекты на виртуальной машине. Иногда хочется какие-то тестовые среды создавать для сайтов и пробовать новые версии софта. Для этого надо отдельную виртуалку брать. Вместо этого я решил попробовать lxc контейнеры.

Использовать lxc контейнеры в плане сети можно двумя способами:

Заказывать каждому контейнеру отдельный внешний IP, настраивать для контейнера bridge на реальном сетевом интерфейсе и выпускать его напрямую в интернет. Этот вариант подходит, если есть ip адреса или не жалко для них денег. Так работать удобнее всего.
Настраивать виртуальный bridge, настраивать NAT и проброс портов с хостовой машины внутрь контейнеров. Не очень удобно, но тем не менее вполне рабочий вариант.

Я расскажу про оба способа, так как проверял и то и другое. Настраивать все будем на CentOS 7.

Если у вас еще нет своего сервера с CentOS 7, то рекомендую мои материалы на эту тему:

Установка CentOS 7.

Настройка CentOS 7.

Добавление CentOS 7 в домен Windows

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

Я без проблем ввел компьютер в домен, прошел все проверки, но потом в squid напрочь отказывалась работать ntlm авторизация. Все на вид выглядело нормально, но не работало. Я несколько раз восстанавливал виртуалку и начинал все сначала, перечитав практически все, что смог найти по теме в рунете и буржунете. В какой-то момент все заработало. Я зафиксировал результат и несколько раз проверил последовательность действий и отточил ее до каждого шага. Проверил несколько раз на чистой системе. По крайней мере на момент написания статьи конфигурация на 100% рабочая, если аккуратно повторить все мои действия. Приступаем.

Сначала остановим и отключим firewalld:

Это не значит, что его не надо настраивать. Сейчас другая тема статьи, для локализации проблем необходимо убрать все, что теоретически может мешать при неправильной настройке. Firewall нужно настраивать и у меня есть подробная инструкция по настройке iptables. Рекомендую с ней ознакомиться и аккуратно настроить iptables, когда все получится со squid.

Установим софт для добавления сервера в домен windows:

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

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

Добавляем наш контроллер в список серверов для обновления в файле /etc/ntp.conf, запускаем ntp и добавляем в автозагрузку:

Синхронизация времени с контроллером домена не является обязательным действием. Но в случае расхождения времени более чем на 5 минут, будут возникать проблемы, которые на первый взгляд будут неочевидными и решать их трудно. Поэтому на всякий случай процедуру лучше провести. Очень подробно о настройке времени в CentOS 7 рассказано отдельно.

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

Команда вся идет в одну строчку. Скопируйте ее сначала в текстовый файл и подредактируйте под свои параметры. Проверьте, что нигде не пропали и не добавились лишние пробелы, либо какие-то еще символы, тире должно быть двойным перед параметром. В данном случае:

xs — название домена
winsrv — имя контроллера домена
winsrv.xs.local — полное имя домена

Вывод после работы команды будет такой:

Это нормально

Обращаю внимание, что SELinux у меня отключен

Теперь заводим машину в домен:

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

Теперь нужно запустить и добавить в автозагрузку winbind:

Проверяем, все ли у нас корректно работает. Для начала проверим наличие доверительной учетной записи сервера на КД:

Все в порядке. Теперь проверяем, может ли наш сервер получать списки пользователей и групп. Первая команда выводит список всех групп домена, вторая — всех пользователей:

Проверим авторизацию пользователя через winbind:

В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня.

Теперь запросим билетик кербероса:

Дальше вводите пароль. Если ошибки не выскочило, значит все в порядке. Проверим билет командой:

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

Дополнительно

Про CPU

Чтобы ограничить контейнер любыми 2 процессорами:

Данная команда сработает на лету, чтобы в этом убедится посмотрим применилось ли наше ограничение

На определенных ядрах процессора, скажем, на втором и четвертом команда примет вид:

Более сложные закрепление с помощью диапазонов:

Чтобы ограничить процессорное время контейнера до 10% от общего числа, набираем вот такую команду:

Про память

Что бы ограничить выделяемую контейнеру память, необходимо набрать следующую команду:

Смотрим инфо про память:

Для отключения файла подкачки swap

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

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

Базовая настройка закончена — можно опробовать наш гипервизор в деле.

В правой верхней части панели управления кликаем по Создать VM:

В открывшемся окне снизу сразу ставим галочку Расширенный:

Задаем имя виртуальной машине и ставим галочку Запуск при загрузке (если хотим, чтобы виртуалка запускалась автоматически с сервером PVE):

* в данном примере мы задали имя FS. При желании, также можно изменить VM ID, но он проставляется автоматически и имеет правильное значение.

Выбираем загруженный нами ISO-образ, с которого будем ставить операционную систему, задаем тип гостевой операционной системы и ее версию:

* в данном примере мы будем устанавливать Linux Ubuntu. Среди списка операционных систем также доступны Microsoft Windows, Solaris и Other.

На вкладке Система можно оставить все значения по умолчанию:

* в некоторых случаях, необходимо выбрать другую видеокарту (при установке систем с GUI), а также особый вариант БИОС.

Задаем размер жесткого диска:

* 16 Гб для Ubuntu достаточно, однако, для наших задач расчет должен быть индивидуальным для каждой создаваемой виртуальной машины.

Мы можем задать количество процессоров и ядер:

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

Выделяем память:

* наша Ubuntu будет работать с 2 Гб оперативной памяти.

Выбираем созданный нами бридж — либо для получения прямого адреса из сети, либо для NAT:

* в данном примере, мы указали vmbr0 для подключения к сети напрямую.

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

… и нажимаем Готово. Ждем окончания процесса и переходим к консоли:

Мы должны увидеть загрузку с ISO-образа.

Подготовка сервера

Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему — установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду каcаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.

Информационная таблица
xs.local	название домена
10.1.3.4	ip адрес контроллера домена
xs-winsrv.xs.local	полное имя контроллера домена
xs-centos7-test	имя сервера centos, который вводим в домен
administrator	учетная запись администратора домена
gr_linux_adm	группа в AD, для которой разрешено подключение к серверам по ssh
lin-user	учетная запись в AD для проверки подключений по ssh

Выключаем firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.

Настроим синхронизацию времени с контроллером домена

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

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

# cat /var/log/messages | grep chronyd
Jul 12 17:58:38 xs-centos7-test chronyd: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Jul 12 17:58:38 xs-centos7-test chronyd: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift
Jul 12 17:02:54 xs-centos7-test chronyd: Selected source 10.1.3.4
Jul 12 17:02:54 xs-centos7-test chronyd: System clock wrong by -3348.457170 seconds, adjustment started
Jul 12 17:02:54 xs-centos7-test chronyd: System clock was stepped by -3348.457170 seconds

Все в порядке. Синхронизировали время с контроллером домена. По логу видно, что время на сервере убежало вперед на 56 минут, но мы это исправили.

Тонкая настройка iptables

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

Готовый листинг , решающий две задачи сразу, представлен ниже:

Создание бэкапов

Данный метод создает бэкапы контейнеров как LXD образы, готовые к импорту. В идеале нужно создавать снимки и отправлять их в приватный репозиторий LXD. Но иногда, этого сделать нельзя. Например, у небольшой компании нет возможности покупать еще один сервер. В этом случае можно обойтись простым решением tar + Amazon S3.

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

Установите флаг выполнения для скриптов:

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

Перезапуск системы

Перезагрузите Ubuntu:

Установка и запуск образа виртуальной машины

Добавьте репозиторий (опционально, по умолчанию images уже добавлен):

Скачайте образ:

centos-image – синоним образа, чтобы легче было к нему обращаться

Запустите образ:

test — название будущего контейнера

Можно запускать образы в две команды:

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

Посмотрите статус запущенных контейнеров

Команда должна показать следующую информацию:

Обратите внимание, что LXD выдал статический IP для контейнера, который вы настроили в /etc/lxc-dnsmasq.conf

Для 4 версии Proxmox

С инструкцией по подключению USB устройств вы можете ознакомится на официальном сайте Proxmox.

Определение устройства

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

lsusb
= вывод команды =
Bus 001 Device 005: ID 0781:5572 SanDisk Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 0665:5161 Cypress Semiconductor USB to Serial
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Видим подключенную флэшку.

Выведем информации о том на каких портах висят устройства.

lsusb -t
= вывод команды =
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
 |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbfs, 1.5M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M
 |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Видим нашу флэшку которая села на Bus 01—Dev 5 наPort 3.

Варианты проброса устройств

Существуют два вариант передачи USB-устройства в виртуальную (гостевую) систему:

передать определенное устройство — при перемещении usb-устройства в другой порт не надо ничего перенастраивать. Вариант хорош, когда надо пробросить одно устройство и второго подобного не будет,
передать порт — вариант передает порт на котором работает устройство.

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

Проброс осуществляются по номеру виртуальной машины. Папка с файлами для редактирования находится по адресу /etc/pve/qemu-server/ в ней вы увидите все ваши виртуальные машины.

Проброс USB устройства

Откроем необходимый файл и добавим нужные параметры.

mcedit /etc/pve/qemu-server/104.conf
= вывод команды с необходимыми добавлениями =
balloon: 500
bootdisk: sata0
cores: 2
ide2: local:iso/CentOS-7-x86_64-DVD-1511.iso,media=cdrom
memory: 1500
name: lamp.sevo44.ad-centos7
net0: e1000=7A:5A:34:67:6C:52,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
sata0: images:104/vm-104-disk-1.qcow2,size=400G
scsihw: virtio-scsi-pci
smbios1: uuid=4374a7e1-1fc7-4eaf-9567-aa5f9cb19b33
sockets: 2
# Проброс устройства USB
# где 0781:5572 - это device ID
usb0: host=0781:5572

Проброс USB порта

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

mcedit /etc/pve/qemu-server/104.conf
= вывод команды с необходимыми добавлениями =
balloon: 500
bootdisk: sata0
cores: 2
ide2: local:iso/CentOS-7-x86_64-DVD-1511.iso,media=cdrom
memory: 1500
name: lamp.sevo44.ad-centos7
net0: e1000=7A:5A:34:67:6C:52,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
sata0: images:104/vm-104-disk-1.qcow2,size=400G
scsihw: virtio-scsi-pci
smbios1: uuid=4374a7e1-1fc7-4eaf-9567-aa5f9cb19b33
sockets: 2
# Проброс USB порта
# где 1-3 это шина Bus 01 и номер порта Port 3
usb0: 1-3

После перезагрузки устройства будут проброшены.

Добавляем сервер к домену через realm

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

Итак, отключаем firewall и SELinux, если не сделали это раньше. Если не хотите отключать, то настройте сами. Данная настройка выходит за рамки статьи.

# mcedit /etc/sysconfig/selinux

меняем значение

SELINUX=disabled

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

setenforce 0

Выключаем firewalld.

# systemctl stop firewalld
# systemctl disable firewalld

Информационная таблица
xs.local	название домена
10.1.3.4	ip адрес контроллера домена
xs-winsrv.xs.local	полное имя контроллера домена
xs-design	имя сервера centos, который вводим в домен
admin51	учетная запись администратора домена

Настроим синхронизацию времени с контроллером домена

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

Устанавливаем софт, который понадобится для дальнейшей работы.

# yum install realmd sssd sssd-libwbclient oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Делаем проверку перед вводом в домен.

# realm discover XS.LOCAL
xs.local
 type: kerberos
 realm-name: XS.LOCAL
 domain-name: xs.local
 configured: no
 server-software: active-directory
 client-software: sssd
 required-package: oddjob
 required-package: oddjob-mkhomedir
 required-package: sssd
 required-package: adcli
 required-package: samba-common-tools

Заводим в домен.

# realm join -U admin51 XS.LOCAL
Password for admin51:

Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.

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

# id [email protected]
uid=185001305([email protected]) gid=185000513(пользователи домена@xs.local) groups=185000513(пользователи домена@xs.local),185001329([email protected]),185001651([email protected]),185001327([email protected])

Еще несколько проверок.

# realm list

# adcli info xs.local

Сервер завели в домен. Приступаем к основному — настройке samba с интеграцией в AD.

Резервное копирование контейнеров LXC

LXC-контейнеры совместимы с файловыми системами ZFS, Btrfs и томами LVM. При размещении контейнеров на хранилищах такого типа, будут использоваться их встроенные средства для создания моментальных снимков.

Перед созданием снимка (snapshot) контейнера его необходимо остановить!

Создать снимок:

lxc-snapshot php7-lxc

=== Для создания снимка с комментарием ===
= создаем файл с комментарием =
echo "base setup sevo44" > snap-comment
= создаем снимок с комментарием =
lxc-snapshot php7-lxc -c snap-comment

Посмотреть имеющиеся снимки с выводом комментариев если они есть:

lxc-snapshot php7-lxc -L -С
= вывод команды =
snap0 (/var/sevo44/lxcsnaps/php7-lxc) 2019:02:26 20:52:17
snap1 (/var/sevo44/lxcsnaps/php7-lxc) 2019:02:26 21:02:44
base setup sevo44

Откатится к снимку snap0 контейнера php7-lxc можно выполнив команду:

lxc-snapshot php7-lxc -r snap0

Удалить снимок:

lxc-snapshot php7-lxc -d snap0

Создать новый контейнер из снимка:

lxc-snapshot php7-lxc -r snap0 php7-2-lxc

Заключение

Теперь вы знаете как выполняется установка и настройка proxmox на Debian 10. Особенно интересен апгрейд Debian 10 при условии, что хост расположен в облаке и его процессор поддерживает виртуализацию. Оплачивая один VPS или VDS, мы можем развернуть внутри несколько изолированных сервисов из любого, даже самого экзотического дистрибутива.

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