From: Fiona Ebner <f.ebner@proxmox.com>
To: Daniel Herzig <d.herzig@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server v3 2/6] fix #4225: qemuserver: introduce sub eject_nonrequired_isos
Date: Mon, 3 Feb 2025 14:09:51 +0100 [thread overview]
Message-ID: <0d45641e-2df1-44ed-b5b6-3e384d4b0f8e@proxmox.com> (raw)
In-Reply-To: <877c67l4gd.fsf@proxmox.com>
Am 03.02.25 um 11:15 schrieb Daniel Herzig:
> Fiona Ebner <f.ebner@proxmox.com> writes:
>
>> Am 31.01.25 um 14:58 schrieb Daniel Herzig:
>>> Fiona Ebner <f.ebner@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/
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-02-03 13:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-30 11:31 [pve-devel] [PATCH qemu-server v3 0/6] bugzilla #4225 -- improve handling of unavailable ISOs Daniel Herzig
2025-01-30 11:31 ` [pve-devel] [PATCH qemu-server v3 1/6] fix #4225: qemuserver: drive: add parameter to mark drive required Daniel Herzig
2025-01-31 9:36 ` Fiona Ebner
2025-01-31 11:09 ` Daniel Herzig
2025-01-30 11:31 ` [pve-devel] [PATCH qemu-server v3 2/6] fix #4225: qemuserver: introduce sub eject_nonrequired_isos Daniel Herzig
2025-01-31 9:36 ` Fiona Ebner
2025-01-31 9:52 ` Fiona Ebner
2025-01-31 13:58 ` Daniel Herzig
2025-02-03 9:00 ` Fiona Ebner
2025-02-03 10:15 ` Daniel Herzig
2025-02-03 13:09 ` Fiona Ebner [this message]
2025-02-03 13:12 ` Fiona Ebner
2025-01-30 11:31 ` [pve-devel] [PATCH qemu-server v3 3/6] fix #4225: qemuserver, test: put eject_nonrequired_isos in place Daniel Herzig
2025-01-31 9:36 ` Fiona Ebner
2025-01-30 11:31 ` [pve-devel] [PATCH pve-manager v3 4/6] fix #4225: ui: form: isoselector: add checkbox for 'essential' param Daniel Herzig
2025-01-30 11:31 ` [pve-devel] [PATCH pve-manager v3 5/6] fix #4225: ui: qemu: cdedit: enable 'Essential' checkbox for isos Daniel Herzig
2025-01-30 11:31 ` [pve-devel] [PATCH pve-manager v3 6/6] fix #4225: ui: qemu: hardware: add eject button for cdroms Daniel Herzig
2025-01-31 9:36 ` [pve-devel] [PATCH qemu-server v3 0/6] bugzilla #4225 -- improve handling of unavailable ISOs Fiona Ebner
2025-01-31 10:38 ` Daniel Herzig
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=0d45641e-2df1-44ed-b5b6-3e384d4b0f8e@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.herzig@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal