Вариантов тут 2:

• Перекачать / переустановить OVA образ.
• Загрузить новую лицензию.

(насчет варианта №2 пока не могу дать более точную информацию, нужно уточнять)

Да, судя по выводу лицензия более не действительна.

Кроме как из-за изменений времени на ВМ, это не могло произойти. (по крайней мене на моей памяти ничего иного не было)

Я спросил ещё у коллег, возможно кто-то знает иные причины. Попрошу их здесь отписаться.

(полагаю разница между временем на стенде и временем отправки сообщения вызвана копированием и т.п.)

Попробуйте выполнить /opt/ptisim/bin/license-checker. Что возвращает в консоль команда?

Здравствуйте!

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

Можете проверить текущее время на сервере? И сравнить его с текущим временем в целом?

(на сервере должно быть текущее время, и выставлен часовой пояс UTC)

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

У меня будет ещё одна просьба.

Состояние DPI на момент падения должно было сохраниться в файл "/opt/ptsecurity/dpi/core".

Если вас не затруднит, не могли бы вы его предоставить?

Единственная проблема - он весит около 1 Гб и я не уверен, что данный форум позволит его загрузить. Возможно тут придётся воспользоваться каким-либо облаком.

Посмотрел cpuinfo.

Судя по всему (предположение) для процесса не настроены/запущены/скомпилированы AVX инструкции. В этом случае DPI должен ругаться на несовместимость с процессором. Но он этого не делает. И на это у нас есть баг. 

Более детально скажу чуть позже, после уточнения информации. 

Скажите пожалуйста:

ВМ корректно была импортирована на ESXi (? я так и не понял какой гипервизор используется...)

1. Я больше хотел узнать про разрядность ОС, которая была задана при разворачивании ВМ. Не могло ли там быть задано - "Импортировать образ, как х32?"
2. Ещё не отказался бы от модели процессора. Но тут полагаю какой-то Intel Xeon стоит...

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

Здравствуйте! Если не затруднит, то приложите ещё системные логи (/var/log/syslog*). По неизвестной мне причине, они не были собраны граббером.