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 2C2B470684 for ; Mon, 7 Jun 2021 10:16:21 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1222AE66C for ; Mon, 7 Jun 2021 10:15:51 +0200 (CEST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 C282EE647 for ; Mon, 7 Jun 2021 10:15:46 +0200 (CEST) Received: by mail-wm1-x336.google.com with SMTP id o127so9410186wmo.4 for ; Mon, 07 Jun 2021 01:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=odiso-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version; bh=8S1BmikgMpIQq7CqcaZ9X6t9vVfcxTAJkDTKbOQRwxk=; b=jHh3eKBSXzch0PtYNimdRMdZP+aPE91F48pKN7UMzYTAymt0IIiIlrfVk5g5367urp NlRKTv6xt8HL1l0j/GzdL39FxpGIP4vDl7mqGiu3GIG3rd6sSNjQM114jBYg23UTfBrf Igd3oh3L6cG1wc7y1gHBWXxSCGOFFvPYdC0lCVjbdufEkLdf9BunGcNApp2lMI6i3LHm HFYL7Tmn4HyLb/H0EworxZ4K2Pu0OAsjTAQerKksA9abxbq/Ndt0SWOlR8fpDlls/zdt +krczVCljn2uZdBAI+TLjtrqJGuhtPgkSFqmBFzZOqW4tMBVVHxlcYSF2b50nz37a56E o9gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=8S1BmikgMpIQq7CqcaZ9X6t9vVfcxTAJkDTKbOQRwxk=; b=hvJydL6FZfTJTW9wyROe+GC0veIvzH679n5zAUz25Ac73CmuWSfcsVVfulCUjjT/4J UPbu3g9IN3gbLVeVsYJS4Zg1tvVGu9NbzXnNOHrVfr6Yfjs6GJ8WLtNBEC1zsvTIIHk8 ANsVSzamZUZw+JQLEjyKsMWPa7kVuJVVCqhthtEMVkgelmlINQkqthNlOldvSpe2qGvb 6fF5DqoxrXSre78+qyaE0XvUvuhCGaaxAhoZaIBKAnRpqai5tlnVOkB3XLALIQrIXOlz OdYNNoZl0iXn/0GjUlcDwGRUiSJaJvLIZxISt5yblkBmxkkcDjYd44Mxi6I/WaDo4HEr 39BQ== X-Gm-Message-State: AOAM531kXarD8DkP2SutMRQ717QC7KLxOxhJOvzvmt24A8W5g8fc7N/4 Vt2rqKPWKpPaXU6KECSsp2rRsg== X-Google-Smtp-Source: ABdhPJxNwqoqONsjc2LclFKGcSKOsTDCAU5vzd8Ns0PmgrKKVraTxCaXShyfXOukWMmbiyGfgJkDYQ== X-Received: by 2002:a1c:5f86:: with SMTP id t128mr15964025wmb.165.1623053740395; Mon, 07 Jun 2021 01:15:40 -0700 (PDT) Received: from ?IPv6:2a0a:1580:0:1::100c? (ovpn1.odiso.net. [2a0a:1580:2000::3f]) by smtp.gmail.com with ESMTPSA id o17sm14417915wrp.47.2021.06.07.01.15.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 01:15:40 -0700 (PDT) Message-ID: <998956055273321cc687db49df5781480e6a4dc2.camel@odiso.com> From: aderumier@odiso.com To: Thomas Lamprecht , Proxmox VE development discussion , pve-devel Date: Mon, 07 Jun 2021 10:15:37 +0200 In-Reply-To: References: <2f9496ebbe77d7c740bf9ef62b9119a1ac583abe.camel@odiso.com> User-Agent: Evolution 3.40.2 MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.839 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% 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 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" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 07 Jun 2021 08:16:21 -0000 Le vendredi 04 juin 2021 à 09:52 +0200, Thomas Lamprecht a écrit : > 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. yes, I think currently we don't have any check to not allowing same device sharing across  multiple vms ? Ha is pretty dump too, try to start vm if host don't have device/storage/network. (I would like to improve that in the future, but I don't have enough time ;) > > > - 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? > It's really not a problem. I have done a lot of try with regenerate the config drive online. (I'm currently still working to improve cloudinit onlines changes) and with a different content, even with unplug/replug the config drive with the iso mounted, it's working without any problem. And even if a file is currently read, it's open as read only. so you can remount to a different iso without any lock. So here, with a live migration, with same content regenerated, I really don't see any problem. The cloud-init don't keep any file open after reading them, I don't think the iso is even mounted after cloudinit has runned. > > > > - 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. I already have some students requests about security/license dongle for example. > > 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. > yes , agreed. > > > > - 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. > yes, pretty dangerous. That's why I was thinking of a special wizard somewhere  with a lot of warning, not just "click on vm of the dead node-> move") or maybe cli only. Move files manually is pretty bad too currently, as you don't have any check if the storage exist for example > > > > - 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?  I was thinking to simply check if the agent is running. (not perfect, but still an improvement) > Also, wait for ever > if the dependent VM is on another node which is currently offline? maybe add a timeout if the depend vm is not started > > A manual start would probably need to allow overriding such ordering > too, > I guess. > yes indeed. (This request is really not a big priority for the student) > > > > > > 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. > yes, student request was to have something central to display current versions, and even better pending update > > - 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. yes, something like that.  not a big priority request too. > > > > > - 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 >