From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Mira Limbeck <m.limbeck@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 07/11] agent: implement fsfreeze helper to better handle lost commands
Date: Mon, 5 May 2025 16:01:11 +0200 [thread overview]
Message-ID: <7630b304-812a-4492-b577-6c6dbc5183b7@proxmox.com> (raw)
In-Reply-To: <6f24bfd3-c1a4-4029-927c-3b9ec2faee11@proxmox.com>
Am 05.05.25 um 15:57 schrieb Mira Limbeck:
> On 5/5/25 14:57, Fiona Ebner wrote:
>> diff --git a/PVE/QemuServer/Agent.pm b/PVE/QemuServer/Agent.pm
>> index 41e615aa..ef36a6a8 100644
>> --- a/PVE/QemuServer/Agent.pm
>> +++ b/PVE/QemuServer/Agent.pm
>> @@ -119,4 +119,55 @@ sub qemu_exec_status {
>> return $res;
>> }
>>
>> +# It can happen that a guest agent command is read, but then the guest agent never sends an answer,
>> +# because the service in the guest is stopped/killed. For example, if a guest reboot happens before
>> +# the command can be successfully executed. This is usually not problematic, but the fsfreeze-freeze
>> +# command has a timeout of 1 hour, so the guest agent socket would be blocked for that amount of
>> +# time, waiting on a command that is not being executed anymore.
>> +#
>> +# Use a lower timeout for the fsfreeze-freeze command, and issue an fsfreeze-status command
>> +# afterwards, which will return immediately if the fsfreeze-freeze command already finished, and
>> +# which will be queued if not. This is used as a proxy to determine whether the fsfreeze-freeze
>> +# command is still running and to check whether it was successful. Like this, the time the socket is
>> +# blocked after a "lost command" is at most 10 minutes.
> With the changed logic it's not so clear at first how long it would wait
> in the worst case. It's still the same 60 minutes as before, just spread
> over the initial fsfreeze command, and then up to 5 iterations of
> fsfreese-status, each with a 10 minute timeout.
>
> Maybe that could be documented in the comment and/or the commit message?
Sure, will add that in v2. The patch intentionally does not change the
time fsfreeze-freeze is allowed to take if it actually runs for that long.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-05-05 14:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 12:57 [pve-devel] [PATCH-SERIES qemu-server 00/11] better handle lost freeze command Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 01/11] agent: drop unused $noerr argument from helpers Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 02/11] api: agent: improve module imports Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 03/11] agent: code style: order module imports according to style guide Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 04/11] agent: avoid dependency on QemuConfig module Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 05/11] qmp client: remove erroneous comment Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 06/11] qmp client: add $noerr argument Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 07/11] agent: implement fsfreeze helper to better handle lost commands Fiona Ebner
2025-05-05 13:57 ` Mira Limbeck
2025-05-05 14:01 ` Fiona Ebner [this message]
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 08/11] agent: avoid use of deprecated check_running() function Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 09/11] agent: move qga_check_running() helper to agent module Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 10/11] agent: prefer usage of get_qga_key() helper Fiona Ebner
2025-05-05 12:57 ` [pve-devel] [PATCH qemu-server 11/11] agent: move guest agent format and parsing to agent module Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7630b304-812a-4492-b577-6c6dbc5183b7@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=m.limbeck@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal