XenServer 6.2 VM 100% ЦП и 100%-е использование памяти и не загрузится

У меня была эта проблема сегодня после сбоя питания.

У меня было 2 vms, и один из них не загрузит и использовал 100% ЦП и 100% памяти.

Так как было очень трудно решить (по крайней мере, для меня), я хочу детализировать здесь шаги, которые я сделал для фиксации его, смешав много учебных руководств.

2
задан 3 January 2015 в 23:56
2 ответа

У меня тоже была эта проблема. Это помогло мне :

Возможно, проблема заключалась в том, что GRUB не отправлял видеосигнал.

Я видел много обсуждений по этому поводу, и весьма вероятно, что мои виртуальные машины зависли на этом экране GRUB, где вы ДОЛЖНЫ выбрать ОС для загрузки (учитывая тот факт, что они загружались нажатием клавиши ввода ).

https://askubuntu.com/questions/372164/ how-to-load-ubuntu-server-automatic-in-grub

Потому что это случилось со мной и после сбоев питания на невиртуализированном компьютере.

Просто щелкнул в пустой области, нажал Enter, и он началась загрузка.

1
ответ дан 3 December 2019 в 10:02

Сначала я попытался использовать установочный компакт-диск сервера 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 или что-то в этом роде).

Я надеюсь, что это поможет кому-то и не стесняйтесь редактировать это и очищать концепции, которые я не знаю о.

3
ответ дан 3 December 2019 в 10:02

Теги

Похожие вопросы