From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 407111FF0E1 for ; Mon, 13 Jul 2026 10:28:24 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 4CAEB213A7; Mon, 13 Jul 2026 10:28:23 +0200 (CEST) Message-ID: Date: Mon, 13 Jul 2026 10:27:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [RFC] qemu-server: add migration_type=insecure to remote-migrate To: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= , Bogdan Ionescu , "pve-devel@lists.proxmox.com" References: <1777552058.4o39hpnqt6.astroid@yuna.none> Content-Language: en-US From: Fiona Ebner In-Reply-To: <1777552058.4o39hpnqt6.astroid@yuna.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783931253133 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.374 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: DL5MQXNYIWVTXO7QGN3AMW7KXO32UTDK X-Message-ID-Hash: DL5MQXNYIWVTXO7QGN3AMW7KXO32UTDK X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 30.04.26 um 2:38 PM schrieb Fabian Grünbichler: > On April 25, 2026 3:10 am, Bogdan Ionescu wrote: >> >> == Backward compatibility approach == >> >> Rather than bumping WS_TUNNEL_VERSION (which would break >> new-source -> old-target combinations because of the existing >> "$WS_TUNNEL_VERSION > $tunnel->{version}" check), I'd add a >> forward-compatible 'caps' field to the version response. Old sources >> ignore unknown JSON keys; new sources require 'insecure-remote' to be >> present in caps before allowing migration_type=insecure, and otherwise >> fall through to the existing WS-tunneled path with no behavioral >> change. > > what do you think @Fiona? Sorry for the very late response. I think a two-way negotiation is better for the long term. Because with the proposed approach, i.e. "target informs source, source decides what to do", the target cannot directly know whether the source will (be able to) use a certain capability or not and thus the target is not be able to adapt its commandline/handling depending on the capabilities alone. I think there should rather be a dedicated 'capabilities' handler rather than the capabilities being part of the 'version' handler and then: 1. The source sends along the capabilities it wants to use. 2. The target looks at the capabilities and decides which ones it also supports/wants and returns the result to the source. This will be a strict subset of the ones the source sent along. 3. Both source and target know which capabilities are going to be used and can proceed accordingly. Best Regards, Fiona