From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
by lore.proxmox.com (Postfix) with ESMTPS id 9FF871FF16E
for <inbox@lore.proxmox.com>; Mon, 3 Feb 2025 11:15:21 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 433802C541;
Mon, 3 Feb 2025 11:15:20 +0100 (CET)
From: Daniel Herzig <d.herzig@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <6db4da9d-9397-4fb6-bc26-bb26177daa9f@proxmox.com> (Fiona Ebner's
message of "Mon, 3 Feb 2025 10:00:51 +0100")
References: <20250130113121.157273-1-d.herzig@proxmox.com>
<20250130113121.157273-3-d.herzig@proxmox.com>
<6366fe87-8801-4a7c-be5b-31ea4fba166a@proxmox.com>
<15e79d80-7f27-47cd-a92b-f4f0a8ad6ad7@proxmox.com>
<87cyg35bkx.fsf@proxmox.com>
<6db4da9d-9397-4fb6-bc26-bb26177daa9f@proxmox.com>
Date: Mon, 03 Feb 2025 11:15:14 +0100
Message-ID: <877c67l4gd.fsf@proxmox.com>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.320 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH qemu-server v3 2/6] fix #4225: qemuserver:
introduce sub eject_nonrequired_isos
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
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.
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.
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.
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.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel