[pve-devel] [PATCH qemu-server v3 2/6] fix #4225: qemuserver: introduce sub eject_nonrequired_isos

[Fiona Ebner]

Am 03.02.25 um 11:15 schrieb Daniel Herzig:
> Fiona Ebner <f.ebner at proxmox.com> writes:
> 
>> Am 31.01.25 um 14:58 schrieb Daniel Herzig:
>>> Fiona Ebner <f.ebner at proxmox.com> writes:
>>>
>>>> Am 31.01.25 um 10:36 schrieb Fiona Ebner:
>>>>> Am 30.01.25 um 12:31 schrieb Daniel Herzig:
>>>>>> +
>>>>>> +    $drive->{essential} = 1 if !defined($drive->{essential});
>>>>>
>>>>> This should rather be done when parsing the drive.
>>>>
>>>> Or I guess to avoid (potentially) writing it out for every drive, it
>>>> should only be a local variable here and not set in the drive hash.
>>>
>>> Thanks, I'll double check on this for v4. But I'd assume the hash to be scoped to
>>> `config_to_command` here, or am I missing something?
>>>
>>
>> But you don't need the modified version in config_to_command() later,
>> or? And if yes, that can just check the same way again, i.e. using
>> default value if not set. If we want to explicitly set the value, that
>> should happen during parsing the drive string. Most of the time it's
>> surprising to implicitly modify a passed-in value. Better to either
>> avoid that or if really necessary, explicitly mention it in the function
>> description.
> 
> No, I do not need the modified version of the VM-config later.

Yes, but you manipulate the drive hash, which would then get written out
modified. Maybe you are lucky and there is no writer, but I'm telling
you how to avoid that by considering the default on access. E.g. see how
this is done for the 'bios' option, we do not modify the setting but
apply the default when accessing it.

> 
> What I'm trying to achieve is a more 'forgiving' behaviour in the case
> of accidently server-side-deleted iso file/unavailable server (for whatever reason)
> attached to a VM. So this is actually aiming at `qm start`, which
> implicitly calls `config_to_command` -- without modifying the existing
> VM config at all.
> 
> If the parameter 'essential' is set to '0', `config_to_command` would --
> in case of file unavailability of the iso file -- generate a kvm startup
> command that contains "-drive 'if=none,media=cdrom,[...]" instead of
> "-drive 'file=$SOME_PATH_TO_ISO,[..]' when we at this point already know
> that $SOME_PATH_TO_ISO is unavailable/non-existent.

Yes, I understand that.

> 
> The VM-config itself is not changed, as an eg nfs-server might come back
> at a point in time later and the user might want to do something with the iso
> stored there.

This is problematic for live migration, see my initial reply. Either we
need to drop the CD from the config or we need another option "missing"
that gets set if it is missing during start-up (and cleared if it is
there during startup). Then the target of migration can also know about
it when starting its own instance of the VM. We could also do this via a
special section in the configuration, see the following series[0] since
this would be internal-only information.

> 
> If the parameter 'essential' is unset, or set to '1', the die would
> happen before `qm start` leads to an invocation of kvm, as it cannot be
> expected to lead to a successful action, if $SOME_PATH_TO_ISO is not
> reachable. This would be the exact behaviour as we have it now, just not
> letting kvm run into this situation, but detect and exit earlier, while
> `config_to_commands` iterates over all volumes via `foreach_volume`
> anyway before producing the 'final' kvm command.
> 

Right, you also modify the config itself. But you cannot rely on nobody
else later writing the config. Just because it doesn't happen right now
in the tested code paths, it doesn't mean it never will. (There can be
safe-guards [1] if we really want to ensure this). But I'd either simply
have the function return which devices should not be added later, or
explicitly write out the modified config.

Because doing config modifications implicitly is error prone and future
changes can easily activate bugs lurking in that implicit behavior.

[0]:
https://lore.proxmox.com/pve-devel/20250127112923.31703-10-f.ebner@proxmox.com/
[1]:
https://lore.proxmox.com/pve-devel/20250124105351.43428-3-f.ebner@proxmox.com/