У меня была эта проблема сегодня после сбоя питания.
У меня было 2 vms, и один из них не загрузит и использовал 100% ЦП и 100% памяти.
Так как было очень трудно решить (по крайней мере, для меня), я хочу детализировать здесь шаги, которые я сделал для фиксации его, смешав много учебных руководств.
У меня тоже была эта проблема. Это помогло мне :
Возможно, проблема заключалась в том, что GRUB не отправлял видеосигнал.
Я видел много обсуждений по этому поводу, и весьма вероятно, что мои виртуальные машины зависли на этом экране GRUB, где вы ДОЛЖНЫ выбрать ОС для загрузки (учитывая тот факт, что они загружались нажатием клавиши ввода ).
https://askubuntu.com/questions/372164/ how-to-load-ubuntu-server-automatic-in-grub
Потому что это случилось со мной и после сбоев питания на невиртуализированном компьютере.
Просто щелкнул в пустой области, нажал Enter, и он началась загрузка.
Сначала я попытался использовать установочный компакт-диск сервера Ubuntu и перейти в раздел «Восстановление сломанной системы», затем попытался переустановить GRUB, но это не удалось.
Затем я выключил неисправную виртуальную машину с помощью Принудительное завершение работы.
Во-вторых, перечисленные виртуальные машины в консоли XenCenter
[root@xen01 ~]# xe vm-list
uuid ( RO) : d56d5ae8-62de-5e7e-41f9-1bd707d727d9
name-label ( RW): fdev-appgw
power-state ( RO): halted
uuid ( RO) : 87aba275-0e05-4160-bebf-efc85fe93386
name-label ( RW): fdev-tracker
power-state ( RO): halted
uuid ( RO) : c81439c2-a345-4f04-947e-34554718ce7e
name-label ( RW): Control domain on host: fdev-xen01
power-state ( RO): running
fdev-tracker вызвали сбой.
Перечислили его диски. Должен признаться, я не знаю, зачем мне здесь 2 диска, поскольку я относительно новичок в Linux. Но я использовал первую, которая гласит: Device: hdb
[root@xen01 ~]# xe vbd-list vm-name-label=fdev-tracker
uuid ( RO) : d461e06d-9cc3-7762-f141-0b3d2abe7b3c
vm-uuid ( RO): 87aba275-0e05-4160-bebf-efc85fe93386
vm-name-label ( RO): fdev-tracker
vdi-uuid ( RO): 92dd9489-b450-4766-8853-b8b2fc9597ad
empty ( RO): false
device ( RO): hdb
uuid ( RO) : 969fc0c8-1fcf-ed2c-ed6e-a71dc3c359d9
vm-uuid ( RO): 87aba275-0e05-4160-bebf-efc85fe93386
vm-name-label ( RO): fdev-tracker
vdi-uuid ( RO): ba9e2ed8-c9db-4f95-8f14-2d51c99ea992
empty ( RO): false
device ( RO): hdd
После нее я ввел эти команды, чтобы иметь возможность смонтировать диск в другой моей виртуальной машине Linux. Я не знаю точно, что они делают, но это то, что написано в руководствах. Обратите внимание, что d56d5ae8-62de-5e7e-41f9-1bd707d727d9 - это UUID рабочей виртуальной машины. Раньше у меня были проблемы, потому что в руководстве это не прояснялось. 92dd9489-b450-4766-8853-b8b2fc9597ad - это UUID неисправного компьютера VDI.
[root@xen01 ~]# xe vbd-create vm-uuid=d56d5ae8-62de-5e7e-41f9-1bd707d727d9 vdi-uuid=92dd9489-b450-4766-8853-b8b2fc9597ad device=autodetect
91022555-2b86-4faf-cce1-eb62efc8aab7
Он выводит UUID. Я использовал его, чтобы подключить его к рабочей машине.
[root@xen01 ~]# xe vbd-plug uuid=91022555-2b86-4faf-cce1-eb62efc8aab7
После этого я подключил рабочую виртуальную машину по ssh и ввел parted
:
jsivil@appgw:/proc$ sudo parted
GNU Parted 2.3
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print devices
/dev/xvda (10,7GB)
/dev/xvdb (21,5GB)
(parted) quit
/ dev / xvdb
вот этот, 21 ГБ занимает диск отказавшей виртуальной машины.
Я попытался выполнить на нем fsck:
jsivil@appgw:/proc$ sudo fsck -p -c -v -f /dev/xvdb
fsck from util-linux 2.20.1
fsck.ext2: Bad magic number in super-block while trying to open /dev/xvdb
/dev/xvdb:
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Но я вспомнил, что при форматировании у него было 2 раздела, один для всей файловой системы (ext4), а другой для подкачки ( ext3 думаю). Так что, возможно, это вызывало проблемы.
Затем я увидел другое руководство, в котором использовалась программа под названием kpartx
. У меня его не было, поэтому я сделал:
sudo apt-get install kpartx
Потом сделал:
jsivil@appgw:/proc$ sudo kpartx -a /dev/xvdb
Похоже, он делает разделы видимыми или что-то в этом роде. Теперь они находятся в / dev / mapper /
jsivil@appgw:/proc$ sudo fsck -p -c -v -f /dev/mapper/ #tab press
control xvdb1 xvdb2 xvdb5
So I made the fsck on all xvdb*:
jsivil@appgw:/proc$ sudo fsck -p -c -v -f /dev/mapper/xvdb1
fsck from util-linux 2.20.1
/dev/mapper/xvdb1: Updating bad block inode.
126881 inodes used (10.05%, out of 1262320)
65 non-contiguous files (0.1%)
120 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 117890/29
778957 blocks used (15.43%, out of 5047040)
0 bad blocks
1 large file
99695 regular files
17528 directories
55 character device files
25 block device files
0 fifos
28 links
9564 symbolic links (8869 fast symbolic links)
5 sockets
------------
126900 files
jsivil@appgw:/proc$ sudo fsck -p -c -v -f /dev/mapper/xvdb
xvdb1 xvdb2 xvdb5
jsivil@appgw:/proc$ sudo fsck -p -c -v -f /dev/mapper/xvdb2
fsck from util-linux 2.20.1
fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/mapper/xvdb2
Could this be a zero-length partition?
jsivil@appgw:/proc$ sudo fsck -p -c -v -f /dev/mapper/xvdb5
fsck from util-linux 2.20.1
fsck: fsck.swap: not found
fsck: error 2 while executing fsck.swap for /dev/mapper/xvdb5
. Я не знаю, почему это не удалось на xvdb2 (и что это такое, потому что для меня в нем должно быть только 2 раздела). xvdb5 был свопом, так что это не имело значения. Затем я попытался смонтировать, чтобы увидеть, смогу ли я увидеть свои файлы (я смог использовать компакт-диск Ubuntu Server), но мне было любопытно.
cd to /run/shm
jsivil@appgw:/run/shm$ mkdir /run/shm/a
jsivil@appgw:/run/shm$ sudo mount -t ext4 /dev/mapper/xvdb1 a
Я нажал «а», и все было там. Я отмонтировал его.
Затем я вернулся к основному руководству по XenServer и попытался отключить его от ВМ
[root@xen01 ~]# xe vbd-unplug uuid=91022555-2b86-4faf-cce1-eb62efc8aab7
The VM rejected the attempt to detach the device.
type: VBD
ref: 91022555-2b86-4faf-cce1-eb62efc8aab7
msg:
Кажется, что на некоторых из предыдущих шагов в рабочей ВМ диск находился в состоянии «используется» или что-то в этом роде.
Итак, я перезагрузил рабочую виртуальную машину. Пытался сделать это еще раз, но виртуальная машина все еще перезагружалась. Итак, я получил еще одну ошибку. Подождал, пока он закончит, и смог это сделать.
[root@xen01 ~]# xe vbd-unplug uuid=91022555-2b86-4faf-cce1-eb62efc8aab7
You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected.
vm: d56d5ae8-62de-5e7e-41f9-1bd707d727d9 (fdev-appgw)
[root@xen01 ~]# xe vbd-unplug uuid=91022555-2b86-4faf-cce1-eb62efc8aab7
[root@xen01 ~]# xe vbd-destroy uuid=91022555-2b86-4faf-cce1-eb62efc8aab7
После всего этого я попытался загрузить неисправный компьютер, но мне не повезло :( Та же проблема была, 100% ЦП и 100% память.
Я поставил на установочный компакт-диск Ubuntu Server (Он у меня в хранилище ISO) и принудительная перезагрузка. Вошел в Rescue Broken System и смонтировал xvdb1 как мою корневую файловую систему. После этого я зашел в «Переустановить GRUB». Помните, что раньше он не работал, но на этот раз все прошло успешно.
Я вынул компакт-диск и перезагрузился.
Моя виртуальная машина снова работает !!!
Это редкая проблема, потому что я не смог найти много информация об этом, только один парень на ServerFault, но без рабочего ответа (например, уничтожение домена vm или что-то в этом роде).
Я надеюсь, что это поможет кому-то и не стесняйтесь редактировать это и очищать концепции, которые я не знаю о.