Proxmox видеокарта для виртуальной машины

Каким образом пробросить видеокарту внутрь виртуалки Proxmox?

Здравствуйте, господа. Имеется материнка ASRock J5005-ITX, где установлен Proxmox 6 поверх Debian 10. Осваимваю виртуализацию и пытаюсь пробросить интегрированную карточку Intel UHD Graphics 605 внутрь гостевой ОС Windows 10.

В /etc/default/grub прописал:

В /etc/modules прописал:

В /etc/modprobe.d/pve-blacklist.conf добавил:

В /etc/modprobe.d/vfio.conf добавил:

И, наконец, выполнил:

и перезагрузился. После перезагрузки вывод lsmod | egrep «kvm|vfio»:

Подскажите, пожалуйста, почему не создаётся директория mdev_supported_types по пути /sys/bus/pci/devices/0000:00:02.0/?

пытаюсь пробросить интегрированную карточку

Брось эту затею. Даже если получится, после очередного обновления развалится.

Мне нужно, чтобы в гостевой ОС видеокарточка работала с аппаратным ускорением и с максимальной производительностью. Быть может, я неправ в своём предположении, но мне почему-то кажется, что второй вариант у меня не прокатит, поскольку камень, скорее всего, GVT-g не поддерживает. Повторюсь: это всего лишь предположение. Посему остаётся 1-й вариант. Но и в нём сложность: по ходу мануала не удаётся извлечь ROM:

Должно же быть изображение в noVNC

Нет, noVNC только с виртуальной видяхи работает.

А каким образом, в таком случае, добиться изображения на реальной (проброшенной) видюхе?

подключить к ней настоящий монитор

Монитор по HDMI и так подключен настоящий. При запуске виртуалки изображение, передаваемое по HDMI пропадает (до запуска выводился syslog). No Signal и всё. Не пойму, в какую сторону копать.

1. Скачал с официального сайта архив с той же версией UEFI, которая зашита в материнку.
2. С помощью утилиты MMTool из UEFI извлёк дамп vBIOS интегрированной видюхи (8086:0406)
3. С помощью утилиты rom-parser/rom-fixer изменил VID\PID в извлечённом дампе на реальные (8086:3184)
4. С помощью rom-parser выяснилось, что видюха не поддерживает режим OVMF (UEFI), посему пришлось настроить виртуалку под SeaBIOS.
5. Скормил ранее извлечённый и модифицированный дамп vBIOS виртуалке:

Источник

proxmox проброс видео карты в виртуальную машину

Доброго времени суток.

Пытался пробросить видео карту в виртуальную машину по статье (https://habr.com/ru/post/437598/), но не удачно.

При указании параметров конфига /etc/modprobe.d/vfio.conf после перезагрузки система зависает. ( помогает только hardreset )

Если не прописать туда параметры видео карты, то загрузка проходит. Более того в виртуальной машине я могу увидеть видео карту и даже могу попытаться поставить на неё драйвера, но потом будет BSOD ( то-ли не так версия драйвера то-ли видео карта не до конца проброшена ( скорее всего последнее ))

в BIOS активны vt-d опции и intel_iommu включен

Характеристики:
OS: proxmox 6.3-2 ( debian 10 )
CPU: Intel(R) Xeon(R) CPU E5-2628 v3
MB: QIYIDA X99-H9
RAM: 8GB

тестируемые видео карты:

1 ответ 1

Решение

Я купил себе еще одну дешевую видео карту и т.к. на моей материнской плате отсутствовал второй слот купил еще и расширение ( за 300р ) для подключения второй видиокарты.
В райзер я подключил видео карту которую я буду пробрасывать в виртуалку, а в слот видео карты на метеринке воткнул дешевую видео карту в качестве затычки.
После через web proxmox добавил видео карту в виртуалку, уже в самой виртуалке доставил драйвера и поставил галочку Primiry GPU. Все видео карта успешно проброшена.
Проброс успешно удался, в качестве теста запустил Portal 2 через steam link, все ок без проседаний.

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

фото платы-расширения для подключения второй видео-карты ( райзер для видео карты )

Источник

GPU (desktop/laptop) Passthrough (Проброс видеокарты в ВМ) в ProxMox. Нюансы настроек. переезжаем в Linux

Comments 25

А есть какая-то возможность организовать всё это при следующих условиях:
— монитор лишь один (с 2 входами и возможностью переключения между ними в настройках монитора)
— видеокарта без портов (т.е. она работает чисто как 3D-ускоритель, передавая картинку на встроенную графику по PCI-E)

таким образом, сетап соответствует схеме

«

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

Есть еще один вариант, это проброс интегрированной ВК в ВМ, судя по всему работает почти на любом ЦП от Интел, начиная с 4го поколения, но конкретно под ProxMox’ом работает медленно, есть вопросы по выводу изображения на дисплей. Гуглится по gvt-d

Встройку можно и целиком пробрасывать, как и отдельную видяху. И вывод на монитор будет работать без особых проблем. Даже звук по HDMI можно передавать, если ещё и встроенный звук пробросить.

Я глубоко не копал, но пробросить встройку как отдельную ВК в ВМ у меня не получилось с наскока. Чисто теоретически в этом случае изображение пойдет, для ноутбука, не на внешний дисплей, а на дисплей ноутбука, что сделает работу комфортной. Конечно мыслится что если физически прокинуть ядра ЦП + встройку + дискретку, то получим на выходе тот же ноутбук, но в виртуалке. Но практически пока что у меня не получилось.

Возможно это будет следующая тема для моей новой статьи.

Не совсем понимаю, зачем вообще это на ноуте?

А ещё если на ноуте есть дискретное видео, то в схеме «Muxed» дискретное видео не сможет выводить картинку на экран, хотя и будет доступно в хост-системе (т.к. мультиплексор управляется встроенной видяхой, а она недоступна хосту при пробросе в виртуалку)

Лично я этой темой заморачивался т.к. у меня неттоп, который и роутер и файлопомойка и куча чего ещё чисто серверного. И я решил, до кучи, сделать из него ещё и медиацентр (Kodi, Steam, RetroArch и т.д.) причем с виндой в отдельной виртуалке с возможностью подключать физическую клаву/мыш/геймпад

Не совсем понимаю, зачем вообще это на ноуте?

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

Лично я этой темой заморачивался т.к. у меня неттоп, который и роутер и файлопомойка и куча чего ещё чисто серверного. И я решил, до кучи, сделать из него ещё и медиацентр (Kodi, Steam, RetroArch и т.д.) причем с виндой в отдельной виртуалке с возможностью подключать физическую клаву/мыш/геймпад

на чем реализовывали? каким гайдом пользовались для настройки?

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

Конфиг самой виртуалки с виндой и проброшенной встроенной видяхой

В «args» идут два параметра:

Ps: До чего же неудобный и кривой редактор текста на хабре. жуть.

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

Как по мне бэкап виртуалок удобнее и проще. Не нужно перезагружаться например, для отката. Я могу разворачивать несколько копий из бэкапа на одном и том же диске и ставить их параллельно. Акронис такое не позволит без танцев с бубном.

На Хосте Линукс, если настроить сеть для ВМ без доступа в интернет, то сохранность данных на виртуалке резко повышается, а всяких вирусов под линукс сильно меньше чем под винду.

Гипервизор себя ничем не выдает внешне, с учетом того что Линукс для большинства пользователей темный лес, то даже при попадении ноутбука в чужие руки, например хозяин ушел на обед, а вагончик ПТО оказался открытым с техникой для технадзора, то вытащить оттуда инфу он не сможет. Даже если вынет диск физически.

Интересно. Нужно будет пробовать.

у вас получилось изолировать устройство? У меня на домашнем ПК не вышло, в итоге вылетает вся группа, а в ней LAN. и привет сеть и тырнет.

у вас получилось изолировать устройство?

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

Моя IOMMU группа со звуковухой

Не знаю, как, но SMBus, ISA, MemControl не прокинулись в виртуалку. Только звук. Остальное осталось в хосте и, вродь как, работает.
Ps: Сетевухи у меня все в отдельных группах (6 штук!)

Даже если вынет диск физически.

И VirtualBox с виндой, если очень надо.

Не знаю, как, но SMBus, ISA, MemControl не прокинулись в виртуалку. Только звук. Остальное осталось в хосте и, вродь как, работает.

для их проброса в ВМ нужно принудительно прописывать, для хоста они тоже отваливаются, после старта ВМ с проброшенной звуковой картой введите на хосте lspci

специалисту да это возможно, или good user’у, но у меня на участке народ не такой продвинутый что бы разобраться что на хосте с Линуксом крутится виртуалка и все данные в ней. Особенно если еще и Линукс затюнить под винду. Хотя на счет этого я еще не определился. За условные 10-30мин они не разберутся, мне этого достаточно. А если требуется отсутствовать дольше, то я всегда уношу с собой ноутбук в спец рюкзаке.

А GVTd-D — это именно виртуальные ускорители графики
Нет это именно проброс всей видяхи. И правильнее GVT-d, а виртуальные это GVT-g

Работать будет, но будет очень небольшой лаг, связанный с копированием памяти из дискретной GPU в встройку — именно этим и занимается Looking Glass.

4.1 Linux при настройке локального времени почему-то считает что время установленное в BIOS это время по Гринвичу (GMT+0), в соответствии с локализацией к этому времени добавляются еще свой родной часовой пояс, MSK (GMT+3) в случае автора.

Про формат времени спасибо! Буду пробовать.

4.1 Linux при настройке локального времени почему-то считает что время установленное в BIOS это время по Гринвичу (GMT+0), в соответствии с локализацией к этому времени добавляются еще свой родной часовой пояс, MSK (GMT+3) в случае автора. В то время как Windows время из BIOS считает местным, в зависимости от настроек часового пояса в системе юзера. Таким образом, если Linux стоит дуал-бутом в Windows и Linux, местное время в двух ОС принимает разницу в 3 часа. Немного неудобно.

скорее наоборот windows почему-то по умолчанию хранит время не в utc.
получается чтобы узнать какое время хранится в rtc, нам нужно где-то хранить стороннюю информацию: в каком часовом поясе мы находимся и был ли произведён переход на летнее/зимнее время.
например, в случае использования нескольких ос на одном компьютере мы получаем проблему с синхронизацией этой информации между ними.

И возникают одни вопросы, что такое сенсоры: temp1, Sensor 1, Sensor 2?

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

Где тут температуры дискретной ВК

не подскажу, у меня как-то везде интегрированное видео.
возможно, их тут вообще нет )

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

fancontrol у меня не установился

не установился или не получилось управлять оборотами кулеров? если второе, то, как я понимаю, это нормально для ноутбуков (
хотя могу ошибаться, у сейчас на руках только один нотбук с linux, оборотами там управляет bios, всё просто работает, не было даже повода разбираться.
то же самое с настольным компьютером: fancontrol работает, но схема из bios меня полностью устраивает, поэтому fancontrol удалил, зачем мне дополнительная потенциальная точка отказа.

fancontrol от Tuxedo в Debian ставится отказывается, в то время как tuxedo-control-center встал со скрипом… видимо в данном случае совместимость софта между Ubuntu и Debian не полноценная, а может быть я чего-то не знаю/не учел

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

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

Но если всё железо отдавать гостю в монопольное владение, то может её загружать прямо на железе? Тогда я так и сделал. Вы не рассматривали вариант без виртуализации?

Работа в виртуальной машине имеет как свои плюсы, так и свои минусы, например виртуалку проще бэкапить и разворачивать, можно настраивать под разные задачи и прятать ее. С другой стороны ее работа требует определенного железа, обычно виртуалке не выделяется 100% ресурсов, пусть минимальные, но есть потери на виртуализацию, порядка 2-5%. Виртуализация это инструмент.

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

Согласен с вами, потеря ресурсов почти всегда минимальная. Но отзывчивость (latency) системы сильно страдает. Кстати, в вашем способе прокидывания дисков на виртуалку сильно падает скорость? Когда проверял на qemu, то хорошие результаты почти без потерь iops получил только с hostdev type=’scsi’. Но в последних версиях он считается не самым быстрым.

В этом видео есть тесты скорости дисков

В первом случае это тест скорости чтения/записи в виртуальный SATA диск, который базируется на 2.5″ SATA SSD Kingston 480Gb, второй тест это тест 3.5″ SATA HDD WD Red 4Tb проброшенного в виртуалку напрямую, но без контроллера sata1: volume=/dev/disk/by-id/ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9

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

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

Так что последние NUC-и не советую брать, если интересует хоть какое-то использование интел графики в виртуальном окружении. Сам попал на это — лучше бы купил решение на амд. У интела обычно все лучше в плане дров для встройки под линуксом, но с последними они что-то накосячили и kvm/qemu с ними не работает нормально (вернее нужен специальный патченный видеобиос которого конечно же нет в наличии)

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

Также плохо работает на старых интелах, где нет поддержки в процессоре и с старыми bios

Также плохо работает на старых интелах, где нет поддержки в процессоре и с старыми bios

Ну это на ооочень старых интелах.

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

Но оно хотя бы работает. Т.е. если нужен Single GPU Passthrough и какой либо из новых процов, то тут только амд, т.к. повторюсь, что на 11-м поколении интела и выше пока что это не возможно (и бубен не поможет). И еще раз повторюсь что это есть в ACRN-е от интела, но продукт уж очень специфический и довольно таки глючный (хоть и очень интересный по фичам — например из коробки есть поддержка прямого вывода виртуальной GVT-g карты на hdmi и т.д.). И все бубны при настройке виртуалок и графики на амд, просто цветочки по сравнению с установкой и настройкой ACRN-а

начиная с 6-й версии ProxMox’а для случаев когда юзер для ВМ использует БИОС UEFI, а иначе ВК не пробросить в ВМ

Отлично всё работает на любом BIOS’е. Просто требуются разные шаманские обряды, чтобы оно заработало.

Вопрос для понимания, пока на стадии изучения и тестирования (могу немного путать теплое с мягким))):

