oVirt 4.2 постоянный RX drop на сетевом интерфейсе VirtIO (vs e1000)

Ответить
Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 521
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

oVirt 4.2 постоянный RX drop на сетевом интерфейсе VirtIO (vs e1000)

Сообщение Алексей Максимов » 09 июн 2018 17:44

Всем доброго времени года.

Прошу "поддержки с воздуха" у нашего эксперта по oVirt. :geek:
Колупался с мониторингом виртуальных машин c Debian 8/9 на базе oVirt 4.2.3.7-1.el7 и обнаружил одну интересную вещь.
На некоторых машинах (не на всех) с Debian 8 фиксируются постоянные дропы входящих пакетов.
Где-то сотни дропов (на менее нагруженных ВМ), где-то даже до пары тысяч доходит (на более нагруженных ВМ).
В попытках понять, откуда "растут ноги" у этих дропов прикрутил на одной из мало-нагруженных машин dropwatch

И вот какие дропы засветились

Код: Выделить всё

# ./dropwatch -l kas

Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
2 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at __netif_receive_skb_core+63c (0xffffffff8142f2dc)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at __netif_receive_skb_core+63c (0xffffffff8142f2dc)
1 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at __netif_receive_skb_core+63c (0xffffffff8142f2dc)
2 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
2 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at __netif_receive_skb_core+63c (0xffffffff8142f2dc)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at __netif_receive_skb_core+63c (0xffffffff8142f2dc)
1 drops at nf_hook_slow+108 (0xffffffff8145f438)
3 drops at ip_rcv_finish+16b (0xffffffff8146591b)
1 drops at nf_hook_slow+108 (0xffffffff8145f438)
1 drops at __netif_receive_skb_core+63c (0xffffffff8142f2dc)
^CGot a stop message
dropwatch> stop
Deactivation requested, turning off monitoring
Waiting for deactivation ack...
Got a stop message
dropwatch> exit
Shutting down ...
Если я правильно понимаю, то вещи типа nf_hook_slow и netif_receive_skb это какие-то функции ядра Linux, и это для меня уже - из разряда тяжёлого кунг-фу :(

Однако, интересно в этой ситуации то, что такое поведение у сетевого адаптера гостевой ОС наблюдается только, если в свойствах ВМ выбран тип адаптера VirtIO. Поменяв тип на e1000, я обнаружил, что дропы прекратились полностью.
VirtIO-vs-e1000.png
VirtIO-vs-e1000.png (82.3 КБ) 218 просмотров
Вот так информацию показывает ethtool при использовании разных типов адаптера, и соответственно, драйвера

Код: Выделить всё

# ethtool -i eth0
driver: e1000
version: 7.3.21-k8-NAPI
firmware-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

# ethtool -i eth0
driver: virtio_net
version: 1.0.0
firmware-version:
bus-info: 0000:00:03.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
Интересны любые мысли по поводу приведённого листинга дропов, а также наблюдения и замечания по поводу сравнения VirtIO vs e1000 vs etc...

Аватара пользователя
Dan Yasny
Дорогой гость
Сообщения: 83
Зарегистрирован: 07 окт 2016 14:17
Контактная информация:

Re: oVirt 4.2 постоянный RX drop на сетевом интерфейсе VirtIO (vs e1000)

Сообщение Dan Yasny » 09 июн 2018 19:34

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

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

Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 521
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: oVirt 4.2 постоянный RX drop на сетевом интерфейсе VirtIO (vs e1000)

Сообщение Алексей Максимов » 10 июн 2018 05:55

На хосте дропов не видно. На машинах с CentOS 6/7 тоже нет и там везде VirtIO. Однако странно то, что на некоторых машинах Debian 8 также нет дропов, хотя они имеют одинаковые настройки системы и даже могут быть расположены на одном хосте в подобной виртуалкой где дропы фиксируются.

Аватара пользователя
Dan Yasny
Дорогой гость
Сообщения: 83
Зарегистрирован: 07 окт 2016 14:17
Контактная информация:

Re: oVirt 4.2 постоянный RX drop на сетевом интерфейсе VirtIO (vs e1000)

Сообщение Dan Yasny » 10 июн 2018 18:41

Когда я такое видел, был какой то мелкий баг в ringbuffer драйвера. То что такой проблемы нет, показывает разницу между центосом и дебианом - в центосе ядро тестируется, а в дебиане собралось - и ладно.

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

Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 521
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: oVirt 4.2 постоянный RX drop на сетевом интерфейсе VirtIO (vs e1000)

Сообщение Алексей Максимов » 10 июн 2018 19:21

По поводу e1000 понял, буду иметь в виду. Спасибо за информацию. Нашёл тут у себя ещё пару вещей которые, как я понимаю, потенциально могут быть причиной таких дропов. На одном их хостов кластера интерфейсы бонда и сам бонд по какой-то причине откатились к старым настройкам хоста и был установлен MTU 9000 вместо 1500 (как на всех других хостах в кластере). Это уже исправил (провёл с веб-морды Sync Networks). К тому же для виртуалок с дропами была найдена общая черта - все они в дефотлном нетегированном 1 VLAN-е. Все прочие виртуалки, не имеющие подобной штуки с дропами - в выделенных изолированных VLAN-ах. Попробую перетащить эти машины в виртуальную сеть, трафик которой завёрнут явно в VLAN, посмотрим как поменяется ситуация.

Ответить

Вернуться в «oVirt»