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 5FD1B99079 for ; Tue, 10 Oct 2023 11:20:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4789830630 for ; Tue, 10 Oct 2023 11:19:49 +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 ; Tue, 10 Oct 2023 11:19:47 +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 8723C4497E; Tue, 10 Oct 2023 11:19:47 +0200 (CEST) Message-ID: <73e0a3a6-f978-ac24-5f6b-16af759ee209@proxmox.com> Date: Tue, 10 Oct 2023 11:19:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Content-Language: en-US To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "aderumier@odiso.com" References: <20230928144556.2023558-1-aderumier@odiso.com> <20230928144556.2023558-3-aderumier@odiso.com> <5ecfa7d0-4525-5f1e-75a2-a6ae1a93356b@proxmox.com> From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.586 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 NICE_REPLY_A -3.339 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] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2023 09:20:19 -0000 Am 09.10.23 um 15:47 schrieb DERUMIER, Alexandre: >>> One could argue that a true 'restart' migration would migrate the >>> volumes also offline, but right now, I don't see a big downside to do >>> it >>> via NBD like in this patch. Still, something we should think about. >>> If >>> it turns out to be really needed, we'd need two different ways to do >>> a >>> restart migration :/ > > I think that a true offline migration (without starting any > source/target vm) can be done with qemu-storage-daemon running nbd > server on target && qemu-img on source. > > This could be also used for online migration with unused/detached > disks. > Yes, we could, but would require additional logic. So the question is if there are enough advantages to do it rather than via a full VM. Starting a VM of course requires more resources. 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. In case of offline migration, it can make sense to go via the storage daemon instead to avoid using more resources than necessary. But can always be added later.