From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@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 4E37F9C43C for <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 10:11:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3092D1CC5E for <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 10:11:16 +0200 (CEST) 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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Tue, 24 Oct 2023 10:11:14 +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 78E7344979; Tue, 24 Oct 2023 10:11:14 +0200 (CEST) Message-ID: <016bd4b8-7502-48fe-9208-a075e8aea02b@proxmox.com> Date: Tue, 24 Oct 2023 10:11:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>, "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "aderumier@odiso.com" <aderumier@odiso.com> References: <20230928144556.2023558-1-aderumier@odiso.com> <20230928144556.2023558-3-aderumier@odiso.com> <5ecfa7d0-4525-5f1e-75a2-a6ae1a93356b@proxmox.com> <dbd02b5443c0b82e14db851d867e2eabf5d0161d.camel@groupe-cyllene.com> <73e0a3a6-f978-ac24-5f6b-16af759ee209@proxmox.com> <e572e2c518cc98cc383fb6a554a1324ed1dd2711.camel@groupe-cyllene.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <e572e2c518cc98cc383fb6a554a1324ed1dd2711.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.085 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 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. [gnu.org] Subject: Re: [pve-devel] [PATCH v4 qemu-server 2/2] remote-migration: add target-cpu && target-reboot params 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: Tue, 24 Oct 2023 08:11:16 -0000 Am 23.10.23 um 20:03 schrieb DERUMIER, Alexandre: > Hi Fiona, > > >>> In case of 'restart' migration, we do want to start the VM anyways, >>> so >>> it's actually better, because we can catch config issues early :) Now >>> that I think about it, can we also just start the target VM in >>> prelaunch >>> mode (instead of incoming migration mode), do the NBD migration, shut >>> down the source VM, stop the NBD server and then resume the target? >>> That >>> would avoid the need to stop and start the target again. And >>> therefore >>> might be quite a bit less downtime. > > > I have done some tests, It's not possible currently to write to the > remote nbd without the --incoming migration flag and only -S > > > > https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05700.html > > > > nbd_add is throwing an error like > > 2023-10-23 18:45:51 [formationkvm1] VM 111 qmp command 'block-export- > add' failed - Permission conflict on node '#block524': permissions > 'write' are both required by an unnamed block device (uses node > '#block524' as 'root' child) and unshared by block device 'drive-scsi0' > (uses node '#block524' as 'root' child). > > > Looking at the qemu code, the are some specific codepath in block when > the incoming flag is setup. > That is unfortunate. But thanks for giving it a shot! I guess if we'd really wanted to go this route, we'd need to add some kind of "empty" migration type without any state, but would be hard to get right and feels like a hack. > > So I think the best way for now is to restart the target vm. > Sure! Going with that is a much cleaner approach then.