Периодический сбой виртуальной машины Debian

В настоящее время я запускаю экземпляр виртуальной машины Debian 8.6 в среде Hyper-V. Виртуальная машина используется для ряда задач cron, которые копируют файлы с одной подключенной машины на наш NAS, а также запускают некоторые контрольные суммы md5 для этих скопированных файлов.

Проблема, с которой я сталкиваюсь, заключается в том, что раз в пару недель файловая система повреждается, и поэтому мои cronjobs перестают выполняться. Если я попытаюсь отредактировать crontab через crontab -e, я получу следующую ошибку:

/tmp/crontab.Vvp59T: Input/output error
Creation of temporary crontab file failed - aborting

Я также заметил, что некоторые команды не распознаются:

root@srv-schl-008:/home/ilienert# dmesg | lpr
bash: lpr: command not found

Затем я попытался запустить проверку файловой системы, но ничего не получилось. Вот лог того, что я сделал:

root@srv-schl-008:/home/ilienert# parted /dev/sda 'print'
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 53.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   51.5GB  51.0GB  ext4
 3      51.5GB  53.7GB  2145MB  linux-swap(v1)
root@srv-schl-008:/home/ilienert# fsck /dev/sda2
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/sda2: recovering journal
fsck.ext4: Bad magic number in super-block while trying to re-open /dev/sda2
/dev/sda2: ********** WARNING: Filesystem still has errors **********
root@srv-schl-008:/home/ilienert# echo $? # status of last command
12

Наконец, когда мы перезагружаем виртуальную машину, мы видим всплеск. И в этот момент мы вынуждены восстановить виртуальную машину из более раннего состояния, после чего она нормально работает еще пару недель, прежде чем снова произойдет сбой. Есть идеи, почему это продолжается?

Вот характеристики нашей среды:

Версия Debian: 8.6.0
Hyper-V работает на двух кластерных серверах с Windows Server 2016 Datacenter
Характеристики оборудования Хосты Hyper-V: 2x E5-2650v2, 8 ядер, 256 ГБ ОЗУ DDR3
Решение для резервного копирования: Veeam Backup & Replication 9.5
Характеристики ВМ:
Кластеризация: да
Поколение: 2
Динамическая память: 16834 МБ
Количество виртуальных процессоров: 4
Тип жесткого диска: VHDX

РЕДАКТИРОВАТЬ: Вот снимок экрана, который я выкопал в предыдущий раз, когда мне удалось выполнить dmesg сразу после сбоя: dmesg output


hyper-v debian debian-jessie hypervisor
person BGSGunterGlut    schedule 02.05.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Трудно сказать, что идет не так (со временем что-то ломается) только по информации, которую вы разместили. Боюсь, вам придется провести дополнительное расследование. Вот две вещи, которые приходят на ум:

1) Мы не можем исключить вероятность того, что ваш физический жесткий диск, на котором размещена виртуальная машина, начинает выходить из строя. Я бы рекомендовал проверить диск самостоятельно (не через виртуальную машину), если это возможно.

2) После восстановления компьютера ежедневно следите за основными системными журналами, они могут содержать сообщения (об ошибках), которые могут помочь объяснить, что происходит с машиной. Обычно я запускаю некоторые команды bash для проверки основных журналов и добавления результатов в файл, например этот (у вас может не быть всех этих журналов на вашем компьютере, для некоторых могут потребоваться установленные пакеты, которых у вас нет, не стесняйтесь адаптироваться к собственное использование):

echo '---------Dmesg-----------' >> /var/log/mylog.txt
dmesg --level=emerg,alert,crit,err >> /var/log/mylog.txt 2>&1
echo '---------systemctl-----------' >> /var/log/mylog.txt
systemctl --state=failed --all -q >> /var/log/mylog.txt 2>&1
echo '---------grep Xorg.0.log-----------' >> /var/log/mylog.txt
grep -wi 'error\|fail\|fault\|corruption\|hung\|lockup\|unkown\|segmentation\|critical\|missing\|(EE)' /var/log/Xorg.0.log >> /var/log/mylog.txt 2>&1
echo '---------journalctl - the last report-----------' >> /var/log/mylog.txt
journalctl -q --boot -0 --priority=3 >> /var/log/mylog.txt 2>&1
echo '---------grep var/log/boot.log -----------------' >> /var/log/mylog.txt
grep -wi 'error\|fail\|fault\|corruption\|hung\|lockup\|unkown\|segmentation\|critical\|missing' /var/log/boot.log >> /var/log/mylog.txt 2>&1
echo '---------end of mylog reports-----------' >> /var/log/mylog.txt

Я бы также рекомендовал перезагружать машину каждый день, пока не найдете проблему.

Надеюсь, это поможет!

person Jamil Said    schedule 02.05.2017
comment
Большое спасибо. Пожалуйста, смотрите мое редактирование, которое содержит более важную информацию. - person BGSGunterGlut; 03.05.2017
comment
Я бы по-прежнему рекомендовал то же самое с некоторыми дополнительными предложениями: попробуйте восстановить машину и запустить fsck сразу после восстановления - если это удастся исправить проблемы (код выхода 1, см. fsck man), тогда я бы сделал это состояние новым состояние машины, которое нужно восстановить, и снова начать использовать машину и надеяться на лучшее. Опять же, я бы заподозрил работоспособность этого жесткого диска и провел бы обширный тест на нем из загрузки системы восстановления, если проблемы не исчезнут. Если все это не помогает, проверяйте журналы каждый день и исследуйте ошибки за ошибками, которые вы там найдете. Удачи! - person Jamil Said; 03.05.2017