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

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

As stated in the below link from libvirt-list,
https://www.redhat.com/archives/libvir-list/2014-May/msg00033.html
> OpenStack cinder provides these storages' snapshot feature, but it
cannot
>  quiesce the guest filesystems automatically for now.
>
>
This patchset adds virDomainFSFreeze()/virDomainFSThaw() APIs and
virsh
> domfsfreeze/domfsthaw commands to enable the users to freeze and thaw
> domain's filesystems cleanly.
>
Do these API's ( commands ) also push the dirty buffer to the disk, or it
has to be done separately before freezing, to take snapshots.

If we don't specify any mount points, how different is
domfsfreeze/domfsthaw from suspend/resume. Which of them would be better to
take live incremental external snapshots of iSCSI devices.

Regards,
Payes



On Fri, Nov 14, 2014 at 4:03 PM, Peter Krempa <pkrempa@redhat.com> wrote:
> 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
>
>
>

On 11/17/2014 07:37 AM, Payes Anand wrote:
> This patchset adds virDomainFSFreeze()/virDomainFSThaw() APIs and virsh
>> domfsfreeze/domfsthaw commands to enable the users to freeze and thaw
>> domain's filesystems cleanly.
>>
> 
> Do these API's ( commands ) also push the dirty buffer to the disk, or
it
> has to be done separately before freezing, to take snapshots.
virDomainFSFreeze does whatever the guest agent is wired to do (and the
default implementation of qemu-guest-agent has hooks for you to add any
additional work around the envelope of freezing your guest's
filesystem).  There have been other threads on this list on how to add a
hook that prepares a database to be frozen, for example.  Passing the
--quiesce flag to taking a snapshot is just shorthand for triggering the
same actions as what you manually control by calling virDomainFSFreeze
yourself.
> 
> If we don't specify any mount points, how different is
> domfsfreeze/domfsthaw from suspend/resume. Which of them would be better to
> take live incremental external snapshots of iSCSI devices.
suspend does NOT flush pending guest I/O.  It just stops the guest CPUs
from making further changes.  Taking a snapshot of a suspended guest is
NOT going to be consistent in the same way as a snapshot of a guest that
has had its filesystems frozen (that is, booting the disks that were
copied from the time that a guest was frozen will likely need fsck
repair, and will not contain pending I/O transactions that were still
held in memory; while booting a disk that was copied while filesystems
were frozen should see a fully consistent file system that is not
lacking any pending I/O).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org