Супер. Кто-то ещё помнит как писать под проц. 8086. В принципе здорово, только непонятно для чего. Какова цель статьи и проделанной работы. Чтобы из нормальной консоли получить самодельную в эмуляторе?
Наверное да. Я подумаю об этом.
Тем не менее, недавний случай с ошибкой в ядре, которая прилетела с патчем в 2.6.32-754.6.3 (была починена в следующем) напоминает о том, что с обновлениями надо быть осторожным.
Как минимум не стоит делать обновления автоматически и для всей инфраструктуры сразу.
Ещё хочу заметить, что идея kABI совместимых модулей не очень соответствует идеям ядра Linux.
Dkms модуль ядра практически не вызывает проблем. Конечно он может не собраться из-за специфичного патча или из-за очередного обновления ядра. Но серваки пачками не кладёт. Если есть возможность использовать dkms модуль, я бы советовал использовать именно его.
Конечно согласен, что изменений между версиями 7.5 и 7.6 было мало. Более того, модуль, собранный под 7.5 оказался совместим с 7.6. Кажется, что проблем нет.
Однако хочу напомнить, может кто не в курсе, у нас была колоссальная проблема при релизе 7.5, когда модуль, собранный для ядра 7.0 был kABI совместим с обновлённым, успешно загружался и гарантированно ронял серваки. Обычно пользователи не любят, когда их серваки падают.
В результате, было принято решение не пытаться работать на ядрах будущих релизов EL7, которые не прошли через наш QA.
Кроме того, шли работы по подготовке к релизу VBR 9.5, VAL 3.0 и VAW 3.0. Выделить ресурсы на hot fix для поддержки rhel 7.6 — а это несколько дней регресса — было сложно.
Да, согласен, что возможно мы недостаточно уделили внимание релизу 7.6. Выводы из этой ситуации мы сделали.
Но для нас всё же приоритетом является надёжность работы серверов наших пользователей.
Спасибо автору за лаконичный обзор LSM.
Сильно расстраивает «Небольшое печальное отступление».
А так хотелось перехватывать появление блочных устройств и монтирование файловых систем на них из модуля.
Самое простое — написать на форум для начала.
Саппорт — тоже хороший вариант.
И не забудьте собрать логи!
veeamconfig config grabLogs
Далее.
при каждом запуске перечитываются все машинки целиком
Создаётся впечатление, что производится бэкап самого гипервизора — это плохая идея.
Для нормального согласованного бэкапа ставить агента надо на гостевые системы. На то он и агент. Для гипервизоров есть другой продукт.
CBT не сможет помочь в случае использования File Backup. Для File Backup модуль ядра обеспечивает только создание снапшота. Делать надо Volume Backup.
Наверное да. Я подумаю об этом.
Тем не менее, недавний случай с ошибкой в ядре, которая прилетела с патчем в 2.6.32-754.6.3 (была починена в следующем) напоминает о том, что с обновлениями надо быть осторожным.
Как минимум не стоит делать обновления автоматически и для всей инфраструктуры сразу.
Ещё хочу заметить, что идея kABI совместимых модулей не очень соответствует идеям ядра Linux.
Dkms модуль ядра практически не вызывает проблем. Конечно он может не собраться из-за специфичного патча или из-за очередного обновления ядра. Но серваки пачками не кладёт. Если есть возможность использовать dkms модуль, я бы советовал использовать именно его.
Однако хочу напомнить, может кто не в курсе, у нас была колоссальная проблема при релизе 7.5, когда модуль, собранный для ядра 7.0 был kABI совместим с обновлённым, успешно загружался и гарантированно ронял серваки. Обычно пользователи не любят, когда их серваки падают.
В результате, было принято решение не пытаться работать на ядрах будущих релизов EL7, которые не прошли через наш QA.
Кроме того, шли работы по подготовке к релизу VBR 9.5, VAL 3.0 и VAW 3.0. Выделить ресурсы на hot fix для поддержки rhel 7.6 — а это несколько дней регресса — было сложно.
Да, согласен, что возможно мы недостаточно уделили внимание релизу 7.6. Выводы из этой ситуации мы сделали.
Но для нас всё же приоритетом является надёжность работы серверов наших пользователей.
Сильно расстраивает «Небольшое печальное отступление».
А так хотелось перехватывать появление блочных устройств и монтирование файловых систем на них из модуля.
Саппорт — тоже хороший вариант.
И не забудьте собрать логи!
Далее. Создаётся впечатление, что производится бэкап самого гипервизора — это плохая идея.
Для нормального согласованного бэкапа ставить агента надо на гостевые системы. На то он и агент. Для гипервизоров есть другой продукт.
CBT не сможет помочь в случае использования File Backup. Для File Backup модуль ядра обеспечивает только создание снапшота. Делать надо Volume Backup.