From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 B470BF603 for ; Fri, 16 Dec 2022 12:52:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9033321573 for ; Fri, 16 Dec 2022 12:52:11 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 16 Dec 2022 12:52:10 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B46EF448D0 for ; Fri, 16 Dec 2022 12:52:10 +0100 (CET) Message-ID: <6d01e6cf-2a27-c838-98cf-38de45f12a2c@proxmox.com> Date: Fri, 16 Dec 2022 12:52:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Thunderbird/109.0 Content-Language: en-GB To: Proxmox VE development discussion , Fiona Ebner References: <20221202125452.54621-1-f.ebner@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20221202125452.54621-1-f.ebner@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.028 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% 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) 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] [RFC qemu-server] migration: nbd export: switch away from deprecated QMP command X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2022 11:52:11 -0000 On 02/12/2022 13:54, Fiona Ebner wrote: > The 'nbd-server-add' QMP command has been deprecated since QEMU 5.2 in > favor of a more general 'block-export-add'. > > When using 'nbd-server-add', QEMU internally converts the parameters > and calls blk_exp_add() which is also used by 'block-export-add'. It > does one more thing, namely calling nbd_export_set_on_eject_blk() to > auto-remove the export from the server when the backing drive goes > away. But that behavior is not needed in our case, stopping the NBD > server removes the exports anyways. > > It was checked with a debugger that the parameters to blk_exp_add() > are still the same after this change. Well, the block node names are > autogenerated and not consistent across invocations. > > The alternative to using 'query-block' would be specifying a > predictable 'node-name' for our '-drive' commandline. It's not that > difficult for this use case, but in general one needs to be careful > (e.g. it can't be specified for an empty CD drive, but would need to > be set when inserting a CD later). Querying the actual 'node-name' > seemed a bit more future-proof. are there other examples than the CD-Drive, as that one wouldn't be really relevant for us here or? IMO they key disadvantage of switching to computed node-names is the upgrade path, as I'd expect that for running VMs we cannot change them to computed ones and thus we would need to still query (or keep the legacy command) for those...