Re: [libvirt-users] Problem with the use of domfsfreeze mountpoint option
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(a)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
Attachments:
- attachment.html (text/html — 2.8 KB)