+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Команда guest-agent fs-freeze ломает систему при резервном копировании., Proxmox Виртуальная Среда

Amin Vakil

Guest

11.05.2020 14:07:00

Одна из ВМ, которую я каждую неделю бэкаплю, сломалась, когда Proxmox выдал команду guest-agent 'fs-freeze'. Я мог пинговать сервер, но ничего не работало (практически все порты были недоступны, оставшиеся не отвечали ни на что, и я не мог подключиться по SSH). Хоть я и не сталкивался с этой проблемой за три года использования Proxmox и последние три месяца включения и установки qemu-guest-agent на хост и ВМ, я подождал 20 минут, но ничего не происходило, затем остановил бэкап, зашёл на хост и выполнил qm unlock 201 && qm reset 201 (201 — идентификатор ВМ). Затем, когда ВМ загрузилась, я отредактировал командную строку GRUB и добавил в конец (просто чтобы быть уверенным, что файловая система не повреждена): fsck.mode=force fsck.repair=yes. Во время загрузки сервера исправлялось много ошибок, они выглядели примерно так: [170.013464] systemd-fsck[639]: Неверное количество свободных блоков для группы #2160 (23153, counted=23948). [ 170.014860] systemd-fsck[639]: Исправить? yes и это [170.142921] systemd-fsck[639]: Неверное количество директорий для группы #2000 (1394, counted=871). [ 170.145106] systemd-fsck[639]: Исправить? yes. Затем сервер загрузился, и всё было в порядке. Я провёл ручной бэкап ещё раз, и та же проблема произошла: всё зависло, когда бэкап дошёл до команды guest-agent 'fs-freeze', и я не мог ничего сделать, кроме как разблокировать и принудительно сбросить ВМ. Сервер обновлён CentOS 7 (2003) с установленным cPanel. Не знаю, поможет ли это или нет, но у ВМ три жёстких диска, бэкап включён только для первого, на котором установлена ОС. Первый жёсткий диск находится в директории "sas", а бэкап записывается в другую директорию "sata". Вот журнал первого запланированного бэкапа (журнал ошибки ручного бэкапа точно такой же): INFO: Начинается бэкап ВМ 201 (qemu) INFO: Бэкап начат в 2020-05-09 02:00:58 INFO: status = running INFO: Имя ВМ: ircpanel1 INFO: включён диск 'virtio0' 'sas:201/vm-201-disk-0.qcow2' 80G INFO: исключён диск 'virtio1' 'sata:201/vm-201-disk-0.qcow2' (backup=no) INFO: исключён диск 'virtio2' 'sata:201/vm-201-disk-1.qcow2' (backup=no) INFO: режим бэкапа: snapshot INFO: ionice priority: 7 INFO: создание архива '/mnt/pve/sata/dump/vzdump-qemu-201-2020_05_09-02_00_58.vma.lzo' INFO: выполняется команда guest-agent 'fs-freeze' INFO: закрытие с чтение буфера по /usr/share/perl5/IO/Multiplex.pm line 927. ERROR: прервано сигналом INFO: выполняется команда guest-agent 'fs-thaw' TASK ERROR: получено неожиданное управляющее сообщение:

wolfgang Guest	#2 0 12.05.2020 07:03:00 Привет, можешь попробовать следующие команды? И напиши потом, что получилось? Код: qm guest cmd 103 fsfreeze-status qm guest cmd 103 fsfreeze-freeze qm guest cmd 103 fsfreeze-status qm guest cmd 103 fsfreeze-thaw

Amin Vakil

Guest

12.05.2020 07:25:00

