Network uplink redundancy lost vmware как исправить
Обновлено: 07.07.2024
Если вы пытаетесь подключить вашу виртуальную машину к компьютеру локальной сети, но она не работает или Мостовая сеть не работает в VMware , вот несколько решений, которые можно использовать для решения этой проблемы. , Это очень распространенный сценарий среди новых пользователей VMware. Даже если вы уже давно используете VMware и внезапно перестали работать мостовые сети, вы также можете попробовать эти решения.
Есть много людей, которым часто нужно подключить свою виртуальную машину к компьютеру локальной сети для обмена файлами. Это очень легко сделать с вашей хост-машиной. Проблема начинается, когда вы пытаетесь сделать то же самое с гостевой операционной системой в VMware. Это происходит из-за сетевого адаптера без общего доступа, который отвечает за создание соединения между компьютером локальной сети и вашей виртуальной машиной.
Мостовая сеть VMware не работает
Эти следующие способы помогут вам решить проблему мостовой сети в VMware-
- Выберите правильное сетевое соединение
- Перезапустите VMware Bridge Control
- Выберите конкретную виртуальную сеть
- Выберите правильное мостовое сетевое соединение
- Восстановить все настройки по умолчанию
- Отключите ненужные сети на главном компьютере
- Отключите брандмауэр/VPN-приложения от хост-компьютера.
1] Выберите подключение к сети .
По умолчанию VMware использует параметр NAT Used для совместного использования IP-адреса хоста , чтобы виртуальная машина могла использовать IP-адрес хост-компьютера при создании сетевого подключения. Это может создать проблемы из-за конфликта IP.
Поэтому вы можете выбрать выделенную опцию, которая позволит вам легко установить мостовое соединение. Если вы выберете эту опцию, она позволит вам копировать состояние соединения хост-машины. Другими словами, вы получите больше гибкости.
Чтобы использовать этот параметр, выберите виртуальную машину и выберите параметр Изменить настройки виртуальной машины . После этого выберите Сетевой адаптер на вкладке Оборудование . С правой стороны вы должны получить опцию с именем Мост: подключен напрямую к физической сети .
Выберите его и нажмите кнопку ОК, чтобы сохранить изменения.
2] Перезапустите VMware Bridge Control .
Иногда простой перезапуск устраняет основные проблемы. Вы можете использовать ту же технику, чтобы решить эту проблему. Это очень легко перезапустить VMware Bridge Control с помощью командной строки. Если в VMware есть какие-то внутренние проблемы, это можно решить, выполнив это. Чтобы перезапустить VMware Bridge Control, откройте командную строку с правами администратора и введите эти команды одну за другой.
3] Выберите конкретную виртуальную сеть
Если вы выберете опцию Bridged, NAT или Host-only, есть вероятность, что VMware может использовать неверную виртуальную сеть. Хотя это очень редко, это может случиться с вами. Таким образом, это довольно хороший вариант для вас, чтобы выбрать конкретную виртуальную сеть вручную, чтобы каждая лазейка могла быть заблокирована.
Для этого выберите виртуальную машину и нажмите Изменить настройки виртуальной машины . После этого перейдите к параметру Сетевой адаптер . С правой стороны вы должны выбрать опцию Пользовательская: Конкретная виртуальная сеть в разделе Сетевое подключение .
Отсюда вам нужно выбрать VMnet0 и сохранить настройки.
4] Выберите правильное мостовое сетевое подключение
После этого вы должны найти VMnet0 в списке. Убедитесь, что это выбрано. После этого выберите Bridged в разделе Информация о VMnet и выберите сетевой адаптер хост-компьютера в раскрывающемся меню.
Теперь нажмите кнопку ОК, чтобы сохранить изменения.
Вот некоторые из рабочих решений этой проблемы. Однако, если у вас все еще возникает та же проблема, вы также можете следовать этим инструкциям.
5] Восстановите все настройки по умолчанию
Если вы внесли много изменений и сеть Bridged перестала работать после этого, вы всегда можете использовать опцию сброса, которая сделает все как новое. Чтобы использовать этот параметр, откройте редактор виртуальной сети и нажмите кнопку Изменить настройки , чтобы внести изменения в этом окне. После этого вы можете найти параметр Восстановить значения по умолчанию , который вам нужно использовать.
6] Отключите ненужные сети на главном компьютере
Здесь вы можете найти все сетевые подключения. Нажмите правой кнопкой мыши каждое соединение и выберите Отключить . Не отключайте подключенное в настоящий момент сетевое соединение и все сети с именем Сетевой адаптер VMware .
7] Отключите приложения брандмауэра/VPN на главном компьютере
Хотя это не должно происходить, иногда VPN может также вызвать эту проблему. Если вы недавно установили приложение VPN или брандмауэр на своем хосте или виртуальной машине, рекомендуется временно отключить его и проверить, сохраняется ли проблема.
В этой статье можно решить проблему, из-за которой виртуальные машины теряют сетевое подключение при использовании сетевых адаптеров Broadcom NetXtreme 1 гигабит.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2986895
Симптомы
Если вы Hyper-V в Microsoft Windows Server 2012 или Windows Server 2012 R2 вместе с сетевыми адаптерами Broadcom NetXtreme 1-гигабитных (но не сетевыми адаптерами NetXtreme II), вы можете заметить один или несколько следующих симптомов:
Виртуальные машины могут случайно потерять сетевое подключение. Сетевой адаптер, кажется, работает в виртуальной машине. Однако вы не можете получить доступ к сетевым ресурсам с виртуальной машины. Перезапуск виртуальной машины не решает проблему.
Невозможно тикинг или подключение к виртуальной машине с удаленного компьютера. Эти симптомы могут возникать на некоторых или всех виртуальных машинах на сервере, который работает Hyper-V. Перезапуск сервера сразу же устраняет подключение к сети для всех виртуальных машин.
Причина
Это известная проблема с сетевыми адаптерами Broadcom NetXtreme 1-gigabit, которые используют b57nd60a.sys драйвера. Эта проблема возникает, когда в сетевом адаптере включена очередь виртуальных машин (VMQ). (По умолчанию VMQ включен драйвером сети Broadcom.)
Broadcom называет эти сетевые адаптеры микросхемами на основе 57xx. Они включают 5714, 5715, 5717, 5718, 5719, 5720, 5721, 5722, 5723 и 5780.
Эти сетевые адаптеры также продаются под разными номерами моделей некоторыми серверами OEMs. HP продает эти драйверы под номерами модели NC1xx, NC3xx и NC7xx. Вы можете использовать драйвер версии 16.2, 16.4 или 16.6 в зависимости от используемой версии OEM или версии драйвера Broadcom.
Решение
Эта проблема устранена в драйвере Broadcom b57nd60a.sys версии 16.8 и более новой. В марте 2015 г. Broadcom опубликовал драйвер версии 17.0 для скачивания. В апреле 2015 г. HP опубликовала версию 16.8 драйвера для затронутых сетевых адаптеров. Обратитесь к OEM-серверу, если вам нужен драйвер, специфический для сервера.
Если вы не можете обновить драйвер сетевого адаптера для решения проблемы, вы можете устранить проблему, отключив VMQ для каждого затронутного сетевого адаптера Broadcom с помощью команды Set-NetAdapterVmq PowerShell.
Рассмотрим следующий сценарий.
- У вас есть сетевой адаптер с двойным портом.
- Порты именуются NIC 1 и NIC 2 в Windows.
В этом сценарии можно отключить VMQ на каждом адаптере с помощью следующих команд:
Вы можете подтвердить отключение VMQ в правильных сетевых адаптерах с помощью команды Get-NetAdapterVmq PowerShell.
По умолчанию VMQ отключен на Hyper-V для виртуальных машин, использующих сетевые адаптеры с 1 гигабитом. VMQ включен на Hyper-V, только если система использует 10-гигабитные или более быстрые сетевые адаптеры. Это означает, что отключение VMQ в сетевом адаптере Broadcom не будет терять производительность сети или какие-либо другие преимущества, так как это по умолчанию. Однако для решения проблемы драйвера необходимо сделать это.
Get-NetAdapterVmqQueue показывает очереди виртуальных машин (VMQ), выделенные в сетевых адаптерах. Вы не увидите VMQ, которые по умолчанию выделены сетевым адаптерам на 1 гигабит.
Всем привет! В прошлый раз мы с вами разобрали, как выбирать себе драйвера интеграции и в частности для сетевого интерфейса, отталкиваясь от его типа, думаю, что благодаря этому вы смогли хорошо увеличить производительность своего виртуализованного парка и снизив нагрузку на физические гипервизоры. Сегодня в статье ошибка "This host currently has no management network redundancy в ESXI 5.1". При подключение хосту к VMware High Availability (HA) или при включение HA на существующем кластере может возникнуть предупреждение: “This host currently has no management network redundancy”
This host currently has no management network redundancy-01
Связано это с тем, что не выполняется требование VMware относительно HA, а именно подключение сервисной консоли или VMware Kernel к двум физическим интерфейсам. Я, как собственно и VMware, советую подключить второй физический интерфейс, это увеличит отказоустойчивость кластера. Но, если такой возможности нет, то данное предупреждение можно попросту отключить.
1. Редактируем настройки HA кластера: В окне vSphere HA (VMware HA) кликаем Advanced Options…
Создаем опцию das .ignoreRedundantNetWarning со значением true
This host currently has no management network redundancy-03
Выбираем хост с этим предупреждением и делаем Reconfigure for vSphere HA, тем самым переустановив агент НА.
Ошибка This host currently has no management network redundancy в ESXI 5.1
- VMware Technology Network
- :
- Global
- :
- Russian
- :
- Russian Discussions
- :
- Вопрос по network redundancy+потеря сети ВМ в неко.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Недавно настроил сетевую подсистему vsphere 5 на блейдах следующим образом:
Два блейдовых сетевых свитча, от них два гигабитных аплинка в магистральную Cisco 3750. Менеджмент корзины HP подключен в блейд свитч1. У хостов по 4е сетевых карты. vmnic0,1 смотрят с блейд свитч 1, vmnic2,3 смотрят в блейд свитч2. Создан один vds. В нем следующие порт группы -
1. Mgmt, vlanX, vmnic2,0 active, vmnic1,3 unused, route based on physical nic load
2. Mgmt redundancy, vlanX, vmnic 1,3 active, vmnic0,2 unused, route based on physical nic load
3. VM LAN1, vlanX, vmnic1,2,3 active, vmnic0 unused, route based on physical nic load
4. VM LAN2, vlanY, vmnic1,2,3 active, vmnic0 unused, route based on physical nic load
+ 2е портгруппы для vmotion+еще пара для VM.
Как-то тут на днях упал аплинк из блейд свитча 1 в магистральную Cisco. Упал из-за чьих-то рук, которые ковярялись в шкафу и видимо как-то нарушили контакт. Корзина не доступна, на iLo не попасть, на блейдсвитчи не зайти (т.к. это все подключено через свитч1). Магистральный свитч видит линк как живой и поднятый. Но траффика нет. Переткнули линк - все ожило.
vCenter при этом был доступен. ESX хост на котором был vCenter тоже был доступен и виртуалки с этого хоста прекрасно работали. Другой же хост ESX в кластере был как disconected. С vcenter не пинговался, виртуальные машинки, сидящие на нем тоже не пинговались. Вопрос - почему?)))) я предполагал, что вышеописанные настройки должны давать возможноть при падении одного свитча, добраться до хостов ESX через другой свитч. Что не так в настройках?
Проблема заключается в следующем: периодически отваливается сеть. Лечится перезагрузкой.
Когда это произошло в первый раз, я сразу поехал в офис, подключил монитор, клаву - на экране картинка есть, пункты меню доступны. Тоесть хост не повис, но по сети не доступны ни хост ни гостевые ОС.
В логах после ничего не нашел (пересмотрел, вроде все).
Первый раз это произошло примерно через месяц после запуска, последнее время чаще: раз в 1-2 недели. Причем, происходит это на выходных. Сообщают мне об этом в ПН утром, либо в СБ, ВСК, если кто-то вышел поработать на выходных. Как эту закономерность сопоставить с проблемой пока не вижу.
Что сделано:
Поменял в bios настройки в соответствии с рекомендацией arruah вот тут
Пункта IOMMU я у себя не нашел. В соответствии с тем, ч то указано тут включил параметр ASPM.
Но ничего не изменилось.
Есть вариант воткнуть в сервер дискретную сетевую от Intel (на старом сервере (обычный десктоп) с этой карточкой все работало около года, но, правда там был ESXI 5).
Но ящик пока на гарантии, его вскрытие как бы и не запрещено, но не желательно, он опломбирован.
- Вопрос задан более двух лет назад
- 2193 просмотра
Средний 2 комментария
Попробуйте на уровне свитчей посмотреть если таковые есть. Через что вы выходите во внешнюю сеть? В моём случае у провайдера "подгоняли" свитчи.
Спасибо что откликнулись.
На одной из виртуалок на этом же хосте керио - через него и ходим.
А что именно у провайдера делалось?
Но сеть отваливается и на хосте ESXi тоже, не только на гостевых ОС. Могли повлиять драйвера в гостевой винде на это?
А как можно проверить версию драйвера, которую юзает VMware? И как скормить ей другой?
В дистрибутив VMware добавлять доводилось драйверы, а вот работающему хосту подсовывать новые нет. Почему решили что сеть отваливается?
В сервере две сетевых карты, подключены обе? в какое оборудование?
Одна в локалку, вторая в инет. Из локалки не доступен сервер, из инета тоже (ВНП отваливается).
Но если подключить моник, то там все норм - можно смотреть логи, базовые настройки выполнять.
Из этого вывод, что именно сеть отваливается.
Спасибо за ссылку, очень информативно, не видел этой таблицы.
Да в общем-то устраивала 5,5 .
Просто ставил актуальную на момент переезда версию. Не проверил достаточно внимательно момент совместимости, тут точно мой косяк.
А как максимально безболезненно организовать даунгрейд, это видимо самое верное решение?
Сейчас сам ESXi стоит на SSD, там же 1 из виртуалок. Остальные на HDD.
Вижу пару вариантов:
1. Перебросить виртуалку на HDD переустановить на SSD ESXi 5.5, добавить в ESXi 5.5 все старые виртуалки.
2. Установить ESXi на отдельный носитель, например на флешку (слышал что так делают, но в чем преимущество такого решения не понял. В моём же случае - это полезно из соображений безопасного переезда)
3. Как-то даунгрейдить текущий ESXi без переустановки. Погуглив немного, пришел к тому, что так не получится, только если ранее был апгрейд и тогда можно откатиться.
Как Вам удалось решить проблему?
Имеем хост ESXI 6.7 всё работало без сбоев примерно год, потом так же отваливается сеть на хосте, причем все адаптеры разом, не важно в каких они VLAN или в какие коммутаторы воткнуты.
Так же заметил закономерность, если мимо (не черпез витруалки или хост) идёт трафик по сети( качаешь примерно 10гб 1 файл), то сеть на ESXI падает, помогает только перезагрузка хоста, либо выдернуть\вставить сетевой провод в сетевухи. Проблему не решили? у меня примерно такая же история только на 6.5. Просто пропадает связь на всех интерфейсах лечится только ребутом. Есть возможность повешать management network на отдельный интерфейс? чтоб на этом физическом интерфейсе не было каких-то портгрупп или свитчей не относящихся к менеджмент нетворк?
Методом тыка у себя я определил, что виновата именно одна из виртуальных машин подключенных к общему свитчу виртуалок. Когда начинаешь на ней утилизировать канал, физический интерфейс на хосте падает, отсюда недоступны все виртуалки. Повешал управление хостом на отдельный интерфейс, и после падения сети зашел в управление. Так вот, оттуда я даже через консоль виртуальной машины не мог ничего сделать в виртуалке, тупо намертво висит пока не передернешь витую пару у сетевухи на хосте.
В логах естественно тишина.
Добрый день!
У нас все было сложно с этим вопросом, и по сути, он еще до конца не решен.
- Проблема именно на серваках Supermicro при работе с ESXi проявляется, ниже ссылки дам, которыми он поделился
- Сама по себе проблема с Sata контроллером на плате Supermicro, и вероятно, её можно решить установкой дискретного Sata/Raid контроллера
- Вроде как еще оно должно лечиться применением каких-то настроек BIOS (что-то похожее и я находил, не факт что те же настройки менять пробовал)
- В итоге после изменения настроек (по ссылкам ниже должно быть описание их), с его слов сервер проработал более 3х недель без сбоев
- На данный момент сервер тестируется у нас, в работу пока не возвращали
К слову, на подменном DELL PowerEdge R710LFF вся наша система вертится без сбоев все это время (уже несколько месяцев).
Читайте также: