How would you build a VDI solution based on thinlinc?
I would use the subcluster feature to allocate a personal VDI node for every user by defining a subcluster for each user,
On idle timeout or logout I need to hook the logout process in order to poweroff the VDI node. Are there any logout hooks in thinlinc? Another solution would be to use systemd’s IdleAction=poweroff. This requires the use of a modern desktop enviroment (Gnome) which updates the systemd idle timer.
On login the vsmserver need to make a rest call to the virtualization platform in order to power up the VDI node, wait for it to start the thinlinc agent and then redierect the client to the VDI node. To my knowledge there is no way of hooking in to the vsm server other that to try editing the obfuscated python mess.
It’s a tricky one. ThinLinc is not a VDI solution, but the first part you describe using subclusters is exactly how I would do it. The part about powering on/off machines is more difficult, since it is somewhat out-of-scope for a terminal server solution. I don’t think there is a simple way to achieve that in ThinLinc currently.
That said, if this is an important requirement for you then please get in touch by emailing support@cendio.com, and we’ll see if there is anything we can do to help.
@pira out of curiosity - is this a base requirement for the organisation, or just a small number of users who require it?
I remember way back helping a customer who wanted a similar thing for physical machines, so they would wake from hibernation on demand. We solved it using wake-on-lan packets, and it worked really well for a fairly small number of users. No idea if modern hypervisors support WoL, but if they do it might be a nice platform-agnostic option.
We are thinking of implementing this at a fairly large scale (hundereds of nodes/users). Wake on lan is probably not supported by any hypervisors. There is no hook that we can use to wake up nodes anyway.
Supporting any one specific hypervisor API would be a big project, and probably outside the scope of ThinLinc as a terminal server solution. But I think you’re right, it might be useful to have some kind of hook into the session startup mechanism. Perhaps @CendioOssman or @samuel are better placed to comment here.
It would be useful for us to understand the rationale for a VDI-based solution like the one you describe, over a terminal-server based one. i.e. is it about being able to power down machines when they’re not being used, do users require root access to the machines, some other reason, etc?
If thinlinq would have some hooks, the Proxmox API should be able to handle this. You can setup a template for a VM, let it mount the Hyperconverged CephFS filesystem and configure the network-interfaces via cloudinit…
What types of hooks would you be interested in? A folder of scripts to run on the Master before it tells an Agent to start a ThinLinc session? Something like a /opt/thinlinc/etc/presessionstart.d?
The hook we have in /opt/thinlinc/etc/sessionstart.d runs on the Master (as root), but only after the Agent has reported that a session has been created.
Regarding hooks for when a user logs out of the session, we have /opt/thinlinc/etc/xlogout.d. Scripts in this folder runs as the user on the agent once the ThinLinc profile has exited. Do you believe that would be sufficient for the logout-part of the use case you are imagining?
Read more about existing customization options here:
The most complicated part of such a presessionstart-hook would be the load balancer. Currently, the ThinLinc master selects the agent which could fit the most new user-sessions resource-wise.
It seems the sort of mechanism being discussed here would have to be able to bypass or replace the default load balancer. Establishing a good API for such a mechanism isn’t trivial.