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 9BF0174520 for ; Mon, 21 Jun 2021 15:56:37 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3D8D81C488 for ; Mon, 21 Jun 2021 15:55:45 +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 id 1ABAA1C2FA for ; Mon, 21 Jun 2021 15:55:36 +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 E650943062 for ; Mon, 21 Jun 2021 15:55:35 +0200 (CEST) From: Dominik Csapak To: pve-devel@lists.proxmox.com Date: Mon, 21 Jun 2021 15:55:13 +0200 Message-Id: <20210621135534.14807-1-d.csapak@proxmox.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.653 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [PATCH/RFC cluster/common/... many] add cluster-wide hardware device mapping 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, 21 Jun 2021 13:56:37 -0000 this series aims to add a cluster-wide device mapping for (atm) pci and usb devices. so that an admin can configure a device to be availble for migration and configuring for uses that are non-root built-in are some additional safety checks in contrast to current passthrough, e.g. if pci addresses shift, with the mapping we can detect that and prevent a vm to boot with the wrong device (in most cases, there are some edge cases when one has multiple of the same device, e.g. the same gpu, that we cannot detect) all in all the series should be functional, but there are some parts that are not finished/rough: * the config format for now i used a section config with 'hostname:id' as section header, but this is not optimal. after some discussion with several colleagues, i'll probably settle for a config file with pure json in it, since there is no good way to have the necessary nesting level (a mapping per node per id + properties per id) and have it reasonably integrate in the section config, while maintaining ease of use with a normal editor (ideally we would have anoter config format like json with comments/trailing commas, or rust-object-notation) if there are some better ideas, please tell! * node api here the section config helps us, but we have the usual weirdness with all options everytime available. also currently the api is limited to the node level, and i have no good solution for distributing the current state of the devices yet (we can use the pvestatd as usual, but it does so many things already; the rewrite really becomes a blocker for many things) * cluster-wide gui depends on the cluster wide api call for listing, which i omitted for now for the reasons i gave above * vm editing gui not completely happy with the result, but could not come up with something better in the time i had until now * config file location for now it lives in pve-common, though after looking at the dependency chain, it would be possible to move it to qemu-server does not really matter to me, and if we sometime want to extend it to containers it needs to be at least in pve-guest-common * auto-generated roles: i did not find a way to have a 'PVEHardwareUser' role without an 'PVEHardwareAdmin', but the 'Admin' would have the same privs. so i settled on only having an Admin. Not sure if that makes sense.. dependencies: manager depends on qemu-server,pve-access-control,pve-common qemu-server depends on pve-access-control,pve-common pve-common depends on pve-cluster additioanl info: pve-common 1/3 and 2/3 are necssary but could be independetly applied, no breaking change pve-cluster: Dominik Csapak (1): add nodes/hardware-map.conf data/PVE/Cluster.pm | 1 + data/src/status.c | 1 + 2 files changed, 2 insertions(+) pve-common: Dominik Csapak (3): SysFSTools: add verbose flag to pci_device_info SysFSTools: change 'product' to 'device' add PVE/HardwareMap and Plugins src/Makefile | 4 ++ src/PVE/HardwareMap.pm | 54 ++++++++++++++++++++ src/PVE/HardwareMap/PCIPlugin.pm | 87 ++++++++++++++++++++++++++++++++ src/PVE/HardwareMap/Plugin.pm | 82 ++++++++++++++++++++++++++++++ src/PVE/HardwareMap/USBPlugin.pm | 69 +++++++++++++++++++++++++ src/PVE/SysFSTools.pm | 33 +++++++++--- 6 files changed, 323 insertions(+), 6 deletions(-) create mode 100644 src/PVE/HardwareMap.pm create mode 100644 src/PVE/HardwareMap/PCIPlugin.pm create mode 100644 src/PVE/HardwareMap/Plugin.pm create mode 100644 src/PVE/HardwareMap/USBPlugin.pm pve-access-control: Dominik Csapak (2): PVE/AccessControl: add Hardware.* privileges and /hardware/ paths PVE/RPCEnvironment: add helper for checking hw permissions src/PVE/API2/AccessControl.pm | 3 ++- src/PVE/AccessControl.pm | 13 +++++++++++++ src/PVE/RPCEnvironment.pm | 8 ++++++++ 3 files changed, 23 insertions(+), 1 deletion(-) qemu-server: Dominik Csapak (7): PVE/QemuServer: allow mapped usb devices in config PVE/QemuServer: allow mapped pci deviced in config PVE/API2/Qemu: add permission checks for mapped usb devices PVE/API2/Qemu: add permission checks for mapped pci devices PVE/QemuServer: extend 'check_local_resources' for mapped resources PVE/API2/Qemu: migrate preconditions: use new check_local_resources info PVE/QemuMigrate: check for mapped resources on migration PVE/API2/Qemu.pm | 108 ++++++++++++++++++++++++++++++++++++++---- PVE/QemuMigrate.pm | 13 ++++- PVE/QemuServer.pm | 38 ++++++++++++++- PVE/QemuServer/PCI.pm | 22 ++++++++- PVE/QemuServer/USB.pm | 22 ++++++++- 5 files changed, 188 insertions(+), 15 deletions(-) pve-manager: Dominik Csapak (8): PVE/API2/Hardware: add Mapping.pm ui: form/USBSelector: make it more flexible with nodename ui: form: add PCIMapSelector ui: form: add USBMapSelector ui: node: add HardwareView and relevant edit windows ui: qemu/PCIEdit: rework panel to add a mapped configuration ui: qemu/USBEdit: add 'mapped' device case ui: window/Migrate: allow mapped devices PVE/API2/Hardware.pm | 6 + PVE/API2/Hardware/Makefile | 1 + PVE/API2/Hardware/Mapping.pm | 292 +++++++++++++ www/manager6/Makefile | 3 + www/manager6/form/PCIMapSelector.js | 95 +++++ www/manager6/form/USBMapSelector.js | 73 ++++ www/manager6/form/USBSelector.js | 32 +- www/manager6/node/Config.js | 8 + www/manager6/node/HardwareView.js | 641 ++++++++++++++++++++++++++++ www/manager6/qemu/PCIEdit.js | 231 ++++++---- www/manager6/qemu/USBEdit.js | 34 +- www/manager6/window/Migrate.js | 37 +- 12 files changed, 1361 insertions(+), 92 deletions(-) create mode 100644 PVE/API2/Hardware/Mapping.pm create mode 100644 www/manager6/form/PCIMapSelector.js create mode 100644 www/manager6/form/USBMapSelector.js create mode 100644 www/manager6/node/HardwareView.js -- 2.20.1