libvirt users - Nov 2014 - Re: Problem with the use of domfsfreeze mountpoint option

On 11.11.2014 22:51, Eric Blake wrote:
> On 11/11/2014 01:58 PM, Payes Anand wrote:
>> Hi everybody,
>>
>> I am having a problem with the use of domfsfreeze command.
>>
>> It is freezing all the filesystems present on the domain,
>>
>> instead of freezing just the mountpoints provided.
>>
>> I am issuing the command--
>>
>> # virsh domfsfreeze <domain> --mountpoint <mountpoint>
>>
>> Output was-- Froze 3 filesystem(s)
>>
>>
>> I want to freeze a particular mount point on the VM, so that i can
>> take a snapshot using my own snapshot feature.
>>
>> Using library: libvirt 1.2.5
>> Using API: QEMU 1.2.5
>> Running hypervisor: QEMU 2.0.0
>
> 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.

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).

Michal

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

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@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
>
>

On 11/12/14 22:17, Eric Blake wrote:
> On 11/12/2014 10:24 AM, Michal Privoznik wrote:
...
>> 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.
> 
I'm currently writing code to add this feature/event.

Peter