qm guest cmd 201 fsfreeze-status
thawed
qm guest cmd 201 fsfreeze-freeze
^C
qm guest cmd 201 fsfreeze-status
QEMU guest agent не работает. Через 5 минут я прервал fsfreeze-freeze, и все сервисы сломались. Я перезагрузил сервер, но он не перезагрузился корректно, поэтому я принудительно его перезагрузил. Попытка снова запустить fsck на GRUB привела к следующему: systemd-fsck[631]: Неверное количество свободных блоков (70620473, посчитано=70441515).
systemd-fsck[631]: Исправить? да
systemd-fsck[631]: Неверное количество свободных inode (19338401, посчитано=19313508).
systemd-fsck[631]: Исправить? да Хотя на этот раз были только эти две ошибки. Теперь при выполнении fsfreeze-status я получаю следующий результат: qm guest cmd 201 fsfreeze-status
thawed Думаю, пытаться выполнить fsfreeze-freeze снова бессмысленно и опасно.

wolfgang Guest	#4 0 12.05.2020 08:48:00 Здесь все работает с чистой установкой CentOS со всеми обновлениями без проблем.

Amin Vakil Guest	#5 0 12.05.2020 08:49:00 Да, проблема только с этим сервером. Может, подскажете, в чем дело?

wolfgang Guest	#6 0 12.05.2020 11:14:00 Загляни в логи ядра, может, там увидишь проблему. Обновись до последней версии ядра.

Amin Vakil Guest	#7 0 12.05.2020 12:03:00 У меня была проблема, и я не мог разобраться, в чем дело. Как бы то ни было, я все равно собираюсь перенести данные на другой сервер. Спасибо, все равно!

hancok62

Guest

22.06.2020 00:49:00

Привет, у меня та же проблема, те же логи, всё то же самое. INFO: отправка команды гостевого агента 'fs-freeze' с закрытием буфера чтения в /usr/share/perl5/IO/Multiplex.pm строка 927. ОШИБКА: прервано сигналом INFO: отправка команды гостевого агента 'fs-thaw' как amin, когда я запускаю: Код: qm guest cmd 103 fsfreeze-freeze
^C
qm guest cmd 103 fsfreeze-status
QEMU guest agent не запущен, когда я запускаю qemu-agent ping ничего не показывает (кажется, это то, что нужно). Код: qm agent 100 ping proxmox info: Код: pveversion -v

proxmox-ve: 6.2-1 (ядро: 5.4.41-1-pve)
pve-manager: 6.2-6 (версия: 6.2-6/ee1d7754)
pve-kernel-5.4: 6.2-2
pve-kernel-helper: 6.2-2
pve-kernel-5.0: 6.0-11
pve-kernel-5.4.41-1-pve: 5.4.41-1
pve-kernel-5.0.21-5-pve: 5.0.21-10
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.3-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksmtuned: 4.20150325+b1
libjs-extjs: 6.0.1-10
libknet1: 1.15-pve1
libproxmox-acme-perl: 1.0.4
libpve-access-control: 6.1-1
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.1-3
libpve-guest-common-perl: 3.0-10
libpve-http-server-perl: 3.0-5
libpve-storage-perl: 6.1-8
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.2-1
lxcfs: 4.0.3-pve2
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.2-7
pve-cluster: 6.1-8
pve-container: 3.1-8
pve-docs: 6.2-4
pve-edk2-firmware: 2.20200229-1
pve-firewall: 4.1-2
pve-firmware: 3.1-1
pve-ha-manager: 3.0-9
pve-i18n: 2.1-3
pve-qemu-kvm: 5.0.0-4
pve-xtermjs: 4.3.0-1
pve-zsync: 2.0-3
qemu-server: 6.2-3
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.4-pve1 Код: virtualmachine info:

Linux hostname.hostname 3.10.0-1127.10.1.el7.x86_64 #1 SMP Wed Jun 3 14:28:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
qemu-agent включен и запущен в виртуальной машине
ОС: centos7

Razva Guest	#9 0 07.07.2020 01:18:00 Такая же проблема, как и у всех.

aychprox Guest	#10 0 02.08.2020 04:40:00 У меня та же проблема на нескольких cPanel VM. Как только доходит до этапа freezefs, VM зависает. Это происходило только на PBS, работает на NFS хранилище – без проблем с бэкапом.

alexvyi Guest	#11 0 04.08.2020 20:18:00 У меня та же проблема, но после обновления ядра в CentOS заработало. Pve 6.2-10, Dell PowerEdge R610 с SSD. Если кому-то нужны дополнительные детали — пишите.

