libvirt users - Feb 2020 - RE: guest-fsfreeze-freeze freezes all mounted block devices

Hi Peter,

Should I assume that the virsh domfsfreeze, does not require the 
qemu-agent service in the guest?

 
PS. I couldn't find the result. Afaik it looks like it is returning the 
amount of frozen/thawed filesystem's

-----Original Message-----
Cc: libvirt-users
Subject: Re: guest-fsfreeze-freeze freezes all mounted block devices

On Fri, Feb 14, 2020 at 22:14:55 +0100, Marc Roos wrote:
> 
> I wondered if anyone here can confirm that
> 
> virsh qemu-agent-command domain
'{"execute":"guest-fsfreeze-freeze"}'
Note that libvirt implements this directly via 'virsh domfsfreeze'. This
is the corresponding man page entry:

  domfsfreeze domain [[--mountpoint] mountpoint...]
      Freeze mounted filesystems within a running domain to prepare for 
consistent snapshots.

      The --mountpoint option takes a parameter mountpoint, which is a 
mount point path of the filesystem to be frozen.
      This option can occur multiple times. If this is not specified, 
every mounted filesystem is frozen.

> Freezes all mounted block devices filesystems. So if I use 4 block 
> devices they are all frozen for snapshotting. Or just the root fs?
Since you are using agent passthrough where libvirt doesn't do any 
interpretation of what happens please refer to the appropriate QEMU 
agent documentation for the semantics of the command you've used.

On Mon, Feb 17, 2020 at 10:03:27 +0100, Marc Roos wrote:
> Hi Peter,
> 
> Should I assume that the virsh domfsfreeze, does not require the 
> qemu-agent service in the guest?
No. That's the official way how to drive the
"guest-fsfreeze-freeze"
agent command via libvirt, thus you must have the guest agent the same
way as you used it before.

Using qemu-agent-command is a backdoor for testing arbitrary commands
and thus you can break things. You are on your own if stuff breaks using
that approach.
> PS. I couldn't find the result. Afaik it looks like it is returning the
> amount of frozen/thawed filesystem's
qemu.git/gqa/qapi-schema.json says:

##
# @guest-fsfreeze-freeze:
#
# Sync and freeze all freezable, local guest filesystems. If this
# command succeeded, you may call @guest-fsfreeze-thaw later to
# unfreeze.
#
# Note: On Windows, the command is implemented with the help of a
# Volume Shadow-copy Service DLL helper. The frozen state is limited
# for up to 10 seconds by VSS.
#
# Returns: Number of file systems currently frozen. On error, all filesystems
# will be thawed. If no filesystems are frozen as a result of this call,
# then @guest-fsfreeze-status will remain "thawed" and calling
# @guest-fsfreeze-thaw is not necessary.
#
# Since: 0.15.0

You might also want to have a look at 'guest-fsfreeze-freeze-list'.

> 
> -----Original Message-----
> Cc: libvirt-users
> Subject: Re: guest-fsfreeze-freeze freezes all mounted block devices
> 
> On Fri, Feb 14, 2020 at 22:14:55 +0100, Marc Roos wrote:
> > 
> > I wondered if anyone here can confirm that
> > 
> > virsh qemu-agent-command domain
'{"execute":"guest-fsfreeze-freeze"}'
> 
> Note that libvirt implements this directly via 'virsh domfsfreeze'.
This
> is the corresponding man page entry:
> 
>   domfsfreeze domain [[--mountpoint] mountpoint...]
>       Freeze mounted filesystems within a running domain to prepare for 
> consistent snapshots.
> 
>       The --mountpoint option takes a parameter mountpoint, which is a 
> mount point path of the filesystem to be frozen.
>       This option can occur multiple times. If this is not specified, 
> every mounted filesystem is frozen.
> 
> 
> > Freezes all mounted block devices filesystems. So if I use 4 block 
> > devices they are all frozen for snapshotting. Or just the root fs?
As a side note. For snapshotting via virsh snapshot-create use the
--quiesce option which does what you want or the virsh command with
arguments if you don't want to freeze everything.
> 
> Since you are using agent passthrough where libvirt doesn't do any 
> interpretation of what happens please refer to the appropriate QEMU 
> agent documentation for the semantics of the command you've used.
> 
> 
>

