On Thu, Nov 27, 2014 at 13:27:25 +0100, Michal Privoznik wrote:
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
s/fixed/fix/
(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)
Heh, nice. I agree, we should not try to remember the state and just
send the command to qemu-ga.
ACK
Jirka