Сценарий резервного копирования моей виртуальной машины не работает при создании снимка.
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
Даже после перезагрузки виртуальной машины система все еще не работает, и я получаю ту же ошибку.
Я думал, что quiesce означает зависание FS, но это не имеет смысла, так как я все еще могу писать в FS, когда захожу на неисправные виртуальные машины. И это не выдержит перезагрузки, правда?
Может быть, проблема со связью заставляет хост думать, что GA сообщает, что машина находится в состоянии покоя, в то время как это не так?
В любом случае, есть ли команда для запроса состояния покоя (помимо попытки сделать снимок и посмотреть, получаю ли я ошибку)?
Предполагая, что неисправные виртуальные машины перестали работать после невоспроизводимой ошибки, я мог бы исправить это, выйдя из приостановленного состояния, что бы это ни значило. Есть ли команда virsh для отмены стабилизации виртуальной машины?
Раньше вся процедура резервного копирования работала, и теперь она не работает на 2 виртуальных машинах, но все еще работает на 2 других, и я не могу придумать какой-либо существенной разницы между ними.
Версии программного обеспечения:
(Для записи сценарий резервного копирования здесь, на GitHub. По сути, он делает следующее: 1 / создает снимок, 2 / копирует, 3 / фиксирует снимок.)
Если я удалю quiesce из командной строки снимка, все работает гладко. Но очевидно, что это не идеально.
Основная причина - ошибка это было исправлено в 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
Обновление до более новой версии исправляет это.