Hmmm, using 'virsh domfsinfo testdom' gives me a crash in win2008r2 
(using software from virtio-win-0.1.171.iso)

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: qemu-ga.exe
P2: 100.0.0.0
P3: 5c473543
P4: KERNELBASE.dll
P5: 6.1.7601.24545
P6: 5e0eb6bd
P7: c0000005
P8: 000000000000c4d2
P9: 
P10: 

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_qemu-ga.exe_bd
2e6535bdb93328680e0285e89e08f2866db83_0b0deada

Analysis symbol: 
Rechecking for solution: 0
Report Id: 3d82596e-517c-11ea-b213-525400e83365
Report Status: 0


-----Original Message-----
Cc: libvirt-users
Subject: Re: guest-fsfreeze-freeze freezes all mounted block devices

On Mon, Feb 17, 2020 at 10:03:27 +0100, Marc Roos wrote:
> Hi Peter,
> 
> Should I assume that the virsh domfsfreeze, does not require the 
> qemu-agent service in the guest?
No. That's the official way how to drive the
"guest-fsfreeze-freeze"
agent command via libvirt, thus you must have the guest agent the same 
way as you used it before.

Using qemu-agent-command is a backdoor for testing arbitrary commands 
and thus you can break things. You are on your own if stuff breaks using 
that approach.
> PS. I couldn't find the result. Afaik it looks like it is returning 
> the amount of frozen/thawed filesystem's
qemu.git/gqa/qapi-schema.json says:

##
# @guest-fsfreeze-freeze:
#
# Sync and freeze all freezable, local guest filesystems. If this # 
command succeeded, you may call @guest-fsfreeze-thaw later to # 
unfreeze.
#
# Note: On Windows, the command is implemented with the help of a # 
Volume Shadow-copy Service DLL helper. The frozen state is limited # for 
up to 10 seconds by VSS.
#
# Returns: Number of file systems currently frozen. On error, all 
filesystems # will be thawed. If no filesystems are frozen as a result 
of this call, # then @guest-fsfreeze-status will remain "thawed" and 
calling # @guest-fsfreeze-thaw is not necessary.
#
# Since: 0.15.0

You might also want to have a look at 'guest-fsfreeze-freeze-list'.

> 
> -----Original Message-----
> Cc: libvirt-users
> Subject: Re: guest-fsfreeze-freeze freezes all mounted block devices
> 
> On Fri, Feb 14, 2020 at 22:14:55 +0100, Marc Roos wrote:
> > 
> > I wondered if anyone here can confirm that
> > 
> > virsh qemu-agent-command domain 
'{"execute":"guest-fsfreeze-freeze"}'
> 
> Note that libvirt implements this directly via 'virsh domfsfreeze'.
> This is the corresponding man page entry:
> 
>   domfsfreeze domain [[--mountpoint] mountpoint...]
>       Freeze mounted filesystems within a running domain to prepare 
> for consistent snapshots.
> 
>       The --mountpoint option takes a parameter mountpoint, which is a 
> mount point path of the filesystem to be frozen.
>       This option can occur multiple times. If this is not specified, 
> every mounted filesystem is frozen.
> 
> 
> > Freezes all mounted block devices filesystems. So if I use 4 block 
> > devices they are all frozen for snapshotting. Or just the root fs?
As a side note. For snapshotting via virsh snapshot-create use the 
--quiesce option which does what you want or the virsh command with 
arguments if you don't want to freeze everything.
> 
> Since you are using agent passthrough where libvirt doesn't do any 
> interpretation of what happens please refer to the appropriate QEMU 
> agent documentation for the semantics of the command you've used.
> 
> 
>