Proxmox windows 10 не видит сеть - Доктор Windows

Hey,

I’m doing a fresh install of Proxmox 7 via the official ISO.

The installation finishes without any issues, server boots as expected, the NIC is listed, network settings are successfully applied.

But unfortunately, even if everything seems to be fine, I have no network connectivity. I can’t even ping the gateway.

Please note that the same machine has zero networking issues if upgraded from 6 to 7. The aftermentioned issue is only when doing a fresh ISO install.

Any hints? Where should I start looking? What logs are necessary in order to debug this?

Thank you

I came in to ask same thing. Have tried upgrade and fresh install, neither has network connectivity. I should say both of my are into a VM on Hyper-V, which is my third machine in my quorum without intention of hosting other vms.

Solved it by adding the following line under iface vmbr0 inet static in /etc/network/interfaces
hwaddress XX:XX

The XX:XX is the full mac address of the physical interface.

I upgraded to 7 with apt. The installation went well but after reboot, I had no network connectivity. I use Intel i219-LM on a ThinkCentre M90n. After the reboot, e1000e complains that it couldn’t probe the interface and errored with -2. Backed up my data over USB and then formatted and reinstalled Proxmox 7 with iso. Installed alright but e1000e cannot probe. I formatted and installed Proxmox 6.4 latest iso, apt update (with the iso’s apt repos) and everything still works after a reboot. If I add the no-subscription repo and apt upgrade, upon reboot, the same problem happens. I then went back to the EFI bootloader and selected the old kernel and this kernel also shows the problem. There are only a few packages which are upgraded from the iso to the latest, but the same problem happens for me on Proxmox 6, so maybe a recent & common change in Proxmox? Because it cannot probe the interface, it doesn’t show me the adapter in `ip addr` but I do show the network adapter when I run lspci. Read a variety of articles that say it’s probably WOL features but I disabled that capability in the BIOS and still couldn’t get the adapter to come up.

Last edited: Jul 8, 2021

Is there any fix/feedback from Proxmox Staff? It seems like a common issue. Thank you

Is there any fix/feedback from Proxmox Staff? It seems like a common issue. Thank you

Are you in a restricted network that restricts MAC-addresses a server can use, e.g., like the environments of hosting provider often do?

VLAN or some settings like that, that were still configured on the upgraded host but not yet on the fresh installed one?

Are you in a restricted network that restricts MAC-addresses a server can use, e.g., like the environments of hosting provider often do?

VLAN or some settings like that, that were still configured on the upgraded host but not yet on the fresh installed one?

Nope, none of above. When installing any other distro, including Proxmox 6, everything works as expected.

I can provide logs if required, just let me know what I should post. Thank you

Yes please, the following exhaustive information could be of help:

Code:

ip -d addr
ip ro
lspci -knn
cat /etc/network/interfaces

to get an overview and rule a few things out, if we’re lucky it’s just a little, overlooked config error — would prefer that over some weird difference between upgrade/fresh installation

Yes pleas, the following exhaustive information could be of help:
Code:
ip -d addr
ip ro
lspci -knn
cat /etc/network/interfaces
to get an overview and rule a few things out, if we’re lucky it’s just a little, overlooked config error — would prefer that over some weird difference between upgrade/fresh installation

Ok, I’ll do screen grabs from IPMI, as I can’t paste from CLI. Is that OK?

I like text better, but screenshots are still better than nothing

I like text better, but screenshots are still better than nothing

I’m using Hetzner so I can’t think of any way of exporting text from their IPMI without internet access on the host. If you have any ideas please let me know. Right now I’m waiting for them to activate my IPMI.

But then you are in a restricted, hosting provider environment?

I’d suggest trying to set the MAC address on the bridge to the one of it’s physical bridge-ports, as described in the upgrade how-to:
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Check_Linux_Network_Bridge_MAC

Well yes, I am, but the same restrictions apply when using Proxmox 6 without any issues. So the fact that right now 6 works as expected (along with Debian 10, plus Hetzner’s rescue system) proves that there’s nothing wrong with the machine, network and/or settings.

Or am I wrong?

Anyway, I’ll add hwaddress in the config and give it a try.

Last edited: Jul 8, 2021

I’m just curious, how could I get the initial/real MAC address on a fresh 7 install? Because booting a Live OS just to get a MAC address is OK for 1-2 machines, but not for 10+.

Later edit: here’s the current Proxmox 6 config.

Last edited: Jul 8, 2021

Well yes, I am, but the same restrictions apply when using Proxmox 6 without any issues. So the fact that right now 6 works as expected (along with Debian 10, plus Hetzner’s rescue system) proves that there’s nothing wrong with the machine, network and/or settings.

Or am I wrong?

Anyway, I’ll add hwaddress in the config and give it a try.

The MAC-Address policy changed between the systemd used by PVE 6.x and PVE 7.x, see the following upgrade how-to section for details: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Linux_Bridge_MAC-Address_Change

So, in PVE 6.4 your bridge always had the MAC of the (physical) port, which is probably the one that’s allowed from Hetzners firewall rules. With 7.0 it gets another one by default, Hetzners firewall does not recognize that MAC as allowed -> blocked (to avoid MAC spoofing, some dedicated-server hosting prodivers also may use VXLAN/VLAN and could be more relaxed regarding MACs).

Any how, that’s why you need to set it static to the one from the port, at least if you’re in a restricted network (normally everything where the switch config is not under your (companies) control).

FYI: If you setup a Debian 11 Bullseye, or any other modern Distro like a Fedora 33 or Ubuntu 21.04 and setup a bridge then you’ll see the same behavior, this is not directly Proxmox VE specific, but as PVE pretty much always uses Linux bridges that changes is felt more.

The MAC-Address policy changed between the systemd used by PVE 6.x and PVE 7.x, see the following upgrade how-to section for details: https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Linux_Bridge_MAC-Address_Change

So, in PVE 6.4 your bridge always had the MAC of the (physical) port, which is probably the one that’s allowed from Hetzners firewall rules. With 7.0 it gets another one by default, Hetzners firewall does not recognize that MAC as allowed -> blocked (to avoid MAC spoofing, some dedicated-server hosting prodivers also may use VXLAN/VLAN and could be more relaxed regarding MACs).

Any how, that’s why you need to set it static to the one from the port, at least if you’re in a restricted network (normally everything where the switch config is not under your (companies) control).

FYI: If you setup a Debian 11 Bullseye, or any other modern Distro like a Fedora 33 or Ubuntu 21.04 and setup a bridge then you’ll see the same behavior, this is not directly Proxmox VE specific, but as PVE pretty much always uses Linux bridges that changes is felt more.

Thank you for the in-depth explanation! So basically I should get the MAC address of the physical NIC and use it on the bridge as well. Correct?

Great, I’ll mark this as solved and if something comes up when installing I’ll get back to this thread.

Also, if you don’t mind, I’ll make a simple tutorial regarding this, as it seems that there are quite a few users who are not aware of this change.

We tried to convey it quite explicitly in the upgrade how-to, and that how-to is heavily recommend getting read and followed closely before and during upgrade, to avoid as many pitfalls on the way.
But we’ll see if we can further improve this, possibly adding a hint to the pve6to7 checker script.

Источник

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

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

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

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

Внешняя сеть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все изменения сетевой конфигурации требуют перезагрузки узла гипервизора, поэтому, чтобы не перезагружать узел дважды перейдем в консоль сервера и перейдем в директорию /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.

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

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

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

Частная сеть

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

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

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

Организуем службы 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

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

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

service dnsmasq restart

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

Источник

В этой статье я покажу тонкости установки Windows 10 в среде виртуализации от ProxMox. Основное внимание будет уделено Virtio драйверам.

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

Про ProxMox VE я уже писал:

Что такое Proxmox VE?
Установка Proxmox VE 6.3

Для того чтобы создать новую виртуальную машины для Windows 10, заходим в Web-интерфейс управления ProxMox VE и нажимаем кнопку “Create VM“:

ProxMox VE. Создание виртуальной машины. Нажимаем Create VM

Во-первых придумаем имя для виртуальной машины:

ProxMox VE. Придумываем имя для виртуальной машины

Выберем хранилище на котором лежит нужный образ (iso). Затем выбираем сам образ. Меняем тип гостевой ОС и её подтип:

ProxMox VE. Настройка гостевой ОС

Настроим систему, а именно поставим галочку Qemu Agent (дальше нужно будет установить агента в ОС). А для контролера выбирайте VirtIO SCSI, хотя он и так используется по умолчанию:

ProxMox VE. Настройка системы

А потом настроим жёсткий диск для виртуальном машины – я использую SCSI (по умолчанию используется IDE). А также нужно выбрать хранилище для жесткого диска и его размер:

ProxMox VE. Настройка жесткого диска

Настроим процессор для виртуальной машины (укажите количество виртуальных ядер):

ProxMox VE. Настройка жесткого диска

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

ProxMox VE. Настройка RAM

Настроим сетевую карту, я снова использую VirtIO устройство:

ProxMox VE. Настройка сетевой карты

В итоге, после всех настроек, нажмём кнопку “Finish“:

ProxMox VE. Заканчиваем создание виртуальной машины

После того, как мы создали виртуальную машину, добавим ей ещё один привод (CD/DVD Drive). Его будем использовать для того, чтобы подключить ещё один образа с VirtIO драйверами:

ProxMox VE. Создаём дополнительный привод

И подключим в новый привод образ с VirtIO драйверами:

ProxMox VE. Подключаем образ с VirtIO драйверами

Если у вас ещё нет образа с VirtIO драйверами, то вы можете скачать их от сюда.

А также, почитать про VirtIO драйверы можно в wiki от ProxMox – здесь.

Прежде чем двигаться дальше посмотрим ещё раз на виртуальное оборудование нашей виртуальной машины:

ProxMox VE. Виртуальное оборудование для Windows

Установка гостевой ОС

Чтобы запустить виртуальную машину, нажмите кнопку “Start“. Затем, чтобы открыть консоль, нажмите кнопку “Console“:

ProxMox VE. Запуск виртуальной машины

Начнётся процесс установки Windows 10:

Старт установки Windows 10

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

Не виден жесткий диск для установки Windows 10, так как нет Virtio драйверов

Нажимаем кнопку “Загрузить“:

Загрузка драйверов Virtio

На диске с VirtIO драйверами ищем каталог /amd64/w10/:

Поиск драйвера для Virtio SCSI

И устанавливаем найденный драйвер:

Установка драйвера для VirtIO SCSI

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

После загрузки драйвера диск виден

Дальше на найденный диск устанавливаем систему как обычно.

После установки, когда система начнет первоначальную настройку, нажимаем кнопку “У меня нет Интернета“. Это необходимо, так как драйвер VirtIO для сетевого интерфейса мы сможем установить только после первоначальной настройки:

Так как в системе ещё нет драйвера VirtIO для сетевой карты, нажимаем “У меня нет Интернета”

Установка дополнительных VirtIO драйверов

После установки системы, для многих виртуальных устройств не будет найдено драйверов. Чтобы это исправить запускаем “Диспетчер устройств“:

Windows 10. Запуск оснастки “Диспетчер устройств”

Видим неизвестные устройства:

Windows 10. Неизвестные устройства, которым нужны драйвера

Нужно для каждого такого устройства установить драйвер с образа диска для VirtIO драйверов. Для этого нажимаем правой кнопкой мышки по устройству и выбираем “Обновить драйвер“:

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

Затем выбираем пункт меню “Выполнить поиск драйверов на этом компьютере“:

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

Дальше нажимаем кнопку “Обзор“:

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

И указываем диск с VirtIO драйверами:

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

Здесь уже искать драйвера не обязательно, главное указать диск.

Таким образом устанавливаете все остальные драйвера:

Сетевой адаптер

COM порт

Balloon устройство

И в самом конце установим VirtIO Агента с этого же образа диска. Для этого на диске ищем каталог guest-agent а в нем запускаем установщик:

Установщик Qemu Агента

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

настроить сеть;
изменить имя компьютера или ввести систему в домен;
обновить систему;
установить дополнительное ПО;
и другое.

Итог

В этой статье я показал что в среде виртуализации ProxMox используется специальное VirtIO оборудование и для его использования в Windows нужно устанавливать специальные VirtIO драйвера. Дополнительно в систему можно установить агента (Qemu-guest-agent), чтобы гипервизор получал некоторые сведенья о гостевой системе, например ip-адреса.

Ну а в Linux поддержка VirtIO оборудования уже встроена в ядро. Хотя агента всё-таки придется установить, например таким способом:

# apt-get install qemu-guest-agent
Или
#yum install qemu-guest-agent

Спасибо за внимание!

Сводка

Имя статьи

Установка Windows 10 на ProxMox VE 6

Описание

В этой статье я покажу тонкости установки Windows 10 в среде виртуализации от ProxMox. Основное внимание будет уделено Virtio драйверам

Источник

Проходил курсы по гипервизору Proxmox и как всегда не без проблем… Это же я…

В общем столкнулся со следующей ситуацией:

После установки и настройки тестового полигона гипервизора Proxmox на базе VirtualBox внутри Windows 10 — произвел настройку сети и установил парочку контейнеров на базе чистой «Ubuntu 20.10» и «Debian 10 + WordPress». Ну как установил — начал ставить каждый из контейнеров и ни один из них не получал по DHCP положенный ему IP адрес, все остальное прошло без проблем. Ручная настройка IP адреса контейнера также не помогала контейнеру попасть в интернет и установить актуальные обновления дистрибутивов, при этом сам Proxmox заходил в интернет без каких либо вопросов.

Перегуглив тонну форумов и обсуждений в интернете, так и не нашел решения своей проблемы… Хотя однажды я сталкивался с такой проблемой, и ее решением была ручная перенастройка основного сетевого адаптера и бриджа. Что ж, пришло время сознаться в собственном бессилии и написать в общий чат онлайн-школы, чтобы более шаристые ребята смогли мне сказать в чем проблема. Так и сделал… На помощь пришло пару человек вместе с преподавателем. Много было разных советов, предположений, грешных маршрутизаторов и просто кривых рук, как же без них)))

Дабы доказать, что ламер я подготовленный и простой ошибки сделать по инструкции не мог, подключил к своему ПК по удаленке и начал с самого начала, и поэтапно разворачивать Proxmox. Развернув весь стенд заново и установив чистые контейнеры сначала показал, что Proxmox сеть видит, обновляется и спокойной пингует любой ресурс, а вот контейнеры при установке из шаблона видят только IP гипервизора и во внешнюю сеть доступа не имеют, как собственно и к маршрутизатору, который по DHCP должен был выдать IP адрес…

Я почему-то в силу своих слабых знаний Linux подумал на брандмауэр, мне его настройки после Windows как-то не особо понятны, особенно в консоли и зная как он работает под виндой, подумал что это оно… Но мне сказали, что это мало вероятно и не думать на эту тему.

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

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

Последним вопросом стал сам VirtualBox , вдруг там чего не так. Начали смотреть все настройки сетевых адаптеров и вот оно — решение всех моих проблем. Та магия которая пол дня жизни испортила — настройка режима сети в VirtualBox, так называемый «Неразборчивый режим». По умолчанию он стоит в режиме «Запрещено».

Всего их там три режима: «Запрещено», «Разрешить ВМ» и «Разрешить всё»

Мне помог именно тот самый режим «Разрешить всё». Установив его в настройках сети своей ВМ с Proxmox и запустив виртуальную машину — все контейнеры без каких либо проблем смогли по DHCP получить свои IP адреса.

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

5
2
Голосов

Рейтинг записи

О себе:

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

Источник

Перейти к контенту

Случилось так, что приказала долго жить материнская плата с установленным на ней Proxmox 6 версии. Быстро нашелся подменный ПК и ~~хвала аллаху~~ при переносе системных дисков на новое железо все взлетело совершенно самостоятельно …
Кроме сети.

Решение нашлось достаточно быстро.

Стоило быть чуть внимательней и прочитать мануал по настройке сетевых интерфейсов в Debian10.

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

dmesg | grep eth

Запоминаем новое имя интерфейса, в нашем случае enp7s0.

Выключаем интерфейс на время настройки:

ip link set dev enp7s0 down

Далее, корректируем имя интерфейса в файле /etc/network/interfaces:

nano /etc/network/interfaces

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

ip link set dev enp7s0 up

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

Ссылки:

https://antonchirkov.ru/proxmox-change-nic/

Источник

Перейти на CTF площадку Игры Кодебай

Выполняйте задания по кибербезопасности в формате CTF и получайте бесценный опыт. Ознакомиться с подробным описанием можно тут.
B правой части каждого сообщения есть стрелки ⇧ и ⇩. Не стесняйтесь оценивать ответы. Чтобы автору вопроса закрыть свой тикет, надо выбрать лучший ответ. Просто нажмите значок ✔ в правой части сообщения.

Доброго времени суток, есть не большой датацентр из двух узлов (dell r440 и dell r740). После не большого простоя, proxmox на dell r440 перестал видеть сеть, не пингуется как в него так и из него, idrac работает стабильно. Порты менял, шнуры менял. С r740 все в порядке. Версия proxmox 5.4.144-1-pve. Заранее спасибо!

Код:

auto lo
iface lo inet loopback

iface ens2f1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 182.16.10.32
        netmask 255.255.255.0
        gateway 182.16.10.1
        bridge_ports ens2f1
        bridge_stp off
        bridge_fd 0

iface eno1 inet manual

iface eno2 inet manual

iface ens2f0 inet manual

rpviewer.png

2,4 КБ

· Просмотры: 265

можно закрывать, проблема решена

можно закрывать, проблема решена

В чём была проблема?

Источник