[pve-devel] training week: students feedback/requests

[Thomas Lamprecht]

Hi,

On 04.06.21 05:21, aderumier at 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 <a> 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