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 DAABE6AFCB for ; Fri, 26 Mar 2021 17:15:29 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C9F662A7C6 for ; Fri, 26 Mar 2021 17:15:29 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 43DE22A7A9 for ; Fri, 26 Mar 2021 17:15:28 +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 E05A342773; Fri, 26 Mar 2021 17:15:27 +0100 (CET) Date: Fri, 26 Mar 2021 17:15:26 +0100 (CET) From: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= To: Proxmox VE user list , Roland , PVE User List Message-ID: <386108369.821.1616775326688@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev5 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.027 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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-User] offline VM migration node1->node2 with local storage X-BeenThere: pve-user@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE user list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2021 16:15:29 -0000 > Roland hat am 26.03.2021 16:29 geschrieben: > > > Hello, > > to pick up this older one: > > >>On 2/16/20 11:28 AM, Roland @web.de wrote: > >/> why do i need to have the same local storage name when migrating a vm />>/from node1 to node2 in dual-node cluster with local disks ? />>//>>/i'm curious that migration is possible in online state (which is much />>/more complex/challenging task) without a problem, but offline i get />/> "storage is not available on selected target" (because there are />/> differenz zfs pools on both machines) /> > >This is because offline and online migration use two very different > >mechanism. > >AFAIK Qemu NBD is used for online migration and ZFS send->recv is used > >for offline migration. > > i had a closer look on offline-migration, and apparently zfs send->recv is only > being used with ZVOLS, the default for VMs on ZFS. > for normal (qcow/raw...) files on any filesystem (even zfs), pvesm export/import > is being used. > > this is working straightforward and apparently, it seems there is missing > appropriate logic inside proxmox including missing parameterization in the webgui > (and probably error handling etc..) !? > > for example, on the target system i can open a "receiver" like this: > # pvesm import ${TARGETDS}:100/vm-100-disk-0.qcow2 qcow2+size tcp://10.16.37.0/24 -with-snapshots 1 -allow-rename 1 > > where on the source i can send the data like this: > # /sbin/pvesm export ${SOURCEDS}:100/vm-100-disk-0.qcow2 qcow2+size - -with-snapshots 1|mbuffer -O 10.16.37.55:60000 > > so we apparently see, what's being needed exists at the base level... > > >>//>>/i guess there is no real technical hurdle, it just needs to get />>/implemented appropriatley !? /> > >There is a patch in the works to make different target storages possible > >for offline migration. > > has there been any progress on this in the meantime ? for compatible storages and setups (e.g., snapshots/replication impose further restrictions since that is hard to carry across different storage types/formats), --targetstorage should allow both live and offline migration and switching storages in one go. you can provide either a single targetstorage, or mappings of source to target storages, or a combination (which means the single storage is used as fallback for storages for which no explicit mapping exists).