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 3A61A61C83 for ; Sat, 21 Nov 2020 14:09:06 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id EE5911A17F for ; Sat, 21 Nov 2020 14:09:05 +0100 (CET) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 3EB0E1A168 for ; Sat, 21 Nov 2020 14:09:04 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id c9so13581705wml.5 for ; Sat, 21 Nov 2020 05:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=K6o+kkYzwtiHTxGxiwOL+QU5Ivu+nN/nuA8c5fYvESk=; b=Birkl/B5tf+fSGOiArWtKDThKhkr7JxG3KlxOsEx38sTBUvCOM0KUE+9Fxcta4zylZ m/rXsn3zTowMrTnGVE8txhZiE3gu2zB2nltQNSFzBZNGoyKUiugpqmB2h92a9P9IKlGE pXGM9gsrE0CD6rLikey8FP26FAadzYk3k6gV7mM/7L8bj1aoTfMuU7Yox0QAsCwjyuQB fFu3SZpg75UjcrOX7XNdJ3XUNp9Xto0fWmoYgY869oyZCuaUPaoU2u8UgQ2MiJnRI+X6 jC2JrQG+4B8mZ1EUpQNVKKSJHUur0/wD+Pt7Te+Z7F9tiRlqnCD6Z+mXllRQ4AZ7yeB1 Mr6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K6o+kkYzwtiHTxGxiwOL+QU5Ivu+nN/nuA8c5fYvESk=; b=uYjhGBuWShnstpV2VyCuzeAltC/Z6IIDkPnh49XAa9euKul+9z69if/l+ipf5yTr0f 0aR68VJwNuGgJLJmI4FFN0UCFuu+CKtJHgWtt4O/5jZwxn7V0/bwvlBc59y4i+d8fqKO exDiu93B3TKCE4+5x9IKsQCJkcBdIpTSAuqq3titWEaXEk8AnYlI6Go/m6xP/kQIbSOt xU69vKp163b4asKMqmcMPMoir5Voa2i/qBzn3BSwah9tQXnapq6bRZPp+2MmHE2vij94 Yn8wxQzVpFCD4hvIQVgsdpMPE1HZbWqSNmNhJPd45YakeMELfALKjsu9sYNUYTgL1ISs E0Lw== X-Gm-Message-State: AOAM532hcNwoEvsdf4ZC4xNwB5xY2ZvLYG8s/JBFYWAj0qRFnWiCTkOi I/T+8zcyuhfnu3MSgSVvFDqCzr191nw19nnbzhXbzC0WJ/EI5A+N X-Google-Smtp-Source: ABdhPJxdEFRhl/JIAYqbvr5NFikkFKUqgjNw7I+I2cMbcQn7rotJWhcR9fIpyH99+66GafQP8SS64l1bgB9ZG4tHezY= X-Received: by 2002:a1c:c309:: with SMTP id t9mr7387434wmf.149.1605964137754; Sat, 21 Nov 2020 05:08:57 -0800 (PST) MIME-Version: 1.0 From: Pablo Ruiz Date: Sat, 21 Nov 2020 14:08:47 +0100 Message-ID: To: pve-devel@pve.proxmox.com X-SPAM-LEVEL: Spam detection results: 0 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 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: [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: Sat, 21 Nov 2020 13:09:06 -0000 Hi, 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. 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 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 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=$storeid', and uses this pool 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 can avoid this custom plugin in the future? I've posted the custom plugin as a gist: https://gist.github.com/pruiz/5d7fbd75efb413ac15d2d0e3ef54f32a Regards Pablo