CSH currently uses Proxmox for VM hosting. It has been working great for every use case we have for it with one exception: member VM self-service. The interface isn’t very intuitive to someone who might not have created a VM before, creating a higher barrier to entry than we would like for members who might want to start learning how to use Linux for the first time. It also lacked the ability to enforce resource limits and automatically cleanup VMs that members weren’t using anymore. All of my previous major projects were much more operations and/or security focused so I figured writing something to solve this problem would be a great way to do a much more development focused project and expand my developer skillset.
Proxstar (a mashup of Proxmox, a VM hosting solution, and STARRS, an IP/DNS/DHCP management system) is a web application that allows for easy VM self-service for the members of CSH. It is written in Python using Flask and runs on the CSH OpenShift cluster. RQ is being used as a task queue for tasks that take more than a second or two and periodic tasks (RQ-Scheduler). Proxstar allowed members to create, edit, and delete VMs and will automatically handle any network registration that needs to be done in STARRS for them. During creation, they can specify to either create it from a template or to install it themselves from an ISO. If creating it from a template, Proxstar will spin up a ready-to-go VM with a a user that has a randomly generated password for the member to use.
Making RTPs’ Lives Easier
Having to periodically go through and clean up VMs that haven’t been touched by members in months can be a tedious task. Enforcing usage limits can also be difficult since Proxmox doesn’t have a mechanism for doing so. Proxstar allows RTPs to set a limit on the number of CPU cores and amount of memory and disk space a member can utilize. It also sets an expiration date on each new VM, emails the member before it expires, and automatically deletes any VMs that aren’t renewed.
The hardest part of the project was figuring out how to give console access to members. Proxmox does not provide a friendly way to access their VNC consoles, so I had to dig into it to figure out how they did it and try to do a similar thing within Proxstar. Upon clicking the ‘Console’ button, Proxstar generates a valid token for the port that the noVNC session will be spun up on. It then forwards the port that the actual VNC session will be spun up on from the respective Proxmox host to the noVNC instance within Proxstar and starts the VNC session for the VM on Proxmox. Finally, Proxstar opens a new tab with the noVNC session and a valid token to access it. It isn’t the cleanest solution, but it has held up pretty well.