Faris Raouf

Guest

#12

04.08.2020 20:47:00

@alexvyi - помнишь, какой у тебя был установлен kernel? Я использую 3.10.0-1127.13.1 и qemu-guest-agent-2.12.0-3 в большинстве своих CentOS (7) VMs без проблем (также 6.2-10 полностью обновлён). У меня также есть VM одного клиента с ещё более старым kernel-ом (...)- 8.1, думаю, который тоже работает нормально, хотя в нём будет установлена более старая версия qemu-guest-agent. Всё ext4 с LVM. Оборудование - все Dell 640s с SSD, резервирующимися на обычные HDD. Образы дисков VM от 20GB до 600GB. Все, кроме старой, недавно обновились до (...)- 18.2, хотя пока ни один не был зарезервирован с этим kernel-ом. Но чем больше я вижу подобные отчеты, тем больше я пугаюсь. Если это не файловые системы, повреждаемые во время резервного копирования, то это таблица разделов (как сообщалось в нескольких других постах). Процесс резервного копирования, который потенциально может нанести вред данным, которые я пытаюсь защитить, - это то, с чем я некомфортно чувствую себя, независимо от того, виноват ли vzbackup, qmenu-guest-agent, kernel или что-то ещё. К сожалению, если разработчики не смогут воспроизвести это (и похоже, что они не могут), то им приходится полагаться на людей, которые столкнулись с этой проблемой, чтобы они опубликовали bug report и предоставили достаточно подробной информации, чтобы они могли хоть как-то продвинуться в понимании того, что происходит. Это понятно. Никто не может жаловаться на это для обычных проблем. Разработчики не могут магически обнаружить причину, если у них нет данных. Но для проблемы такого рода, где процесс резервного копирования потенциально может уничтожить данные, я бы действительно предпочёл видеть более проактивный ответ. Конечно, возможно, я переносит свою одержимость проблемами резервного копирования и закрашиваю свой judgement, но я не думаю, что неразумно хотеть видеть более позитивный ответ, особенно с тем количеством пользователей, которые сообщают о проблемах, которые я считаю значительным. Пожалуйста?

alexvyi

Guest

#13

04.08.2020 20:56:00

Обновите ядро до kernel-3.10.0-1127.18.2.el7.x86_64 и, конечно, перезагрузите машину. Если вам страшно, используйте кластер для еще большей отказоустойчивости. И держите сервер Proxmox в вашей локальной сети только для хранения резервных копий. Как раз это я и делаю (ежедневно). И эта проблема возникла сегодня, так что даже если бы pve сломался, у меня была бы вчерашняя резервная копия.

alexvyi Guest	#14 0 04.08.2020 20:57:00 Извини, это новый ядро. То, которое заменили сегодня, я точно сказать не могу... Извини ещё раз.

Razva Guest	#15 0 05.08.2020 17:15:00 Это исправлено в последнем ядре?

alexvyi Guest	#16 0 05.08.2020 17:20:00 Для моей конфигурации это подходит, и я делаю резервную копию ВМ с 1 терабайтным SCSI-жестким диском.

alexvyi Guest	#17 0 06.08.2020 17:56:00 Снова это случилось. Заработало только после перезагрузки. Происходит это только с корпоративной версией. На других машинах у меня (с открытым исходным кодом) я такого никогда не видел.

alexvyi Guest	#18 0 15.08.2020 10:37:00 И снова то же самое. Может, кто-нибудь из Proxmox глянет? Или попробует воссоздать ситуацию, чтобы понять, что не так?

igerlster Guest	#19 0 15.10.2020 11:45:00 И у меня так же, самая новая Ubuntu 18.04 Server, всё обновлено. На моих Ubuntu 20.04 всё работает.

alexvyi Guest	#20 0 15.10.2020 16:51:00 Привык, к сожалению. Просто вечером вырубаю виртуальную машину, делаю бэкап, перезагружаю и всё. Пока что.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры