Ошибка virsh: домен уже приостановлен

Сценарий резервного копирования моей виртуальной машины завершается ошибкой при создании снимка.

virsh snapshot-create-as --domain machine_1 snap --diskspec vda,file=/srv/test/test-snap.qcow2 --disk-only --atomic --no-metadata --quiesce
error: Requested operation is not valid: domain is already quiesced

Даже после перезагрузки виртуальной машины система все еще не работает, и я получаю ту же ошибку.

Я думал, что покоя означает замораживание FS, но это не имеет смысла, так как я все еще могу писать в FS при входе в неисправные виртуальные машины. И это не переживет перезагрузку, верно?

Может ли это быть проблема связи, которая заставляет хозяина думать, что GA говорит, что машина остановлена, а это не так?

В любом случае, есть ли команда для запроса состояния покоя (кроме попытки сделать снимок и посмотреть, получаю ли я ошибку)?

Предполагая, что неисправные виртуальные машины перестали работать после невоспроизводимой ошибки, я мог бы исправить это, выйдя из состояния покоя, что бы это ни значило. Есть ли команда virsh, чтобы отключить VM?

Вся процедура резервного копирования работала, и теперь она не работает на 2 виртуальных машинах, но все еще работает на 2 других, и я не могу думать о какой-либо существенной разнице между ними.

Версии программного обеспечения:

  • Хост - Debian Jessie с qemu-kvm 2.8+dfsg-3~bop8+1 из бэкпортов.
  • Гости Debian Stretch с qemu-guest-agent 2.8 + dfsg-6 + deb9u4.

(Для записи, скрипт резервного копирования находится здесь на GitHub. По сути, он делает 1/ создать снимок, 2/ копировать, 3/ зафиксировать снимок.)

Если я удалю quiesce опция из командной строки снимка, все работает гладко. Но, очевидно, это не идеально.

Источник

1 ответ

Решение

Основной причиной является ошибка, которая была исправлена ​​в libvirt 1.2.11.

Исправлено:

commit 6085d917d5c5839b7ed351e99fadbbb56f5178fe
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Nov 27 11:43:56 2014 +0100

qemu: Don't track quiesced state of FSs

https://bugzilla.redhat.com/show_bug.cgi?id=1160084

As of b6d4dad11b (1.2.5) we are trying to keep the status of FSFreeze
in the guest. Even though I've tried to fixed couple of corner cases
(6ea54769ba18), it occurred to me just recently, that the approach is
broken by design. Firstly, there are many other ways to talk to
qemu-ga (even through libvirt) that filesystems can be thawed (e.g.
qemu-agent-command) without libvirt noticing. Moreover, there are
plenty of ways to thaw filesystems without even qemu-ga noticing (yes,
qemu-ga keeps internal track of FSFreeze status). So, instead of
keeping the track ourselves, or asking qemu-ga for stale state, it's
the best to let qemu-ga deal with that (and possibly let guest kernel
propagate an error).

Moreover, there's one bug with the following approach, if fsfreeze
command failed, we've executed fsthaw subsequently. So issuing
domfsfreeze in virsh gave the following result:

virsh # domfsfreeze gentoo
Froze 1 filesystem(s)

virsh # domfsfreeze gentoo
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance

virsh # domfsfreeze gentoo
Froze 1 filesystem(s)

virsh # domfsfreeze gentoo
error: Unable to freeze filesystems
error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze': The command guest-fsfreeze-freeze has been disabled for this instance

Обновление до более новой версии исправляет это.

Источник
Другие вопросы по тегам