Proxmox не видит сетевую карту

На сегодняшний день существует несколько наиболее популярных гипервизоров для построения виртуальной информационной системы. В данной статье я рассмотрю установку и настройку бесплатной системы виртуализации proxmox 6 на базе ОС Debian 10, установленной на RAID 1. В качестве гипервизоров она использует опенсорсные KVM и LXC, позволяя виртуализировать наиболее популярные ОС.

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

Присоединился: 4 года назад

Возникла проблема по сабжу. Суть в следующем. На железку установлен последний ProxMox со всеми обновлениями. На нем крутятся виртуалки с начисто установленными голыми системами Win10x64, Debian 9.9 и Centos 7 последних версий. Одна из физических сетевых карт Hosta по очереди пробрасывается напрямую в каждую из виртуалок. Затем этой виртуалке, в которую в данный момент проброшена карта, делается бекап средствами ProxMox (Datacenter — BackUp) в режиме Stop. ProxMox останавливает эту машину на какое-то время, делает бекап и запускает снова. После этого:

— Debian и Винда после этих манипуляций прекрасно работают и видят сеть, есть интернет.

— Centos поднимает сетевой интерфейс, айпишник на месте, все настройки на месте, но интернета и сети нет. До тех пор, пока не будет перезагружен Host, т.е. ProxMox.

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

Вопрос — в какую сторону копать?

Присоединился: 10 лет назад

Я бы сначала пошел по самому простому пути — бэкапить без остановки виртуалки.

Судя по описанию, тут какой-то нетипичный баг или глюк, особенно если в логах пусто, а на других системах не воспроизводится.

Присоединился: 4 года назад

Спасибо, попробуем делать бекап машин постоянно. Посмотрим, что получится.

Подведем итог тому, что сделали:

• Установили гипервизор proxmox на сервер под управлением Debian на программный raid1, обеспечив отказоустойчивость системы на уровне дисков.
• Настроили виртуальную сеть для виртуальных машин.
• Подключили различные storage для выполнения задач размещения и бэкапа виртуальных машин.
• Добавили и настроили виртуальные машины.
• Организовали автоматический бэкап всех ВМ.

Я постарался выбрать наиболее востребованные функции и описать их, чтобы систему можно было использовать в реальной работе и не бояться за надежность решения. Собрал необходимый минимум, но статься все равно получилась очень большая, объемная. Я не стал ее разделять на части, чтобы была целостная картина всего того, что сделали. Тут есть еще над чем поработать, особенно актуален вопрос бэкапа. Без инкрементного бэкапа неудобно хранить резервные копии на удаленном сервере, очень большой объем передаваемых данных получается. Мне не известен способ инкрементного бэкапа виртуальных машин в proxmox, буду рад, если кто-то посоветует хорошее решение для KVM. Снэпшоты zfs не в счет.

Если у вас есть желание научиться администрировать системы на базе Linux, но вы с ними никогда не работали и не знакомы, то рекомендую начать с онлайн-курса «Linux для начинающих»
в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Цена за курс минимальная (символическая). Информация о курсе и цене
.

Помогла статья? Подписывайся на telegram канал
автора

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

Некоторое время назад я узнал про систему виртуализации proxmox на базе KVM. Ранее с этим гипервизором я был знаком, но он мне не понравился из-за отсутствия удобных инструментов управления под windows. Это было давно, лет 5 назад. Мне пришлось администрировать уже настроенный гипервизор и мне это не понравилось, слишком много действий приходилось делать в консоли. Не скажу, что мне это прям не нравится, но я не вижу смысла в консоли делать то, что в других гипервизорах мышкой ты делаешь в 5 раз быстрее в gui. Свое время стараюсь экономить и использовать рационально.

