[libvirt-users] Problem with the use of domfsfreeze mountpoint option
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 --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. Best Regards, Payes
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
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
----- Original Message ----- | From: "Eric Blake" <eblake@redhat.com> | To: "Payes Anand" <payes.anand@cloudbyte.com>, libvirt-users@redhat.com | Sent: Wednesday, November 12, 2014 5:51:12 AM | Subject: Re: [libvirt-users] Problem with the use of domfsfreeze mountpoint | option | 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. On RHEL, the bug for adding FSFreeze function is this one : https://bugzilla.redhat.com/show_bug.cgi?id=1102457 And according commnet 10 in that bug, --mountpoint is not supported now. Whether you specify --mountpoing or not, it will always output Froze 2 filesystem(s) or Thawed 2 filesystem(s) | -- | Eric Blake eblake redhat com +1-919-301-3266 | Libvirt virtualization library http://libvirt.org | _______________________________________________ | libvirt-users mailing list | libvirt-users@redhat.com | https://www.redhat.com/mailman/listinfo/libvirt-users -- Regards shyu
participants (5)
-
Eric Blake -
Michal Privoznik -
Payes Anand -
Peter Krempa -
Shanzhi Yu