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

[Payes Anand]

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