Все изменилось, когда я решил посмотреть на Proxmox
. Простая установка и удобная панель управления через браузер привлекли сразу. Попробовал, потестировал, вроде все неплохо работает, управление удобное и понятное. Особенно понравились бэкапы из коробки. Не решался использовать в реальной работе, потому что не имею опыта работы c zfs, а ставить гипервизор на одиночные диски плохая идея. Раньше я использовал XenServer, установленный на mdadm raid1, пока он не перестал поддерживать такой режим работы. Proxmox почему-то не поддерживает установку на простой и понятный mdadm, но при этом есть zfs. Этот момент мне искренне не понятен, если учитывать, что proxmox работает на базе системы Debian, которая без проблем устанавливается на программный рейд.

В итоге я решил установить, настроить и протестировать proxmox, установленный на программный raid 1 mdadm. Диски отключал, вынимал, вставлял обратно. Все прекрасно работает. Отказоустойчивость на уровне дисков обеспечена, значит можно использовать в реальной работе. Я и использую последние пару лет. Отдельно упомяну, что меня сразу привлекло в KVM — возможность пробрасывать USB. До сих пор Hyper-V и XenServer не умеют это делать. Первый совсем не умеет, второй вроде как-то пробрасывает, но без гарантий и не все устройства работают. А в KVM без проблем получилось пробросить USB в виртуалку и воткнуть туда HASP ключ от 1С. Для малых и средних офисов это актуальная потребность.

Для того, чтобы установить proxmox на raid 1 пойдем окольным путем. Стандартный инсталлятор не дает нам необходимой возможности установки на рейд. У нас есть 2 варианта решения проблемы:

1. Установка сначала голой системы Debian 10 на raid1, а затем на нее устанавливается proxmox. Конечный результат не будет отличаться от инсталляции со стандартного диска.
2. Установить систему proxmox на одиночный диск, а потом перенести ее на raid1.

Я пробовал оба способа, первый мне показался более простым и понятным, поэтому займемся его реализацией.

На днях собирал для тестового кластера Proxmox
ноду в виде неттопа со встроенной сетевой картой RealTek. На удивление, она не заработала ни в Proxmox, ни в чистой Debian. Пришлось разбираться, в чем тут дело. Давно не сталкивался с подобными сетевыми проблемами. Когда на сервере нет сети, ты как без рук. Ничего установить или обновить нельзя, репозитории недоступны. Приходится через флешку что-то копировать и устанавливать.

Если у вас есть желание научиться администрировать системы на базе Linux, рекомендую познакомиться с онлайн-курсом «Linux для начинающих»
в OTUS. Курс для новичков, для тех, кто с Linux не знаком. Подробная информация
.

Полностью ошибка выглядела примерно так:

 [01448.532276] r8169 0000:09:00.0 enp3s0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
[01458.532277] r8169 0000:09:00.0 enp3s0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
[01468.532278] r8169 0000:09:00.0 enp3s0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).
[01478.532279] r8169 0000:09:00.0 enp3s0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100). 

Её было видно как в системном логе, так и на консоли сервера. Сеть не работала вообще. Меня это смутило, потому что во время работы инсталлятора Proxmox, проблем не было. Установщик получил по dhcp ip адрес на этой сетевой карте. А когда загрузилась система, сеть уже не работала.

Для проверки я установил чистый Debian 11. Ни установщик, ни сама система сеть не видели через сетевой интерфейс RealTek. Точная модель моей сетевой карты — RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
. Я немного погуглил и быстро нашёл причину ошибки. Стандартный драйвер Linux r8169 не поддерживает мою сетевую карту. Надо его отключать и вручную устанавливать другой — https://github.com/mtorromeo/r8168/releases
. Звучит несложно, когда у тебя работает сеть. А вот когда её нет, все процессы усложняются.

Для установки драйвера RealTek в Debian, необходимы следующие пакеты:

• build-essential
• linux-headers-`uname -r`

У первого будут какие-то зависимости. Сейчас уже точно не помню, какие именно. Так сети у нас нет, а вручную собирать пакеты со всеми зависимостями хлопотно, то я взял полный DVD-1
от Debian и подключил его в качестве репозитория. Для этого надо смонтировать флешку, куда записан этот DVD, в какую-то директорию, например /mnt
. В /etc/apt/sources.list
добавляем строку, закомментировав все остальные.

 deb [trusted=yes] file:/mnt bullseye main 

После этого обновляем кэш репозиториев и устанавливаем нужные пакеты:

 # apt update
# apt install build-essential linux-headers-`uname -r` 

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

 # tar -xzvf r8168-8.049.02.tar.gz
# cd r8168-8.049.02
# ./autorun.sh 

Делать всё нужно с правами root. Скрипт сам автоматически соберет новый драйвер, отключит старый и загрузит новый. Вам останется только заблокировать загрузку оригинального драйвера при старте системы, добавив его в blacklist:

 # echo "blacklist r8169" >> /etc/modprobe.d/blacklist.conf 

В завершении перезагрузил nettop и сеть заработала. Я получил миниатюрный тестовый сервер с процессором i5 и 16 гб оперативной памяти.

Далее я установил поверх Proxmox и сеть снова отвалилась с описанной в заголовке ошибкой. Это не удивительно, так как у Proxmox свое ядро. Необходимо еще раз установить драйвер RealTek в это ядро. Так как у нас почти все настроено, необходимо только установить ядро нужной версии. Посмотрите, какое установлено сейчас:

 # uname -r
5.11.22-4-pve 

Возьмите установочный диск с proxmox и смонтируйте его в /mnt
. В директории /mnt/dists/bullseye/pve/binary-amd64/
 будет пакет с исходниками ядра — pve-headers-5.11.22-4-pve_5.11.22-8_amd64.deb. Установите его:

 # dpkg -i pve-headers-5.11.22-4-pve_5.11.22-8_amd64.deb 

После этого заново соберите и установите драйвер, как я это сделал ранее для Debian. Для Ubuntu инструкция будет такой же один в один, только локальный репозиторий нужно будет подключать с диска Ubuntu.

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

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

Если обратиться к официальной документации
, то там будет рассказано о двух основных сетевых конфигурациях: с использованием моста и маршрутизации. Приведенные примеры покрывают основные сценарии использования и не углубляются в подробности, но различные комбинации настроек для этих вариантов позволяют реализовывать самые разнообразные сетевые конфигурации. В данном материале мы рассмотрим базовые возможности Proxmox, не касаясь объединения сетевых адаптеров или использования Open vSwitch, потому как это отдельные темы, лежащие за рамками базовой настройки.

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

Внешняя сеть

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

В основе всех виртуальных сетей в Proxmoх лежит сетевой мост
( Linux Bridge
) — vmbr
, допускается создание до 4095 таких устройств. Сетевой мост может включать в себя как физические, так и виртуальные адаптеры, выполняя для них роль неуправляемого коммутатора. Физическая сетевая карта, подключенная к мосту, не имеет настроек и используется как физический Ehternet-интерфейс для данного виртуального коммутатора. Все сетевые настройки производятся внутри виртуальных машин, которые через мост и физический адаптер прозрачно попадают во внешнюю сеть.

Фактически это сетевые настройки самого гипервизора. Обратите внимание, что сервера DNS указываются отдельно, в Система — DNS
:

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

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

Внешняя изолированная сеть

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

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

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

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

Внутренняя сеть с NAT

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

Все изменения сетевой конфигурации требуют перезагрузки узла гипервизора, поэтому, чтобы не перезагружать узел дважды перейдем в консоль сервера и перейдем в директорию /etc/network
, в котором будут присутствовать файлы interfaces
— с текущей сетевой конфигурацией и interfaces.new
— с новой, которая вступит в силу после перезагрузки.

Откроем именно interfaces.new
и внесем в конец следующие строки:

 post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.34.0/24' -o ens33 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.34.0/24' -o ens33 -j MASQUERADE 