В чем принципиальное отличие в виртуализации и организации массивов и ФС, кроме графической оболочки:

Proxmox от Debian + |KVM + IOMMU| + |LXC| + |RaidZ + ZFS|

Unraid от Debian + |KVM + IOMMU| + |Docker| + |Snapraid + XFS + BTRFS|

OMV от Debian + |KVM| + |Docker| + |Mdraid + ext4 + RaidZ + ZFS|

Понятно что функционал бегло по основному (для меня сейчас), хочется понять что принципиально нового, удобного, полезного в выборе данных оболочек против Linux с установленными и настроенными модулями вручную?

Кто хочет кидайте тапки, но вот начал выбирать систему (FreeBSD не рассматривал), принципы реализации, и получается что в каждом варианте ИМХО есть четко выраженные взгляды создателей оболочек, систем (называйте как угодно), и приходится подстраиваться, либо править то, что не рекомендует создатель и при обновлении модулей оболочки что-то да имеет большую вероятность «полететь». В каждой из этих систем так или иначе для тонкой настройки приходится лазить под капот, дак не проще ли сразу под капот засунуть все что требуется без шилдика?

Например я хочу использовать |KVM + IOMMU| + |Docker|+ |LXC|+ |Mdraid + Snapraid + ext4| + Оболочку для мониторинга и быстрой корректировки как у OMV, но не OMV, но оболочка дело привычки ей как раз можно пренебречь и поставить тот же Webmin или Cockpit, хотя и тот и другой как две противоположности мне не зашли, лучше вообще без оболочки и пользоваться окружением через VNC если припрет «пощелкать» по визуальному интерфейсу + добавить приблуду для мониторинга по типу Grafana.

Верно ли я понял, что чего-то принципиально революционного отличающегося от чистого Linux Debian, Ubuntu, и прочих + нужные приложения и модули, в подобных оболочках нет?

Хочется услышать мнение опытных практиков. Спасибо.

Источник

Установка и настройка Proxmox VE

Используемые термины: Proxmox VE, Linux.

В данной инструкции мы пошагово разберем способы установки Proxmox VE, базовую настройку и создание виртуальной машины. Proxmox основан на Debian — поэтому установку будем выполнять на данный дистрибутив Linux. В данной инструкции работа ведется на Proxmox версии 6.

Системные требования

Требования разделены на минимальные и рекомендованные:

Установка

Есть два варианта установки Proxmox VE — использовать готовый образ или установка на Debian. Мы рассмотрим оба.

Установка готового образа ISO

1. Переходим на страницу загрузки Proxmox официального сайта. Загружаем дистрибутив, например, Proxmox VE 6.1:

