From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH manager] fix #7229: refresh pmxcfs infos between guest bulk actions
Date: Fri, 16 Jan 2026 11:44:47 +0100 [thread overview]
Message-ID: <20260116104537.294443-1-f.gruenbichler@proxmox.com> (raw)
lifecycle changes in guests can trigger hookscript invocations which
in turn might affect configuration files like storage.cfg. since the
bulk action endpoints invoke API handlers directly, any cfs-registered
config files accessed by those handlers before forking off the task
worker are cached for the whole duration of the bulk endpoint
execution, which usually spans multiple guests. to allow potential
changes made by the hookscript invocation of guest A to be visible
when executing the bulk action for a (later) guest B, a call to
cfs_update needs to be made to invalidate the cache (if needed).
the originally reported issue was a bulk start via pve-guests.service,
with one VM providing a storage combined with a hookscript that
enables/disables the storage entry on start/stop of the VM. without
this fix, the storage entry is still visible as disabled for
subsequent guest starts in the same startall invocation, despite
storage.cfg being updated by the hookscript to reflect that the
storage is in fact available after the VM in question has been
started. the same issue exists for the other bulk actions (stop,
suspend, migrate) as well.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
---
PVE/API2/Nodes.pm | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm
index 6a6465b6b..5bd6fe492 100644
--- a/PVE/API2/Nodes.pm
+++ b/PVE/API2/Nodes.pm
@@ -2126,6 +2126,7 @@ __PACKAGE__->register_method({
my $d = $vmlist->{$vmid};
PVE::Cluster::check_cfs_quorum(); # abort when we loose quorum
+ PVE::Cluster::cfs_update(); # ensure modifications by hookscripts are visible
eval {
my $default_delay = 0;
@@ -2296,6 +2297,9 @@ __PACKAGE__->register_method({
};
for my $vmid (sort { $b <=> $a } keys %$vmlist) {
+
+ PVE::Cluster::cfs_update(); # ensure modifications by hookscripts are visible
+
my $d = $vmlist->{$vmid};
my $timeout = int($d->{down} // $param->{timeout} // 180);
my $upid = eval {
@@ -2431,6 +2435,8 @@ __PACKAGE__->register_method({
};
for my $vmid (sort { $b <=> $a } keys %$vmlist) {
+ PVE::Cluster::cfs_update(); # ensure modifications by hookscripts are visible
+
my $d = $vmlist->{$vmid};
if ($d->{type} ne 'qemu') {
log_warn("skipping $vmid, only VMs can be suspended");
@@ -2636,6 +2642,8 @@ __PACKAGE__->register_method({
my $workers = {};
my $workers_started = 0;
foreach my $vmid (sort keys %$vmlist) {
+ PVE::Cluster::cfs_update(); # ensure modifications by hookscripts are visible
+
my $d = $vmlist->{$vmid};
my $pid;
eval {
--
2.47.3
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
reply other threads:[~2026-01-16 10:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260116104537.294443-1-f.gruenbichler@proxmox.com \
--to=f.gruenbichler@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