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 AECE974EC1 for ; Fri, 4 Jun 2021 09:53:19 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A7AB21A1A9 for ; Fri, 4 Jun 2021 09:52:49 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 3586E1A18D for ; Fri, 4 Jun 2021 09:52:46 +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 15FD242237 for ; Fri, 4 Jun 2021 09:52:46 +0200 (CEST) Message-ID: Date: Fri, 4 Jun 2021 09:52:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Proxmox VE development discussion , aderumier@odiso.com, pve-devel References: <2f9496ebbe77d7c740bf9ef62b9119a1ac583abe.camel@odiso.com> From: Thomas Lamprecht In-Reply-To: <2f9496ebbe77d7c740bf9ef62b9119a1ac583abe.camel@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.318 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.603 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] training week: students feedback/requests 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: Fri, 04 Jun 2021 07:53:19 -0000 Hi, On 04.06.21 05:21, aderumier@odiso.com wrote: > Hi, > I just finish the last training week session, > here some students feedback/requesst: thanks for your feedback! > - add support for vm offlline vm migration with local usb or pci > devices. > 1 student have same special device on multiple hosts, and want to be > able to offline move vm when it need to do maintenance. > It's currently possible with HA anyway. Sounds reasonable, IIRC, allowing it in HA was a result from some bug entry where user had also identical GPUs reserved for the recovery case. > - allow vm migration with local storage cloud-init drive. > Without need to replicate it, I think it could be pretty easy to > regenerate cloud-init drive on target host if same local storage name > exist on target. Yeah, sync or regeneration should both work from PVE side, wolfgang had some objections for the regeneration of CI drives, it could be a bit unexpected for a guest process having that open, IMO they should just handle that. Do you have any experience of issues with regeneration in practice? > > - allow vm online vm migration for specific usb devices. > Maybe a little bit more complex, user have special usb devices (googl > coral usb tensorflow accelerator) on multiple host. > I think it could be possible to unplug device before migration, and > rattach it afte migration. (The application running inside th vm is > able to handle this). > So maybe adding an option on usb device like "allow migrate" could be > enough ? funnily we'd have a use case for that too (some HSM). It'd like to see some USB plug improvements in general anyway, i.e., allowing one to add new USB hubs so that the rather low current limit could be exceeded. This and the PCI one would need some extra checking on the target node, i.e., some basic "all local HW the VM config refers too present?" to make it a bit nicer. > > - be able to move vms from a dead node. > Currently the only was is to move manually the vms config files. > Maybe adding a special wizard, only for root, with a lot of warning, > could be great. > Can be pretty dangerous, but I do not really want to object that completely, in the end the Admin needs to be the one knowing if it is safe, and we want to reduce the steps where one needs to switch to the CLI, so yeah, we could add this with great care about how to present this somewhat safely. > > - Backups: add some kind of lock/queues when you are doing a single > schedule of "vzdump -all .." > Currently, it's launch vzdump on all nodes at the same time. > If user have a lot of nodes, it can easily flood the backup storage, or > backup storage network. > it could be great to be able to define something like: "the backup > storage is able to handle X backups jobs in parallel" > Would need some thoughts about how to implement this fitting good in the existing stack, but yes, we heard that one a few times already, and seems definetively like a sensible request. > > - vm start order: be able to add vms dependencies, > like a vm2 need to wait that vm1 is started (and if > guest agent is used, wait that agent is running, to be sure that vm1 is > fully booted) Hmm, how do you check the "fully" booted case though? Also, wait for ever if the dependent VM is on another node which is currently offline? A manual start would probably need to allow overriding such ordering too, I guess. > > > Gui: > > - Displaying nodes versions in the datacenter sumarry node list. sounds sensible, I'd like to have a panel there with update/repo status of all nodes anyway, to have a more central view about pending or not-configured updates. > - In vms notes: if user add an http://... link, display it as link to > be clickable I checked out a few small markdown JS libraries in the pase, as that was also requested at least once, but just doing simple link https? detection and wrapping them in tags could be enough for most as a starter. > > - add saml authentification > You may have seen that there's some effort going on in that space thanks to Julien BLAIS, the biggest (or basically single) blocker is which SAML lib. to use, the pure perl thing uses the perl MOOSE framework which is huge and IIRC incompatible with the lib-anyevent we use, the rust versions seem not really active, having a rust one, in combination with perlmod to create perl bindings would be great, as then all products could use the same base. cheers, Thomas