2. Если установка выполняется на виртуальную машину, монтируем образ. Если нет — создаем установочную флешку, например, с помощью WinSetupFromUsb или загрузочный диск с помощью InfraRecorder.

3. Загружаем сервер с установочного ISO — мы увидим окно приветствия Proxmox — выбираем пункт меню Install Proxmox VE:

4. Принимаем лицензионное соглашения, кликнув по I agree.

5. Выбираем диск, на который будет установлена система:

* при необходимости, кликаем по Options и задаем настройки файловой системы и размера раздела.

6. Пишем страну, временную зону, язык раскладки клавиатуры по умолчанию:

7. Вводим дважды пароль, который будет использоваться для пользователя root:

8. Прописываем сетевые настройки:

9. В окне «Summary» проверяем введенные данные и кликаем по Install. Начнется процесс установки, который займет не более 10 минут.

10. После установки мы должны увидеть «Installation Successful» — перезагружаем сервер, кликнув по кнопке Reboot.

После переходим к проверке установки.

Установка на Debian

Если мы решили установить Proxmox на уже установленный Debian, выполняем следующую инструкцию.

При установке среды виртуализации меняется ядро Linux. Это может привести к потери работоспособности уже установленных сервисов. Таким образом, установку Proxmox следует выполнять на чистый сервер, а не тот, который уже используется для каких-либо задач.

1. Имя сервера должно разрешаться по его IP-адресу. Для этого либо добавляем А-запись в DNS, либо настраиваем на сервере файл hosts:

192.168.1.55 proxmox.dmosk.local proxmox

* где 192.168.1.55 — IP-адрес нашего сервера; proxmox — имя сервера; dmosk.local — наш домен, если используется.

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

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

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

Обновляем список пакетов:

3. Устанавливаем Proxmox PE и компоненты:

apt-get install proxmox-ve open-iscsi

* где proxmox-ve — собственно, сам гипервизор; open-iscsi — iSCSI-клиент для подключения iSCSI-target-ов.

4. Перезагружаем сервер:

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

В браузере открываем панель управления системой виртуализации по адресу https:// :8006. В открывшемся окне выбираем язык, вводим логин и пароль от пользователя root:

Должно открыться окно управления.

Начальная настройка

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

1. Загрузка образов

Переходим в раздел Содержимое и кликаем по Загрузить:

В открывшемся окне выбираем ISO-образ системы, который будем устанавливать в качестве гостевой и кликаем по Загрузить. Ждем окончания копирования файла на сервер.

2. Создание сети для виртуальных машин

Мы рассмотрим примеры создания 2-х режимов сети — Bridge и NAT.

Независимо от способа установки Proxmox, необходимо подключиться к хосту по SSH и установить пакет ifupdown2 командой:

apt-get install ifupdown2

* ifupdown2 — утилита для конфигурации сетевого интерфейса (по сути, аналог ifupdown, написанный на языке Python).

. в противном случае, при попытке применить сетевые настройки мы получим ошибку you need ifupdown2 to reload networking (500).

Bridge

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

Работать с режимом Bridge нужно очень осторожно. Любое неправильное действие и удаленный доступ к серверу будет потерян. Если работы ведутся на удаленном сервере, рекомендуется сначала потренироваться на какой-нибудь локальной машине.

Также стоит отметить, что при установке PVE из установочного ISO-образа, один Bridge уже будет создан.

. иначе, создавать его не обязательно.

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

* если мы не сделаем этого, то при настройке Bridge мы получим ошибку Parameter verification failed. (400). gateway: Default gateway already exists on interface ‘ens160’.

Нажимаем Создать и выбираем Linux Bridge:

В открывшемся окне заполняем поля IPv4/CIDR, Шлюз (IPv4), Порты сетевого моста:

* в данном примере мы задаем IP-адрес, на котором будет работать Proxmox (чтобы ничего не перепутать, можно задать IP-адрес физического интерфейса, который будет задействован под Bridge); маска указывается в нотации CIDR и в нашем примере это 24 или 255.255.255.0; в качестве физического интерфейса наш bridge будет использовать ens160.

. нажимаем Создать.

Кликаем по Apply Configuration, чтобы применить сетевые настройки:

