From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id B20E51FF168 for ; Tue, 7 Jan 2025 21:28:59 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F3783CCA4; Tue, 7 Jan 2025 21:28:45 +0100 (CET) Date: Tue, 7 Jan 2025 12:28:20 -0800 To: pve-devel@lists.proxmox.com MIME-Version: 1.0 Message-ID: List-Id: Proxmox VE development discussion List-Post: From: John Byrd via pve-devel Precedence: list Cc: John Byrd X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: , List-Unsubscribe: , List-Archive: Reply-To: johnwbyrd@gmail.com, Proxmox VE development discussion List-Help: Subject: [pve-devel] Feature concept: "demanding" qemu vms Content-Type: multipart/mixed; boundary="===============7227464696815403336==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" --===============7227464696815403336== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.proxmox.com 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 9FF83CAD0F for ; Tue, 7 Jan 2025 21:28:43 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 89509CC91 for ; Tue, 7 Jan 2025 21:28:43 +0100 (CET) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 for ; Tue, 7 Jan 2025 21:28:39 +0100 (CET) Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e399e904940so19508797276.2 for ; Tue, 07 Jan 2025 12:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736281712; x=1736886512; darn=lists.proxmox.com; h=to:subject:message-id:date:from:reply-to:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=z3cqlzrH1ZDabrYZdKEKT4pi+ZpxWwpR8ZLhscqp+H4=; b=EsSGmgFABwqOEAodFO4kKqP+F1cfh5r+gDjobPk4Bp8ek0o8u0DV+uttmGsbvYaT4d VFo8KqYH2odZVUbra7okM/D9pb0jRIsNKKQkf3/eTuVa7AuxBiVxgf2Seqxm1OlDDVHv LfDdrKbZ24MTt/sMWVcXs+0nnKqSRB4ajZihPOLpNvfX7MPdfbFC2n58x5sep88krCwb mk7Jkg1Ubgen1EuIlJGrrQBF8734BbgYxmyfYpF3tvM/X9utLn82K8UDrCAp72x+R/l8 ssLdpD1p8zdKz6mRRnnUIJikz+8HFZCCz8V4lCEdM+94uO8fniL4rr1xxMhWaRkQRRKO 7GsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736281712; x=1736886512; h=to:subject:message-id:date:from:reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=z3cqlzrH1ZDabrYZdKEKT4pi+ZpxWwpR8ZLhscqp+H4=; b=QlQgKJMOOYaLqjoBDgjz81HkwbRSIHgZ3iGuI0/BKF3XTGeahYX3fDzzjzOSUDyde1 YXs+TZOtJi1vSfAZxHtFtFam1RsPVdr2VnHhEDFLPqe/PdNhhDJ+o+L746/4BuLd/e2J GaY2xYHsSGldQ4wMX8RRTpWS4KGLbygb//snUIjDLA8hPE8Ujvg6j40EMOGfh7I84/EY +qFr/J6XCKDK56Aw5Y6ordwxKIlNFskc0qAdCnV1/VTVkpOTZzuwa157YnmYkSYJkfFn pw90uILGEcnhbeyVE/2EnRC8usCMGcVDFf5FV/VJg3dcjNLy2+cOtGJRi6le67lQzU9b F0EQ== X-Gm-Message-State: AOJu0YyWu6V6o7gATROoXqg4V4JEpA54yTHXe2+41zO3mOL91zwqvC8y Lm8L+Sttm/zaWOITVVF/nFYoE9i+m1jA6Q4bplrV7LUaXTMK/oH+i/UpR5ipUQ5KOrZVybmEqG4 AWqSndy3A7VMLuR6vwK+1vqsjhXMLx04X X-Gm-Gg: ASbGncsgnDjMbrnLPjquLrjuv3bJIER/CMJ68JuvhclR0eRpTrZz9QJXlS5iyXvU2MF 8o8I/NAS31JkL7KmAd8fQmZZLsbY+IK29TA== X-Google-Smtp-Source: AGHT+IH0SXspZKtq+e5fP6Rl7VUwhS1MjE9ADDXjHTRT3uMw421XvymVgMktiXb7+gr8Hth6zvqwsjQWcwjVwtOfwtk= X-Received: by 2002:a05:690c:9c02:b0:6ef:6f24:d093 with SMTP id 00721157ae682-6f5311f86dcmr3933657b3.6.1736281712201; Tue, 07 Jan 2025 12:28:32 -0800 (PST) MIME-Version: 1.0 Reply-To: johnwbyrd@gmail.com From: John Byrd Date: Tue, 7 Jan 2025 12:28:20 -0800 X-Gm-Features: AbW1kvZhtu7rgba54BMxx5b4XmC4RuAYt_zXFf4D8GwgYXlTRn0cJhMd3lcbT6Q Message-ID: Subject: Feature concept: "demanding" qemu vms To: pve-devel@lists.proxmox.com Content-Type: text/plain; charset="UTF-8" X-SPAM-LEVEL: Spam detection results: 0 BAYES_50 0.8 Bayes spam probability is 40 to 60% 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 DMARC_PASS -0.1 DMARC pass policy FREEMAIL_FROM 0.001 Sender email is commonly abused enduser mail provider 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 Greetings pve-devel, I'm a long-time user and fan and Perl hacker. I use Proxmox as my hypervisor and daily driver on a workstation-class PC, with a high-end Nvidia PCI card attached via PCI passthrough, keyboard, mouse, and a couple other USB peripherals. For development purposes, I need to switch occasionally between the virtual machine that has control of the display and the USB input devices. In other to do this, I have to manually shut down the VM that controls these devices, manually reassign them to a different VM, and then bring that VM back up. It strikes me that we could mark a particular qemu instance as "demanding." In this case, demanding would imply that the VM would, before turning on, verify that all its PCI and USB resources were available and ready for use. If not, the demanding instance would gracefully shut down other instances that are currently using the PCI and USB devices, release them from their current owners, and reassign them to the demanding VM, before turning it on. Consider for a moment what this feature implies. Functionally, it means that Proxmox could replace dual-booting PC workstations with multiple operating systems, with no chance whatsoever that the operating systems would conflict. The user experience would be the same as dual booting -- all your USB devices and graphics cards would work the same as if your OS were installed on metal. And, Proxmox takes care of the complexity of switching the local USB and PCI devices when you change between "demanding" virtual machines. Anyway, it would save me some pain to go ahead and implement this feature in some form, just for myself. And I think that Proxmox's scripting interface would be sufficient to do this without integration with the Proxmox API or UI. However, it strikes me that such a feature might be useful to a lot of people, so I figured I'd ask here before I ran off and wrote the code to do it. 1. Do you think such a feature would be useful to a lot of people? 2. What approach would you use to implement such a feature as an integral part of the core functionality of the Proxmox API and UI? 3. What approach would you use to implement such a feature as a non-integral part of the API and UI? Many thanks for your wisdom and insights. If I can get some good advice, I will follow it in implementing this feature, as per the developer documentation and submission guidelines. Your devoted fan, John Byrd www.johnbyrd.com --===============7227464696815403336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============7227464696815403336==--