Я использую гостевой экземпляр Windows Server 2003 в Xen 3.x. Этот DomU работает нормально в течение дня или двух, затем перестает отвечать - я не получаю никакого ответа от сети, и я больше не могу подключиться к консоли Xen VNC для этого DomU.
xm list показывает это:
Name ID Mem VCPUs State Time(s)
Domain-0 0 6508 8 r----- 1161159.4
[A working Linux DomU] 1 512 1 -b---- 68711.1
[The hung Windows DomU] 5 512 1 ------ 67234.2
[Another working Linux DomU] 3 512 1 -b---- 163036.4
(Что это ------ значит? В xm руководство объясняет, что означает каждое из шести состояний, но не то, что означает отсутствие состояния.)
Если я xm destroy а потом xm create снова Windows DomU, он загружается сразу после загрузки (с предупреждением Windows The previous system shutdown at [...] was unexpected.), а затем перестает отвечать через день или два. Помимо этого предупреждения, в журнале событий Windows нет ничего важного. Кроме того, я использую Munin для мониторинга диска, сети, количества процессов, использования ЦП и памяти; графики Мунина не указывают на исчерпание ресурсов или другую подозрительную активность до зависания.
Я проверил /var/log/xen/*.log, но в то время, когда сервер перестает отвечать, сообщения журнала не создаются.
Как мне продолжить устранение неполадок?
В ------ означает, что он в состоянии «ничего». Например, он не работает, заблокирован, приостановлен, завершен, аварийно завершен или умирает. Итак, «работает, но не работает», как если бы он находился в очереди выполнения, но не в начале ее.
Что касается устранения неполадок, что вы пробовали до сих пор и какие инструменты или скрипты для мониторинга производительности Xen используете? Довольно сложно подсказать, куда идти, если мы не знаем, где ты был. Если вы еще этого не сделали, я бы определенно начал с ведения журнала и мониторинга производительности, чтобы увидеть, можете ли вы соотнести начало вашего рабочего состояния с какими-либо индикаторами.
Также, возможно, стоит взглянуть на журналы событий Windows или выполнить регистрацию производительности внутри Windows - я сомневаюсь, что они скажут что-нибудь примечательное, но может случиться так, что что-то внутри гостевой ОС вызывает такое поведение, и если да, вам нужно посмотреть на гостевую ОС, чтобы выяснить, что.