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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 251B2624F7 for ; Mon, 23 Nov 2020 17:34:29 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0F5DA2B45B for ; Mon, 23 Nov 2020 17:34:29 +0100 (CET) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 27F612B445 for ; Mon, 23 Nov 2020 17:34:27 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id e7so1687232wrv.6 for ; Mon, 23 Nov 2020 08:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RojSV7j/gOPiN8Y6yfNCfOn6FRECmp4+7CWl/WKCqHM=; b=fK5iU5+r74QU12KYd39upPdWYgJEQWQirD7thKJ43Nbk1QL5y15jq1LR++PwJuy2jo YlDI+Ie0OzMIrOhCLqVWlF/XAsIrMEmirU/tzyayHxg5k8MO1aYPCKfcx1Ke/6NnzlpT iAwoOprNCE0MSpuyIBc1ITKUk0VJlucfx8ppvn8TORrQxj7UyB4uCjuiDm9TtWs7Be+0 cY60v15FPkaU8LnnPkB5bKKWlW5rQVPbZw8iakFO+WAvnQm4Uzdj4dxyUC8uXjH+ZBjL 8C6O4BJ/0fxBEA1oAt0O4nGNXGdNmTsn9LKLaS9FCnp28xPUJiNVOwX2GecjezjbX4++ dMAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RojSV7j/gOPiN8Y6yfNCfOn6FRECmp4+7CWl/WKCqHM=; b=CdpoLOTOz8yXvrLiWyk5uvg9LN0mrNWu8+GyjQZL3VGrRCcUIPBXySDcC0wVuWkKWh rYYP9B9ILe9c6NiT6y2YEN9wsAClPRoMEhu0cYIHJWWsc/b6S8SMcanFPyTyvmK+GZ7D P2Z/mutXKgBCl6R7/HsUCAD+FRmiRLTpIbFy4c5yj0GkEMvDjvaa90D50EztI3AON8hf gA5JejnkC1hYV7cxnY/nN3nZNFk8YraSjOOZFtyWTkSP74BOb8MpNJ9/hahpwjidsRp9 97xskn4Ob1ujPvMx0LyeZr8ab0BLNeFPehK7/zHE0bvP7y5MOy2EqHzO7c4BvNtNC68Z 66MQ== X-Gm-Message-State: AOAM530n6bXQ31GG6NTDzKv5mFkWd3AP7/BHhvg4s/Hy2oD/81OrV0If H57QLTXHPjjFg/um3aKHyCL8AVMtOwne0ABxvxAz2ZH7bX96gA== X-Google-Smtp-Source: ABdhPJyCoqMfOsge36UEL6RCugLuNvEMroO1gfaP3AsF4/Gf066zlxGhtteNEDHaxGd0xOrgu4e+OXaPC+hytDkFN2k= X-Received: by 2002:a5d:40cd:: with SMTP id b13mr547758wrq.52.1606149260657; Mon, 23 Nov 2020 08:34:20 -0800 (PST) MIME-Version: 1.0 References: <57EF5F8B433A6742AD548ABECE78FE4853930A@hal9001.straightec.lokal> In-Reply-To: <57EF5F8B433A6742AD548ABECE78FE4853930A@hal9001.straightec.lokal> From: Pablo Ruiz Date: Mon, 23 Nov 2020 17:34:09 +0100 Message-ID: To: Proxmox VE development discussion X-SPAM-LEVEL: Spam detection results: 0 AWL -0.600 Adjusted score from AWL reputation of From: address DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain FREEMAIL_FROM 0.001 Sender email is commonly abused enduser mail provider HTML_MESSAGE 0.001 HTML included in message KAM_LINEPADDING 1.2 Spam that tries to get past blank line filters RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust 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. [proxmox.com] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 16:34:29 -0000 Cause the dataset lies at different pools on each server group: - old servers: rpool/data - new servers: newpool/data You can only rename pools (or datasets) within their own. Regards Pablo On Mon, Nov 23, 2020 at 8:55 AM Carsten H=C3=A4rle wrote: > Why not just rename the ZFS-dataset on the old server with "zfs rename"? > Seems to be much easier than implementing a separate feature. > > -----Urspr=C3=BCngliche 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.com; Fabian Ebner > Betreff: Re: [pve-devel] Allow dynamic pool name discovery on ZFSPoolPlug= in > > Hi, > > On 21.11.20 14:08, Pablo Ruiz wrote: > > Hi, > > > > I've just made a little custom storage plugin which basically > > overrides/extends ZFSPoolPluging so the pool name instead of being fixe= d, > > can be 'dynamically' guessed on each cluster node. > > > > While adding some new nodes to one of our current clusters, due to > hardware > > differences, we ended up with new nodes having a different zpool's layo= ut > > 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 > server > > (ie. on old servers it should use 'rpool/data', while on newer ones it > > should be using 'data'). > > > > Currently proxmox does not allow overriding an storage.cfg's property > > 'per-node'. So we came up with a simple custom plugin which basically > looks > > up the pool with an attribute like 'pve:id=3D$storeid', and uses this p= ool > > obtained dynamically. > > > > We could have simply added a new store with a different id, but that > would > > break our orchestration and automatic deployment of machines, and add > some > > additional management issues by having to track the store of each > machine, > > specially if/when moving vms around. > > > > 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 ca= n > > avoid this custom plugin in the future? > > > > I've posted the custom plugin as a gist: > > https://gist.github.com/pruiz/5d7fbd75efb413ac15d2d0e3ef54f32a > > > > 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 informatio= n > 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 > > > > > > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > >