Здравствуйте.
Стоит KVM на Centos 6.3.

Был образ системы на отдельном массиве RAID 1. Я случайно его удалил во время работы гостевой системы.
Гость продолжает работать. Диск показывает что место занято. А удаленного файла нет.

Что делать?

2 (26.04.2013 21:21:09 отредактировано bormant)

Файл на диске продолжит свое существование без имени до тех пор, пока не будет закрыт всеми процессами, после этого освободится место и файл перестанет существовать как организованная цепочка кластеров, хоть и безымянная.
Можно попробовать найти открытый дескриптор на хосте (не госте) c нужным файлом (в каталоге /proc/ид_процесса/fd/дескриптор) и скопировать содержимое. Не факт, что скопированное окажется в непротиворечивом состоянии, но для повышения вероятности в получении исправного образа есть смысл предварительно перевести гостевую машину в монопольный режим telinit 1 или init 1 (ни в коем случае не перезагрузкой!!!, если kvm отпустит дескриптор -- образ придётся восстанавливать средствами работы с ФС с неизвестным результатом).

3

Пример:
tty1:

$ echo test > /tmp/test.txt
$ mcview /tmp/test.txt

tty2:

# ps ax | grep mcview
 8854 pts/0    S+     0:00 mcview /tmp/test.txt

# ls -l /proc/8854/fd
...
5 -> /tmp/test.txt

# rm /tmp/test.txt
# ls -l /proc/8854/fd
...
5 -> /tmp/test.txt\ (deleted)

# cp /proc/8854/fd/5 /tmp/test.bak
# cat /tmp/test.bak
test

Вуаля!

4 (26.04.2013 21:47:00 отредактировано magistr_forever)

bormant⇓ пишет:

Можно попробовать найти открытый дескриптор на хосте (не госте) c нужным файлом (в каталоге /proc/ид_процесса/fd/дескриптор)

Содержимое
/proc/ид_процесса/fd/
Что с этим делать?

Это оно?
5 -> /dev/kvm

итого 0
dr-x------. 2 qemu qemu  0 Апр 26 21:40 .
dr-xr-xr-x. 7 qemu qemu  0 Апр 26 20:07 ..
lrwx------. 1 qemu qemu 64 Апр 26 21:41 0 -> /dev/null
l-wx------. 1 qemu qemu 64 Апр 26 21:41 1 -> /var/log/libvirt/qemu/debian_doy.log
lrwx------. 1 qemu qemu 64 Апр 26 21:41 10 -> anon_inode:[signalfd]
lr-x------. 1 qemu qemu 64 Апр 26 21:41 11 -> /iso/debian-6.0.6-amd64-netinst.iso
lrwx------. 1 qemu qemu 64 Апр 26 21:41 12 -> anon_inode:kvm-vcpu
lrwx------. 1 qemu qemu 64 Апр 26 21:41 13 -> anon_inode:kvm-vcpu
lrwx------. 1 qemu qemu 64 Апр 26 21:41 14 -> socket:[24342]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 15 -> socket:[24340]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 16 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 17 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 18 -> anon_inode:[signalfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 19 -> socket:[24392]
l-wx------. 1 qemu qemu 64 Апр 26 21:41 2 -> /var/log/libvirt/qemu/debian_doy.log
lrwx------. 1 qemu qemu 64 Апр 26 21:41 20 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 21 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 22 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 23 -> /dev/net/tun
lrwx------. 1 qemu qemu 64 Апр 26 21:41 24 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 25 -> /dev/vhost-net
lrwx------. 1 qemu qemu 64 Апр 26 21:41 26 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 27 -> anon_inode:[eventfd]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 3 -> socket:[24328]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 4 -> /dev/ptmx
lrwx------. 1 qemu qemu 64 Апр 26 21:41 5 -> /dev/kvm
lrwx------. 1 qemu qemu 64 Апр 26 21:41 6 -> anon_inode:kvm-vm
lr-x------. 1 qemu qemu 64 Апр 26 21:41 7 -> pipe:[24334]
l-wx------. 1 qemu qemu 64 Апр 26 21:41 8 -> pipe:[24334]
lrwx------. 1 qemu qemu 64 Апр 26 21:41 9 -> /kvm/.Trash-0/expunged/953814782 (deleted)

5

а как назывался удалённый файл?
В приведённом списке единственный удалённый, это
lrwx------. 1 qemu qemu 64 Апр 26 21:41 9 -> /kvm/.Trash-0/expunged/953814782 (deleted)

Но, если правильно путаю, он удалён из корзины.

Либо это и есть искомый файл, но перед удалением был помещён в корзину, либо реальный процесс виртуальной машины имеет иной id?

magistr_forever⇓ пишет:

Содержимое
/proc/ид_процесса/fd/
Что с этим делать?

Если внимательно посмотрите на пример выше, увидите, что командой "ps ax" был получен список процессов, который затем был отфильтрован при помощи grep по имени процесса "mcview" чтобы узнать идентификатор процесса, в примере был "8854". Затем в каталоге /proc/8854/fd/ был установлен дескриптор открытого удалённого файла, в примере "5", который был скопирован под новым именем, в примере /tmp/test.bak, командой "cp".

magistr_forever⇓ пишет:

Это оно?
5 -> /dev/kvm

Наверняка -- нет.

6 (26.04.2013 22:05:27 отредактировано magistr_forever)

bormant⇓ пишет:

а как назывался удалённый файл?

debian_doy.img

Он был в корзине. И потом удален оттуда.

7

Тогда скорее всего вам нужен из приведённого списка именно 9, скопируйте его в нужное место под именем debian_doy.img и попробуйте запустить с ним новую виртуальную машину в целях проверки работоспособности. Если всё в порядке, считайте, что вам повезло.

Удачи!

8 (26.04.2013 22:43:35 отредактировано magistr_forever)

bormant⇓ пишет:

Тогда скорее всего вам нужен из приведённого списка именно 9, скопируйте его в нужное место под именем debian_doy.img и попробуйте запустить с ним новую виртуальную машину в целях проверки работоспособности. Если всё в порядке, считайте, что вам повезло.

Скопировал, он занимает 42 кб. И с восклицательным знаком имя стало.
А должен 250 Гб.

или его нужно было скопировать в /kvm/.Trash-0/expunged/ ?



Есть резервная копия полного диска. Но старая. Может ее как-то использовать?

9 (27.04.2013 00:06:14 отредактировано Fat-Zer)

magistr_forever⇓ пишет:

Скопировал, он занимает 42 кб. И с восклицательным знаком имя стало.А должен 250 Гб.или его нужно было скопировать в /kvm/.Trash-0/expunged/ ?

копировал через cp, а не через какой-то файл-менеджер?
и на всякий пожарный, что говорит о нём file? и какое его содержимое(если на вид оно осмысленное)

95% процентов проблем находятся между клавиатурой и стулом.
Fat-Zer⇓ пишет:

копировал через cp, а не через какой-то файл-менеджер?

Да, через mc.

Щас написал cp, идет копирование. Уже 23 ГБ!!!! be

Ждем результата.....

ВСЕ ЗАРАБОТАЛО!

Всем спасибо!
az