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 D419D62178 for ; Mon, 23 Nov 2020 08:55:09 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C44A3245EB for ; Mon, 23 Nov 2020 08:54:39 +0100 (CET) Received: from server12.webgo24.de (server12.webgo24.de [185.30.32.12]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id E8BCA245E1 for ; Mon, 23 Nov 2020 08:54:38 +0100 (CET) Received: from straightec.de (unknown [87.122.202.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by server12.webgo24.de (Postfix) with ESMTPSA id 804D8A5414B1 for ; Mon, 23 Nov 2020 08:54:32 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Nov 2020 08:54:27 +0100 Message-ID: <57EF5F8B433A6742AD548ABECE78FE4853930A@hal9001.straightec.lokal> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pve-devel] Allow dynamic pool name discovery on ZFSPoolPlugin Thread-Index: AdbBbYx78uyEmgzZQP2tqQ+G8vnXrgAABslg References: From: =?iso-8859-1?Q?Carsten_H=E4rle?= To: "Proxmox VE development discussion" X-SPAM-LEVEL: Spam detection results: 1 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an 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. [proxmox.com] Subject: Re: [pve-devel] Allow dynamic pool name discovery on ZFSPoolPlugin 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: Mon, 23 Nov 2020 07:55:09 -0000 Why not just rename the ZFS-dataset on the old server with "zfs rename"? Se= ems to be much easier than implementing a separate feature. -----Urspr=FCngliche Nachricht----- Von: pve-devel [mailto:pve-devel-bounces@lists.proxmox.com] Im Auftrag von = Thomas Lamprecht Gesendet: Montag, 23. November 2020 08:50 An: Proxmox VE development discussion; Pablo Ruiz; pve-devel@pve.proxmox.co= m; Fabian Ebner Betreff: Re: [pve-devel] Allow dynamic pool name discovery on ZFSPoolPlugin Hi, On 21.11.20 14:08, Pablo Ruiz wrote: > Hi, >=20 > I've just made a little custom storage plugin which basically > overrides/extends ZFSPoolPluging so the pool name instead of being fixed, > can be 'dynamically' guessed on each cluster node. >=20 > While adding some new nodes to one of our current clusters, due to hardwa= re > differences, we ended up with new nodes having a different zpool's layout > than the already existing nodes. Our existing nodes had a pool named > 'rpool/data' (a dataset nested into system's main pool). While the new > nodes have a dedicated pool (data) independent of 'rpool'. So we needed a > way to have the same storage use different backing zfs pools on each serv= er > (ie. on old servers it should use 'rpool/data', while on newer ones it > should be using 'data'). >=20 > Currently proxmox does not allow overriding an storage.cfg's property > 'per-node'. So we came up with a simple custom plugin which basically loo= ks > up the pool with an attribute like 'pve:id=3D$storeid', and uses this poo= l > obtained dynamically. >=20 > We could have simply added a new store with a different id, but that woul= d > break our orchestration and automatic deployment of machines, and add som= e > additional management issues by having to track the store of each machine= , > specially if/when moving vms around. >=20 > That said, the plugin works, but I think this feature may be of use to > others. Would a patch against upstream ZFSPoolPlugin accepted, so we can > avoid this custom plugin in the future? >=20 > I've posted the custom plugin as a gist: > https://gist.github.com/pruiz/5d7fbd75efb413ac15d2d0e3ef54f32a >=20 thanks for sharing your solution! It's an interesting way to solve this, the thing I do not really like, is that the storage config is now not the only single source of truth for "which pool to use/import" anymore We could actually add a nodename to pool mapping as a property to the ZFS Pool storage config schema instead, that'd would keep this information contained to the configuration and make lookup a bit cheaper. cheers, Thomas _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel