public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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


  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