В качестве сети, в нашем случае 192.168.34.0/24
, укажите выбранную вами сеть, а вместо интерфейса ens33
укажите тот сетевой интерфейс, который смотрит во внешнюю сеть с доступом в интернет. Если вы используете сетевую конфигурацию по умолчанию, то это будет не физический адаптер, а первый созданный мост vmbr0
, как на скриншоте ниже:

Перезагрузим узел и назначим виртуальной машине или контейнеру созданную сеть (vmbr1), также выдадим ей адрес из этой сети, а шлюзом укажем адрес моста.

Не забудьте указать доступный адрес DNS-сервера и убедитесь, что виртуальная машина имеет выход в интернет через NAT.

Внутренняя сеть

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

Частная сеть

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

Для такой сети просто создайте еще один сетевой мост без каких-либо настроек:

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

Организуем службы DNS и DHCP для внутренних сетей

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

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

В качестве серверов DNS и DHCP мы будем использовать уже известный нашим читателям пакет dnsmasq
, который является простым и легким кеширующим DNS и DHCP-сервером. Установим его:

 apt install dnsmasq 

Затем перейдем в конфигурационный файл /etc/dnsmasq.conf
и найдем и приведем к следующему виду параметры:

interface= vmbrl, vmbr2 

listen-address= 127.0.0.1, 192.168.34.2, 192.168.35.2

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

Затем укажем выдаваемые клиентам диапазоны адресов:

dhcp-range=interface:vmbr1,192.168.34.101,192.168.34.199,255.255.255.0,12h 

dhcp-range=interface:vmbr2,192.168.35.101,192.168.35.199,255.255.255.0,12h

Обратите внимание на формат записи, перед каждой настройкой мы указываем сетевой интерфейс к которой она применяется.

Аналогичным образом зададим нужные DHCP-опции, в нашем случае это Option 3 и 6 (шлюз и DNS-сервер).

dhcp-option=interface:vmbr1,3,192.168.34.2 

dhcp-option=interface:vmbr1,6,192.168.34.2 

dhcp-option=interface:vmbr2,3 

dhcp-option=interface:vmbr2,6

Сохраняем конфигурационный файл и перезапускаем службу

 service dnsmasq restart 

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

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

Базовая настройка proxmox

 You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options. 

У нас нет платной подписки, поэтому нужно удалить из списка репозиториев платный. Для этого открываем консоль сервера и закомментируем репозиторий:

 # mcedit /etc/apt/sources.list.d/pve-enterprise.list 

 #deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise 

Дальше видим главную страницу управления гипервизором proxmox 6.

Часто задаваемые вопросы по теме статьи (FAQ)

Как можно делать инкрементные бэкапы виртуальных машин в Proxmox?

Проблема инкрементных бэкапов в proxmox очень актуальна. Универсального решения, к сожалению, нет. На текущий момент инкрементные бэкапы возможны только на уровне хранилища для виртуальных машин, если оно это поддерживает. К примеру, с помощью zfs это можно организовать через механизм снепшотов. Какого-то аналога для бэкапов, типа Veeam, для Proxmox не существует.

Есть ли разница, разворачивать Proxmox на Debian либо через официальный ISO образ?

Принципиальной разницы нет. На выходе будет одна и та же система. Другое дело, что установив сначала Debian, у вас возникает больше возможностей для преднастройки дисковой подсистемы. К примеру, вы можете установить все на массив mdadm. Штатный установщик из ISO образа не дает такой возможности.

Чтло лучше использовать — виртуальные машины или контейнеры?

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

Есть ли какая-то принципиальная разница в чистом гипервизоре KVM по сравнению с Proxmox?

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

Можно ли в виртуальные машины Proxmox пробрасывать внешние IP адреса?

Да, в этом нет никаких проблем. Просто делаете бридж с интерфейсом гипервизора, на который приходят эти ip адреса и добавляете интерфейсы из этого бриджа в виртуальные машины. А на них настраиваете внешние IP адреса.

Можно ли в Proxmox пробросить USB в виртуальную машину? Например, для подключения токена или лицензионного ключа.

Да, то можно сделать. Гипервизор KVM, на базе которого построен Proxmox, давно поддерживает возможность проброса USB портов в виртуальные машины.

Установка proxmox на mdadm raid 1 в debian 10

Первым делом нам нужно установить чистую систему Debian
. На данный момент это версия 10 Buster
. У меня есть отдельная статья по установке Debian
. Там подробно описан процесс установки системы на софтовый рейд mdadm. В конце я на примере показал, что делать, когда диск выходит из строя, как его менять. Я на практическом примере продемонстрировал отказоустойчивость такого решения, поэтому не буду здесь подробно на этом останавливаться.

Скачивайте дистрибутив последней версии Debian. Взять его можно, к примеру, на Yandex. Mirror
, конкретно здесь
. Для установки подойдет образ CD-1
либо netinst
. Начинайте стандартную установку и доходите до пункта настройки жесткого диска. Я буду использовать консольное отображение, не графическое. Мне так удобнее. Принципиальных отличий нет, можете делать по аналогии, если начали установку в графическом режиме. Когда дело дойдет до настройки диска, выбирайте вариант ручной разметки.

Если вы делаете установку на чистые диски, то вас должна встретить такая картина состояния дисков:

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

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

Параметры первого раздела на 500 Мб:

Параметры второго раздела на 10 Гб:

Оба раздела должны быть Primary
.

Теперь создадим 2 отдельных raid массива на 500 мб и 10 гб. Выбираем раздел Configure Software RAID
, дальше Create MD device, потом RAID1, 2 диска в массиве, и в завершении выбираем 2 наших раздела по 500 мб:

То же самое делаем с разделами по 10гб — объединяем их в рейд:

Как закончите, жмете Finish. У вас должна получиться такая картина:

Теперь нужно создать файловую систему на рейд массивах. Сделаем на первом раздел /boot ext2, а на втором корень системы — / и файловую систему ext4. В итоге должно получиться вот так:

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

Игнорируйте его, потом подключим swap отдельно в виде файла. В процессе установки вам будет предложено выбрать набор пакетов. Не ставьте ничего лишнего, только ssh сервер и системные утилиты.

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

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

 # dpkg-reconfigure grub-pc 

На все вопросы оставляете дефолтные значения, в конце выбираете оба жестких диска для установки загрузчика:

На всякий случай проверим как встала система на жесткие диски:

 # df -h
Filesystem Size Used Avail Use% Mounted on
udev 3.9G 0 3.9G 0% /dev
tmpfs 798M 17M 782M 3% /run
/dev/md1 9.1G 1020M 7.7G 12% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/md0 460M 47M 390M 11% /boot
tmpfs 798M 0 798M 0% /run/user/0 

 # cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[1] sda1[0] 486400 blocks super 1.2 [2/2] [UU]
md1 : active raid1 sda2[0] sdb2[1] 9756672 blocks super 1.2 [2/2] [UU] 

Все в порядке, получилось так, как и задумывали. На данном этапе можно повынимать жесткие диски и проверить как система работает без одного из них, научиться заменять сбойный диск. Команды и рекомендации не буду приводить, чтобы не раздувать статью. Мануалов по работе с mdadm в интернете полно. К тому же, я об этом рассказываю в статье про установку debian, ссылку на которую уже давал ранее. Рекомендую сразу настроить мониторинг mdadm в zabbix
.

Переходим непосредственно к установке proxmox. Для этого редактируем файл /etc/hosts
и приводим его строго к следующему виду. Если что-то будет не так, как указано у меня, получите ошибку установки с очень большой долей вероятности. Я на этом моменте прилично застрял, когда разбирался.

 # mcedit /etc/hosts 

 127.0.0.1 localhost.localdomain localhost
192.168.155.104 proxmox6.local proxmox6 pvelocalhost 

Проверить правильность настроек можно командой:

 # hostname --ip-address
192.168.155.104 

