У меня есть виртуальная машина kvm с веб-сервером. Вчера, без внесения каких-либо изменений на сервере или хосте, эта виртуальная машина перестала отвечать. Насколько я могу судить, он зависает во время загрузки, постоянно используя 100% одного ядра процессора. На виртуальной машине выделено 2 процессора, но она потребляет только один, как показано в HTOP на хосте.
Единственный способ выключить его - это virsh destroy. И во время загрузки, насколько я могу видеть, виртуальная машина застревает во время загрузки со следующей проблемой:
[ 1.201865] List of all partitions:
[ 1.202927] No filesystem could mount root, tried:
[ 1.204415] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.206842] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.0-514.2.2.el7.x86_64 #1
[ 1.209032] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 1.210684] ffffffff818b4340 00000000de564bbf ffff880139abfd60 ffffffff816861cc
[ 1.212973] ffff880139abfde0 ffffffff8167f5d3 ffffffff00000010 ffff880139abfdf0
[ 1.215219] ffff880139abfd90 00000000de564bbf 00000000de564bbf ffff880139abfe00
[ 1.217494] Call Trace:
[ 1.218221] [<ffffffff816861cc>] dump_stack+0x19/0x1b
[ 1.219712] [<ffffffff8167f5d3>] panic+0xe3/0x1f2
[ 1.221149] [<ffffffff81b0a602>] mount_block_root+0x2a1/0x2b0
[ 1.222849] [<ffffffff81b0a664>] mount_root+0x53/0x56
[ 1.224358] [<ffffffff81b0a7a3>] prepare_namespace+0x13c/0x174
[ 1.226092] [<ffffffff81b0a270>] kernel_init_freeable+0x1f5/0x21c
[ 1.227882] [<ffffffff81b099db>] ? initcall_blacklist+0xb0/0xb0
[ 1.229656] [<ffffffff81674630>] ? rest_init+0x80/0x80
[ 1.231220] [<ffffffff8167463e>] kernel_init+0xe/0xf0
[ 1.232716] [<ffffffff81696718>] ret_from_fork+0x58/0x90
[ 1.234304] [<ffffffff81674630>] ? rest_init+0x80/0x80
Насколько я понимаю, возникла проблема с монтированием корневой файловой системы. Я не знаю, что мне делать в этой ситуации и что вызвало проблему. Если у вас есть какая-либо информация, которая может иметь отношение к моей ситуации, сообщите мне.
Я использую хранилище lvm на CentOS 7: Linux srv1.host.ro 3.10.0-514.6.2.el7.x86_64 #1 SMP Thu Feb 23 03:04:39 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Еще я проверил смарт на основном жестком диске, на котором хранится виртуальная машина, выглядит неплохо:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 175 174 021 Pre-fail Always - 2250
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 66
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 078 078 000 Old_age Always - 16090
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 66
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 56
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 517
194 Temperature_Celsius 0x0022 108 097 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
Последние журналы записей libvirt:
qemu: terminating on signal 15 from pid 1138
2017-02-23 09:15:02.440+0000: shutting down
2017-02-23 09:15:21.080+0000: starting up libvirt version: 2.0.0, package: 10.el7_3.4 (CentOS BuildSystem <http://bugs.centos.org>, 2017-01-17-23:37:48, c1bm.rdu2.centos.org), qemu version: 1.5.3 (qemu-kvm-1.5.3-126.el7_3.3), hostname: srv1.host.ro
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name Nginx -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu Penryn -m 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid be91646a-f5d3-494d-8a51-e9e598bfdf52 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-Nginx/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -drive file=/dev/Storage/Nginx,format=raw,if=none,id=drive-ide0-0-0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -drive if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:2c:e1:cd,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on
char device redirected to /dev/pts/0 (label charserial0)
Вы должны понимать, что поврежден образ виртуального диска, а не физический. Я бы попробовал следующие две вещи:
qemu-img check на изображении, чтобы убедиться, что на нем нет повреждений на уровне изображенияList of all partitions: предполагается, что за ним следует список всех разделов (очевидно). См. Например Linux 3.10 init / do_mounts.c: 418, часть mount_block_root():
printk("List of all partitions:\n");
printk_all_partitions();
printk("No filesystem could mount root, tried: ");
for (p = fs_names; *p; p += strlen(p)+1)
printk(" %s", p);
printk("\n");
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
panic("VFS: Unable to mount root fs on %s", b);
(The for (p = fs_names; ...) printk(...); Цикл - это просто причудливый способ напечатать список завершающихся нулем строк с нулевым завершением. Я мог бы объяснить, как это работает, но это займет несколько абзацев и не имеет отношения к вашей проблеме.)
Также обратите внимание Unable to mount root fs on unknown-block(0,0) в сообщении о панике ядра. В unknown-block(0,0) часть, безусловно, красный флаг.
printk_all_partitions() определяется в Linux 3.10 блок / genhd.c: 738 и в основном просто печатает список всех разделов диска, известных ядру на тот момент.
Можно сделать вывод, что что-то привело к тому, что ваша виртуальная машина KVM потеряла свои диски. (Подобные вещи также могут привести к неправильному поведению системы, в том числе к зависанию, которое вы испытали.) Изучите и исправьте это, и ваша виртуальная машина должна вернуться к жизни, предполагая, что данные все еще в порядке.
Поскольку вашей виртуальной машине не удалось смонтировать root до того, как root pivot из вашего initramfs в вашу систему, хранящуюся в «/ root», очень вероятно, что это проблема, связанная с тем, что ваш начальный ramdisk не может найти корневую файловую систему - либо потому, что это не так. там у initramfs нет инструментов, необходимых для его монтирования, или у вас есть какая-то ошибка тома или конфигурации загрузки.
Учитывая предоставленные доказательства, я бы сказал, что это, скорее всего, проблема на уровне гостевой ОС или у вас отсутствует диск, который раньше был подключен к этой виртуальной машине и имел какое-то отношение к корневой файловой системе. Например, если вы используете LVM на самой гостевой системе с несколькими участниками виртуального диска.
Также возможно, что обновление повлияло на аргументы времени загрузки или пакеты, установленные в initramfs. Обычно это происходит только тогда, когда вы обновляете ядро. Помимо этого, изменение конфигурации загрузчика или иногда изменение имени хоста или имен томов на машине с поддержкой LVM.
Кроме того, вполне возможно, что это произошло из-за настоящего сбоя файловой системы либо на хосте, либо на гостевой системе. Если он не настроен на регулярную проверку, вы можете рассмотреть возможность проверки базовых дисков, файловых систем и гостевых файловых систем в качестве простого шага по устранению неполадок.