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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list