В ответ должны получить свой ip адрес.

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

 # mcedit /etc/apt/sources.list 

 deb http://mirror.yandex.ru/debian/ buster main non-free contrib
deb-src http://mirror.yandex.ru/debian/ buster main non-free contrib
deb http://download.proxmox.com/debian/pve buster pve-no-subscription 

Если не подходит репозиторий яндекса (заблокирован), можно воспользоваться любым другим, например http://mirror.corbina.net/debian/

Добавляем цифровую подпись proxmox репозитория:

 # wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg 

Если раньше не обновили систему, то обновитесь и на всякий случай перезагрузите сервер после этого:

 # apt update && apt full-upgrade
# reboot 

Теперь устанавливаем саму систему виртуализации proxmox:

 # apt install proxmox-ve postfix open-iscsi 

Если получите ошибку во время установки:

 dpkg: error processing package proxmox-ve (--configure): dependency problems - leaving unconfigured
Errors were encountered while processing: pve-cluster libpve-access-control librados2-perl pve-firewall pve-ha-manager qemu-server pve-container pve-manager proxmox-ve 

Проверяйте файл hosts. У меня там лишние строки были, кроме тех, что я указал ранее. Когда исправил, установка прошла без ошибок. После окончания установки перезагрузите сервер, чтобы загрузилось новое ядро. Если все в порядке, то увидите окно приветствия на мониторе сервера:

Открывайте браузер по указанному адресу и заходите в web интерфейс. Напоминаю, что web порт proxmox по-умолчанию — 8006
. Не забывайте его указывать в строке адреса в браузере. Вы должны увидеть предупреждение браузера насчет сертификата. Так и должно быть, по-умолчанию используется самоподписанный сертификат.

Если у вас нет своего железа для установки proxmox, можно арендовать недорогой сервер у Selectel
. Линейка выделенных севреров Chipcore стартует с абонентки в 1500 р. в месяц. Через панель управления во время заказа сервера можно сразу выбрать proxmox, установленный на софтовый рейд mdadm. Самим ничего делать не нужно будет. Сразу получите отказоустойчивый настроенный гипервизор.

Хранилище для виртуальных машин

После чистой установки proxmox на debian, автоматически создается хранилище local
, которое располагается на одном разделе с самой операционной системой по адресу  /var/lib/vz
. Оно уже предназначено для хранения образов дисков, виртуальных машин и контейнеров.

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

Мы создадим еще один raid 1 mdadm
из незанятого места на дисках. Для этого нам нужно будет там создать разделы и объединить их в программный рейд с помощью mdadm.

Обращаю сразу внимание, что это тестовая среда, в реальности так диски разбивать не надо. Оптимально сделать raid 1 из двух отдельных под систему, заняв 30-50 гигов, остальное место на этом рейде отдать под iso образы и возможно бэкапы. Для виртуальных машин подключить отдельные диски и собрать из них рейд. Его уровень будет зависеть от количества дисков. Оптимально 4 штуки для raid 10

Смотрим имена дисков в нашей системе:

 # ls -l /dev | grep sd
brw-rw---- 1 root disk 8, 0 Aug 9 15:26 sda
brw-rw---- 1 root disk 8, 1 Aug 9 15:26 sda1
brw-rw---- 1 root disk 8, 2 Aug 9 15:26 sda2
brw-rw---- 1 root disk 8, 16 Aug 9 15:26 sdb
brw-rw---- 1 root disk 8, 17 Aug 9 15:26 sdb1
brw-rw---- 1 root disk 8, 18 Aug 9 15:26 sdb2 

У меня 2 диска sda
и sdb
. На них уже есть по 2 раздела, которые мы сделали во время установки системы. Создадим на каждом из них еще по одному разделу из всего оставшегося свободного места.

 # cfdisk /dev/sda 

Выбираем свободное пространство, создаем на нем раздел и указываем тип — Linux raid autodetect
.

