[pve-devel] [PATCH v2 qemu-server 3/3] restore: remove efidisk from config if not backed up

[Thomas Lamprecht]

On 09.07.21 09:11, Fabian Ebner wrote:
> Am 08.07.21 um 13:46 schrieb Stefan Reiter:
>> If it doesn't exist, there's no need to keep it around at all. Such a
>> backup might easily be created if an efidisk is configured with BIOS
>> set to anything but 'OVMF'.
>>
>> Unbreaks live-restore for such cases too.
>>
>> Signed-off-by: Stefan Reiter <s.reiter at proxmox.com>
>> ---
>>
>> v1->v2:
>> * Actually remove efidisk from config, not just from launched version for
>>    live-restore - first, this allows one to restart the VM after the live-restore
>>    is done without errors, and second this way it also applies for normal
>>    restores (no reason to keep an efidisk configured that doesn't exist).
>>    After testing both I think I like this approach better, but feel free to keep
>>    the v1 version too...
>>
>>   PVE/QemuServer.pm | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
>> index 4082e69..9af0ad3 100644
>> --- a/PVE/QemuServer.pm
>> +++ b/PVE/QemuServer.pm
>> @@ -6044,7 +6044,7 @@ my $restore_allocate_devices = sub {
>>   };
>>     sub restore_update_config_line {
>> -    my ($cookie, $map, $line, $unique) = @_;
>> +    my ($cookie, $map, $line, $unique, $rpcenv) = @_;
>>
> 
> General question, because this will pop up often with the new task warnings: should using RPCEnvironment::get() within each function that needs it be preferred over passing it around as a parameter?

Good question I asked myself recently.

FWIW, status quo is that we normally only get the RPCEnv in the API and then pass
it along.

I broke that recently once when adding the better warn for the CT start, but
explicitly made it such that it won't fail if a RPCEnv singleton isn't instantiated,
and I was not too happy with it, is was rather done out of time pressure for the
release.

In general I'd rather try to avoid using side-effects in "pure" methods, that
are only helpers or "bussiness-logic", and try to contain RPCEnv to the API/CLI if
possible. If one would need to add a new $rpcenv param to 3+ methods to chain it
through it may be a sign that there's a general design issue with the approach taken
though.