У меня была эта проблема сегодня после сбоя питания.
У меня было 2 виртуальных машины, и одна из них не загружалась и использовала 100% ЦП и 100% памяти.
Поскольку это было очень сложно решить (по крайней мере, для меня), я хочу подробно описать здесь шаги, которые я сделал, чтобы исправить это, смешав множество руководств.
Сначала я попытался использовать установочный компакт-диск сервера Ubuntu и перейти в раздел «Восстановить сломанную систему», затем попытался переустановить GRUB, но это не удалось.
Затем я выключил неисправную виртуальную машину с помощью Force Shutdown.
Во-вторых, перечислил виртуальные машины в консоли 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
После этого я подключил рабочую виртуальную машину и вошел 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% CPU и 100% память.
Я поставил установочный компакт-диск Ubuntu Server (он у меня в хранилище ISO) и принудительно перезагрузился. Вошел в Rescue Broken System и смонтировал xvdb1 как мою корневую файловую систему. После этого я зашел в «Переустановить GRUB». Помните, что раньше он терпел неудачу, но на этот раз все получилось.
Я вынул компакт-диск и перезагрузился.
Моя виртуальная машина снова работает !!!
Кажется, это редкая проблема, потому что я не смог найти много информации об этом, только один парень на ServerFault, но без рабочего ответа (например, уничтожение домена vm или что-то в этом роде).
Я надеюсь, что это поможет кому-то, и не стесняйтесь редактировать это и очищать концепции, о которых я не знаю.
У меня тоже была эта пробема. Это помогло мне:
Возможно, проблема заключалась в том, что GRUB не отправляет видеосигнал.
Я видел много тем по этому поводу, и весьма вероятно, что моя виртуальная машина застряла. на этом экране GRUB, где вы ДОЛЖНЫ выбрать ОС для загрузки (учитывая тот факт, что они загружается нажатием Enter).
https://askubuntu.com/questions/372164/how-to-load-ubuntu-server-automatically-in-grub
Потому что это случилось со мной и после сбоев питания на невиртуализированном компьютере.
Просто щелкнул пустую область, нажал ввод, и он начал загружаться.