Thanks a lot for your replies. They were very useful in debugging the issues that i was facing.
I am using qemu 1.5 in both the host and the guest. While using libvirt 1.2.5, all the file systems on the domain were freezing. I have finally got an error message. After upgrading libvirt to 1.2.10, the command, # virsh domfsfreeze <domain> --mountpoint <mountpoint>, is giving the following error, error: internal error: unable to execute QEMU agent command 'guest-fsfreeze-freeze-list': The command guest-fsfreeze-freeze-list has not been found After upgrading to libvirt 1.2.10, i had not restarted libvertd services, due to which i was not getting the above error. What version of qemu-guest-agent is running in the guest? > qemu-guest-agent doesn't support per-mountpoint freezing until the > introduction of guest-fsfreeze-freeze-list in qemu 2.2 (still unreleased). > > They have released qemu-2.2.0-rc1, I have installed it in both the host and the guest, but still guest-fsfreeze-freeze-list is not found . On Thu, Nov 13, 2014 at 2:47 AM, Eric Blake <ebl...@redhat.com> wrote: > On 11/12/2014 10:24 AM, Michal Privoznik wrote: > >> What version of qemu-guest-agent is running in the guest? > >> qemu-guest-agent doesn't support per-mountpoint freezing until the > >> introduction of guest-fsfreeze-freeze-list in qemu 2.2 (still > >> unreleased). > >> > >>> > >>> --Upgraded libvirt to 1.2.10, but that also didn't solve the problem. > >>> > >>> Am i missing something over here? > >>> Any help would be greatly appreciated. > >> > >> I wonder if you may have uncovered a libvirt bug. If the guest agent is > >> not capable of supporting per-mount freezing (because the agent is too > >> old), the command should fail rather than blindly freezing everything. > >> But to know for sure, it would be good to find the log messages for the > >> actual agent commands issued by libvirt, to make sure we were actually > >> trying to freeze just a single mount point. > > > > Well, even though I agree I don't see way to achieve that. I mean, if > > libvirt would probe for qemu-ga commands/capabilities, by the time it > > makes a decision guest agent may have been downgraded, crashed, > > whatever. There's been some discussion on this topic (unfortunately I > > don't recall where currently). This is where guest agent is different to > > the monitor tremendously. > > Well, libvirt should still be able to at a minimum detect an error for > trying an unsupported command (as it must use a different command when > freezing specific mountpoints than for freezing all disks). > > > > > Although, I see a way that we could get something reasonable here. If > > qemu would tell us whenever somebody (dis-)connects (from)to the virtio > > channel. That way we could query the qemu-ga capabilities and make good > > decisions. And whenever we see a disconnect, we may just forget the > > qemu-ga capabilities and claim guest agent unresponsive (instead of this > > ping algorithm I'd came up with). > > Yes, qemu now provides that, as of qemu 2.1. It is the VSERPORT_CHANGE > event that fires whenever the guest opens or closes its connection to > the channel. And yes, we have more than one reason why we should wire > up libvirt to track when that event happens - we ALSO have people > requesting that we expose the information to management apps as a > libvirt event. > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