Данный режим сети активно применяется в случае аренды сервера, где количество IP-адресов лимитировано. В данном случае, все виртуальные машины будут находисться за NAT, в качестве которого выступает сам Proxmox.

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

Создание нового bridge-интерфеса

Оставляем имя vmbr1 или пишем любое другое, прописываем IP-адрес с маской сети, в которой будут находиться серверы за NAT:

Нажимаем Создать. Применяем настройки:

Настройка ядра и брандмауэра

Подключаемся к серверу по SSH. Открываем на редактирование файл настройки ядра:

. и добавляем разрешение на редирект:

После применяем настройки:

Добавляем правило в брандмауэр:

* в данном примере мы создали правило для маскарадинга всех пакетов из подсети 192.168.122.0/24 и для исходящего интерфейса vmbr0. Обратите внимание, что если у нас будет другая подсеть и исходящий интерфейс для сети Интернет, то нужно будет задать другие значения.

Ставим утилиту для сохранения правил iptables:

apt-get install iptables-persistent

. и сохраняем правила в процессе установки или командой:

Сеть между виртуалками

Данная сеть — частный случай NAT без выхода в Интернет. Мы должны создать бридж с отдельной подсетью без шлюза. При добавлении виртуальным машинам данного сетевого адаптера мы сможем настроить их взаимодействие по внутренней сети.

Создаем бридж, как делали это ранее:

Создаем интерфейс. Готово — при создании или редактировании виртуалок, мы можем указывать с качестве интерфейса созданный бридж (в данном примере, vmbr2) для изоляции их в отдельную подсеть 192.168.150.0/24.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезные настройки

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

Для изменения параметра, просто кликаем по нему дважды, меняем значение и нажимаем OK.

Добавление дискового накопителя

В открывшемся окне задаем размер диска и нажимаем OK.

Для увеличения размера имеющегося диска устанавливаем на него курсов и кликаем по Изменить размер диска:

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

Добавление сетевого адаптера

Как при создании ВМ, выбираем тип сетевого адаптера (бридж или нат) и нажимаем Добавить.

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

В открывшемся окне мы должны подтвердить свои намерения удалить виртуальную машину, вписав ее идентификатор:

* если мы поставим галочку Purge, то виртуальная машина будет удалена полностью вместе с виртуальным диском.

Кликаем по Удалить — готово.

Тюнинг сервера PVE

Внесем несколько изменений, которые сделают работу с Proxmox VE удобнее.

Отключение предупреждения об отсутствии подписки

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

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

И так, в SSH открываем на редактирование репозиторий proxmox:

Приводим его к виду:

#deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
deb http://download.proxmox.com/debian/pve stretch pve-no-subscription

* мы закомментировали репозиторий pve-enterprise и добавили pve-no-subscription.
* при большом желании, можно удалить файл репозитория с именем pve-enterprise.list и создать новый — кому как будет удобнее.

После обновим список пакетов:

Последнее — редактируем файл /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js:

* данной командой мы находим getNoSubKeyHtml в файле /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js и меняем на getNoSubKeyHtml_.

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

Сертификаты

Сервер PVE устанавливается с самоподписанным сертификатом. Это означает, что при подключении к панели управления мы будем видеть предупреждение от системы безопасности. Чтобы браузер принимал сертификат, он должен соответствовать следующим требованиям:

При этом, мы не должны заходить в панель управления по IP-адресу — в противном случае, независимо от сертификата, мы все-равно, получим предупреждение.

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

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

Создание нового пользователя

При установке PVE создается пользователь root. Рассмотрим процесс добавления еще одного через командную строку.

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

* где user — имя создаваемого пользователя.

После создаем нового пользователя в Proxmox:

pveum useradd user@pam

* в данном примере мы создали пользователя user в области pam.

pveum passwd user@pam

Задаем роль для созданного пользователя, например, административную:

Ubuntu и CentOS

Возможно, кому-то захочется установить Proxmox именно на Ubuntu или CentOS. К сожалению, разработчики остановились на Debian. Возможно, есть неофициальные обходные пути установки Proxmox на другие дистрибутивы Linux, однако такой путь не является приемлемым для продуктивной среды. Для настройка виртуализации на Ubuntu и CentOS предлагаю инструкции:

Источник