On 2/13/26 12:04 PM, Fabian Grünbichler wrote:
On February 13, 2026 11:52 am, Dominik Csapak wrote:
On 2/13/26 11:47 AM, Fabian Grünbichler wrote:
On January 23, 2026 2:25 pm, Dominik Csapak wrote:
sometimes we may want to call the hookscript with additional parameters
in some phases, e.g. we want to call it for each pci device that was
prepared before starting with the correct uuid or pci id.
Add these new parameters to the environment instead of the positional
parameters of the hookscript, since that is more future proof and we get
a key/value pair instead of just the position.
Signed-off-by: Dominik Csapak <[email protected]>
---
changes from v1:
* use a hash instead of a list for the parameters, and give them to the
hookscript via the environment instead of positional parameters, like
we do for the vzdump hookscript
src/PVE/GuestHelpers.pm | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/PVE/GuestHelpers.pm b/src/PVE/GuestHelpers.pm
index f8d112b..b4122e6 100644
--- a/src/PVE/GuestHelpers.pm
+++ b/src/PVE/GuestHelpers.pm
@@ -115,14 +115,22 @@ sub check_hookscript {
}
sub exec_hookscript {
- my ($conf, $vmid, $phase, $stop_on_error) = @_;
+ my ($conf, $vmid, $phase, $stop_on_error, $params) = @_;
return if !$conf->{hookscript};
+ $params //= {};
+
eval {
my $hookscript = check_hookscript($conf->{hookscript});
die $@ if $@;
+ local %ENV;
+
+ for my $key (keys $params->%*) {
+ $ENV{ uc($key) } = $params->{$key};
this should really have some sort of static prefix, both to avoid
clashes, and to allow the hookscript to find all such parameters (e.g.
for logging purposes) by filtering all set env variables.
PVE_HOOKSCRIPT_PARAM_...
or something similar would do the trick?
yep make sense, but maybe something a bit shorter?
PVE_PARAM_
PVE_HS_PARAM_
PVE_HS_
?
yeah, anything short but specific enough to avoid accidents should be
fine. maybe `PVE_HOOK_` ?
yes, that sounds good to me, thx
i'll send a v3, but i'll wait a bit if the other patches get reviewed
