[libvirt-users] Problem with the use of domfsfreeze mountpoint option

[Payes Anand]

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 <eblake at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20141114/1a448675/attachment.htm>