То же самое делаем со вторым диском. После этих действий у вас должны появиться новые разделы /dev/sda3
и /dev/sdb3
. Чтобы это произошло, нужно либо перезагрузить сервер, либо перечитать таблицу разделов командой:

 # partprobe -s 

Если команда не найдена, установите parted
:

 # apt install parted 

Проверим новые разделы:

 # ls -l /dev | grep sd
brw-rw---- 1 root disk 8, 0 Aug 9 15:40 sda
brw-rw---- 1 root disk 8, 1 Aug 9 15:40 sda1
brw-rw---- 1 root disk 8, 2 Aug 9 15:40 sda2
brw-rw---- 1 root disk 8, 3 Aug 9 15:40 sda3
brw-rw---- 1 root disk 8, 16 Aug 9 15:40 sdb
brw-rw---- 1 root disk 8, 17 Aug 9 15:40 sdb1
brw-rw---- 1 root disk 8, 18 Aug 9 15:40 sdb2
brw-rw---- 1 root disk 8, 19 Aug 9 15:40 sdb3 

Теперь объединим только что созданные разделы в raid1:

 # mdadm --create /dev/md2 --level=1 --raid-disks=2 /dev/sda3 /dev/sdb3 

 mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started. 

Проверим информацию о mdadm:

 # cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdb3[1] sda3[0] 42140672 blocks super 1.2 [2/2] [UU] [=>.] resync = 9.4% (4001792/42140672) finish=3.0min speed=210620K/sec
md0 : active raid1 sdb1[1] sda1[0] 486400 blocks super 1.2 [2/2] [UU]
md1 : active raid1 sdb2[1] sda2[0] 9756672 blocks super 1.2 [2/2] [UU] 

Все в порядке, массив синхронизируется. Дождитесь окончания синхронизации и продолжайте. Хотя это не обязательно, массив и сейчас уже готов к работе, он он будет сильно тормозить во время ребилда. Добавим информацию о новом массиве в конфигурационный файл /etc/mdadm/mdadm.conf
, иначе после перезагрузки массив не будет виден в системе:

 # mdadm --examine --scan | grep 'md/2' >> /etc/mdadm/mdadm.conf 

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

 # cat /etc/mdadm/mdadm.conf 

 # mdadm.conf
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf

for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system
HOMEHOST

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=a214eb8b:c3ff0ab2:13197140:25a25924 name=proxmox6:0
ARRAY /dev/md/1 metadata=1.2 UUID=1d5a52f3:7caa923c:b8f13836:8a7bcf54 name=proxmox6:1

# This configuration was auto-generated on Fri, 09 Aug 2019 13:59:40 +0300 by mkconf
ARRAY /dev/md/2 metadata=1.2 UUID=30be9c4e:6a351eca:6d66228d:ee695c19 name=proxmox6:2

Дальше у нас 2 пути:

1. Создать файловую систему на md2, смонтировать раздел в систему и создать storage в виде обычной директории
   , такой же, как по-умолчанию.
2. Создать том LVM
   и на его основе storage.

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

 # pvcreate /dev/md2
File descriptor 7 (pipe:[31619]) leaked on pvcreate invocation. Parent PID 2856: bash Physical volume "/dev/md2" successfully created. 

Создадим группу томов:

 # vgcreate raid1-md2 /dev/md2
File descriptor 7 (pipe:[31619]) leaked on vgcreate invocation. Parent PID 2856: bash Volume group "raid1-md2" successfully created 

Теперь идем в web интерфейс, выбираем Datacenter, вкладку , жмем Add и выбираем LVM:

Указываем параметры только что созданной группы томов.

Все готово. Новый storage добавили. Его можно использовать для хранения дисков виртуальных машин.

Добавление и подключение диска

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

Я подключил новый жесткий диск, проверим его имя в системе:

 # ls -l /dev | grep sd 

 brw-rw---- 1 root disk 8, 0 Aug 9 15:40 sda
brw-rw---- 1 root disk 8, 1 Aug 9 15:40 sda1
brw-rw---- 1 root disk 8, 2 Aug 9 15:40 sda2
brw-rw---- 1 root disk 8, 3 Aug 9 15:40 sda3
brw-rw---- 1 root disk 8, 16 Aug 9 15:40 sdb
brw-rw---- 1 root disk 8, 17 Aug 9 15:40 sdb1
brw-rw---- 1 root disk 8, 18 Aug 9 15:40 sdb2
brw-rw---- 1 root disk 8, 19 Aug 9 15:40 sdb3
brw-rw---- 1 root disk 8, 32 Aug 9 15:40  sdc  

Можно не создавать на диске раздел, а сразу его инициализировать для работы в lvm и создать группу томов:

 # pvcreate /dev/sdc
# vgcreate disk-sdc /dev/sdc 

Идем в веб интерфейс и создаем новый storage:

Если у вас будет не одиночный диск, а несколько, то перед этим создайте рейд массив из них и так же поверх накатывайте lvm и добавляйте новый storage. На этом настройку локальных хранилищ завершаем. Все основные действия мы выполнили, можно начинать работать с системой — создавать виртуальные машины.

 Хранилище по NFS

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

Я это хранилище буду использовать только для iso образов и backup’ов, поэтому выставляю соответствующие настройки.

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

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

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

Чтобы установить виртуальную машину, нужно использовать iso образ
. Его надо как-то загрузить на proxmox. Сделать это не сложно, нужно только понимать, что загрузить образ можно только на тот storage, который поддерживает такую возможность. Сторейджи LVM не позволяют загружать образы, для этого нужно использовать, например, storage в виде локальной директории. По умолчанию, один такой есть в системе. В него и загрузим образ виртуальной машины. Для этого открываем нужный storage и выбираем вкладку . Жмем на Upload
и выбираем нужный образ.

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

Альтернативный способ загрузки iso образа в proxmox — использовать scp или напрямую через wget качать образ из интернета. Положить его нужно в директорию /var/lib/vz/template/iso
, если используете дефолтный storage, добавленный по-умолчанию после установки.

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

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

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

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

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

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

Рассмотрим простой пример. У нас есть виртуальная машина, к примеру Windows Server с ролью Active Directory на борту. Все остальные серверы завязаны на корректную работу службы каталогов. Нам надо сначала запустить контроллер домена, а затем все остальные серверы за ним. Установите параметр Start at boot
 в положение Yes для всех виртуальных машин, которые хотите запускать автоматически. Укажите Start/Shutdown order
 на контроллере домена 1, Startup delay
240, Shutdown timeout
120. С такими настройками при запуске гипервизора первой стартует виртуальная машина с КД, через 240 секунд все остальные в соответствии с их настройками.

Backup виртуальных машин

Подошли к очень важному этапу настройки proxmox — организация бэкапа виртуальных машин. На этот момент нужно обратить особенное внимание, и все хорошенько проверить. Настраивается backup так же просто, как и все остальное в proxmox. Идем в раздел Backup и создаем задание:

Выставляем необходимые параметры, например такие:

Ждем назначенного часа и проверяем исполнение задания.

Для того, чтобы выполнить разовый бэкап конкретной виртуальной машины, достаточно открыть виртуальную машины, выбрать в ней раздел Backup и нажать Backup Now
:

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

Тут сразу встает следующий вопрос — как автоматически удалять старые бэкапы? Однозначно ответить не получится, все будет зависеть от того, где будут храниться бэкапы. Если это обычный linux сервер с доступом к консоли, то можно воспользоваться программой find
:

 # /usr/bin/find /mnt/backups-vm -type f -mtime +30 -exec rm {} \; 

После выполнения этой команды, все файлы в папке /mnt/backups-vm
старше 30 дней будут удалены. Для автоматизации процесса команду можно поместить в cron
. С помощью zabbix
 вы можете мониторить актуальность бэкапов
и следить за их размерами
.

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

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