From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <s.reiter@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7F85C62DCC for <pve-devel@lists.proxmox.com>; Thu, 1 Oct 2020 14:12:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 71B602121E for <pve-devel@lists.proxmox.com>; Thu, 1 Oct 2020 14:12:16 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id D171A21210 for <pve-devel@lists.proxmox.com>; Thu, 1 Oct 2020 14:12:15 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8E3F345B67 for <pve-devel@lists.proxmox.com>; Thu, 1 Oct 2020 14:12:15 +0200 (CEST) To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20200924141142.15842-1-s.reiter@proxmox.com> <b976aeee-38fe-4538-30cb-1f30743bd728@proxmox.com> From: Stefan Reiter <s.reiter@proxmox.com> Message-ID: <809d7c17-4d87-3c84-9c42-342697f1ab16@proxmox.com> Date: Thu, 1 Oct 2020 14:12:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <b976aeee-38fe-4538-30cb-1f30743bd728@proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.044 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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 1/2] fix #3010: add 'bootorder' parameter for better control of boot devices 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> X-List-Received-Date: Thu, 01 Oct 2020 12:12:16 -0000 On 9/28/20 2:18 PM, Thomas Lamprecht wrote: > On 24.09.20 16:11, Stefan Reiter wrote: >> (also fixes #3011) >> >> Deprecates the old 'boot' and 'bootdisk' options (they still work the >> same, but will get removed if a user sets a 'bootorder' parameter and >> ignored if both are set). > > I'd rather re-use boot instead of adding a new property. > > Move the current boot format out into it's own format definition, and > change it to a formatsting key=value list with the old format as default_key > for backward compatibillity. The new stuff can be added as new format there, > e.g., "order=<boot-order-list>". > Makes sense, I'll change it. >> >> This allows a user to specify more than one disk in the boot order, >> helping with newer versions of SeaBIOS/OVMF where disks without a >> bootindex won't be initialized at all (breaks soft-raid and some LVM >> setups). >> >> This also allows specifying a bootindex for USB and hostpci devices, >> which was not possible before. Floppy boot support is not supported in >> the new model, but I doubt that will be a problem (AFAICT we can't even >> attach floppy disks to a VM?). >> >> Default behaviour is intended to stay the same, i.e. while new VMs will >> receive the new 'bootorder' property, it will be set so the VM starts >> the same as before (see get_default_bootorder). > > We probably want to add a boot and/or bootorder config2cmd test before > this patch, helps to guarantee that. > Existing tests already check 'bootdisk' property, but I'll add one for 'boot' too. >> >> The API is updated to handle the deprecation correctly, i.e. when >> updating the 'bootorder' attribute, the old properties are removed >> (would now be useless). When removing a device that is in the bootorder >> list, it will be removed from the aforementioned. Note that non-existing >> devices in the list will not cause an error - they will simply be >> ignored - but it's still nice to not have them in there. > > But you do not always rewrite it to the new format, i.e., if just another, > unrelated, config property changed, or? > No, only when bootorder is added (or order= is modified in new version then). I'll also split it into multiple patches.