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 12E911FF164 for <inbox@lore.proxmox.com>; Fri, 31 Jan 2025 11:38:21 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F273429C54; Fri, 31 Jan 2025 11:38:16 +0100 (CET) From: Daniel Herzig <d.herzig@proxmox.com> To: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <5091fb7e-b77c-4b0e-80dc-b88284513811@proxmox.com> (Fiona Ebner's message of "Fri, 31 Jan 2025 10:36:24 +0100") References: <20250130113121.157273-1-d.herzig@proxmox.com> <5091fb7e-b77c-4b0e-80dc-b88284513811@proxmox.com> Date: Fri, 31 Jan 2025 11:38:08 +0100 Message-ID: <87tt9f5kvj.fsf@proxmox.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.337 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH qemu-server v3 0/6] bugzilla #4225 -- improve handling of unavailable 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 30.01.25 um 12:31 schrieb Daniel Herzig: >> This patch series addresses bugzilla entry #4225. >> >> Currently VMs refuse to to start if a configured isofile becomes unavailable, >> be it a deleted file or an unavailable network storage. >> >> This patch series introduces a new parameter in Drive.pm, called 'essential'. >> Depending on whether this parameter is set or not, the situation will be handled >> differently. >> >> If the parameter is set to 0, the configuration will temporarily changed to use >> 'none' as file for the cd drive, which allows qemu to start up the machine. >> The configuration is not changed in this process to avoid unexpected behaviour. >> Instead a log_warn will be issued. >> >> For transition reasons an unset parameter acts like 'required=1'. In this case >> the startup process will die earlier than currently, if the file is missing or >> the underlying storage not available. > > Since you use the word "transition", is there a plan to change the > default behavior at some point? IMHO that requires more rationale > (especially in the backend). > I just used this phrasing to underline that the option 'essential', if pro-actively set to 0, will change current behaviour. Without intervention, people should not notice any difference to current behaviour with the changes from these patches. Except the startup error additionaly listing the file, that's triggering the contact to a non-available network share. I might have a slight preference to not see ISOs as essential files after a successful installation indeed, but there certainly are setups, where it does not make sense to attempt starting up a machine (or let the attempt fail) without an available ISO attached to the VM. I'm eg thinking about ephemeral VMs running from live-ISOs or the like. >> >> If a new VM is created from the WebGUI, a corresponding added checkbox >> is checked by default, but allows for convenient unchecking during setup time, >> eg for media that is only needed for installation time. >> >> This patch series adds an 'Eject' button to the hardwareview in the WebGUI, >> which can be used as a convenience shortcut to setting file to 'none' for the >> cdrom drive. >> >> This series supersedes: >> https://lore.proxmox.com/pve-devel/20250113085608.99498-1-d.herzig@proxmox.com/ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel