Комментарии 6
По хорошему можно было бы реализовать идею так же, как когда то реализовали первую систему контроля версий — как нечто принципиально новое, а не сцепленные отдельные части, изначально предназначенные для других целей. С другой стороны — это можно сделать позже, а сейчас отработать и огородить вешками самые скользкие и болотистые места.
А как у вас реализован «VM linked clone»? Через стандартный функционал ESXi 6 или чем-то вроде clone.sh?
Как-то побеждали перезагрузки\обработку bsod на vm или jenkins из коробки может это?
Тоесть я вот эту фразу никак не пойму: Код фреймворка выполняется на Gate VM — контрольной машине, а System Under Test (в нашем случае kernel driver) разворачивается на Test VM.
на GateVM удаленный дебаггер подключен и вы им бсод ловите из TestVM?
на GateVM удаленный дебаггер подключен и вы им бсод ловите из TestVM?
Каждая тестовая OS настроена на сбор полного дампа в случае BSOD, с автоматической перезагрузкой после сбора.
Таким образом, после ребута достаточно проверить, нет ли дампа в установленном месте.
Согласно https://www.vmware.com/pdf/vsphere6/r60/vsphere-60-configuration-maximums.pdf, можно на Gate VM настроить до 32х параллельных портов, и по named pipe подключить дебаг сессии к каждой Test VM. В этом случае, однако, тест идет заметно дольше — на каждом ребуте Guest OS теряется до 5 минут, так что от такой схемы мы отказались.
Таким образом, после ребута достаточно проверить, нет ли дампа в установленном месте.
Согласно https://www.vmware.com/pdf/vsphere6/r60/vsphere-60-configuration-maximums.pdf, можно на Gate VM настроить до 32х параллельных портов, и по named pipe подключить дебаг сессии к каждой Test VM. В этом случае, однако, тест идет заметно дольше — на каждом ребуте Guest OS теряется до 5 минут, так что от такой схемы мы отказались.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация тестирования: «беспилотник» Acronis Kernel