We (a company I am associated with) use guacamole as the basis for a virtual classroom. Our current set up works like this:
- VMs are hosted on GCP. They are GCE instances in a region convenient for the class we are running. We run classes all round the world. - We run multiple guacamole front-ends. They're partitioned by client and/or region. Instructors have some level of admin access and can see all student machines. - Each student has at least 1 VM pre-assigned to them. The VM is configured with all the specific software for the course. We build one disk image that supports the class and then clone it for each machine. This process is semi-automated. Even if we wanted, using a vanilla Windows image would be tough because of tools like Oracle Personal Edition, which poses challenges for machine naming/IP addresses. These need to be dynamically configured, so we run custom start-up scripts. There may be a better way, but that's outside the scope of this email: it is certainly not trivial. - Students may start and stop their assigned VM(s) by means of start/stop buttons next to the machine name on the host list and the pop-up overlay menu. We also display a status. The buttons are handled by a custom authentication extension. Challenges: - One global database is too slow. Guacamole is quite chatty with the database (it is even more with the extension). We run two (one in the US and one in Asia) and don't attempt to synchronise them. It would be great to enhance caching and separate the "read only" portions (like the definition of the users and machines, which is very small even with 100s of users - might not be with 1000s!) from the "read-write" portions, such as the activity log (allowing them to go to completely different databases). I was actually going to suggest we build in a formal decorator mechanism to support this. The email has been sitting in my drafts for many months! Yes, I know I could just wrap the JDBC extension, but a decoration mechanism would be more extensible. - Finding the appropriate machine in GCP requires additional metadata. The GCP API is heavily dependent on region, zone and project. We use several of each, so there is a fairly complex set of additional metadata, which is currently *not* stored in the database, but discovered by matching the IP address. We use a list of projects, regions and zones that *is* in the database: it is too complex for the properties file, though we can also specify through a json file pointed to by properties. This discovery process has to run periodically to allow for new machines or changed machines (it is complicated by the fact that a GCP GCE instance can have more than 1 IP address, so the data structure is more complex than I would like). It would be great to be able to run this process in a ServletContextListener without having to actually modify Guacamole. In fact, my next change may be to move this process into a separate servlet. Of course, an alternative is to provide additional metadata through the database, but I wanted to explain that the metadata may not be quite as simple as it first appears and it would need to be synchronised globally (in our situation). - Currently each thread separately queries for status. Since there is no guarantee which thread a user will hit, this results in several threads simultaneously querying for the same host. Again, I could improve this, but will probably carve it out into a separate servlet. - Starting a Windows machine is really very slow. It takes several rounds of the "waiting" message for it to start. We do not start them automatically, though clearly we could create an EventListener to do that. To be honest, originally I was concerned about how robust the process might be. This is probably a next step. Shutting down hosts is an issue (they cost money to run, but user convenience suggests not stopping them every time a user disconnects). - Testing is hard! I have not found a really effective way to test the extensions since both the web client (the new buttons etc) and the servlet (resource) require quite a lot of guacamole infrastructure. I am slowly working to reduce the dependencies in the Java code, but it would be useful to have bootstrap test utilities for both. There are probably other aspects I have forgotten about since I haven't looked at this since the start of lockdown (March). Happy to get involved, answer questions etc. Regards, Mark On Tue, 1 Sep 2020 at 15:34, Nick Couchman <[email protected]> wrote: > Hey, everyone, > Throwing out a topic for discussion that's been banging around in my head > for a year or two, now, and that's creating a more complete VDI solution > based on Guacamole. As a disclaimer, I'll say that I'm going for technical > discussion and completely ignore the licensing details, here, associated > with Windows in particular. > > It seems like Guacamole already handles most of the functionality required > to build a VDI solution. It does connection management, permission > management, load balancing and grouping, etc. The following are the areas > I can see might need to be implemented in some form/fashion for a more > complete VDI solution: > - VM lifecycle management: Across multiple hypervisors, the ability to > provision and destroy, start and stop, snapshot and refresh virtual > machines, configure them (name, IP, domain membership, etc.), etc. > - Dedicated/user assigned VDI: The preferred idea of "floating" pools is > readily done using the already present load balancing; however, doing a > one-to-one assignment of user to VDI VM within a connection group so that > the user is persistently assigned that VM upon connecting to that group. > While this could be accomplished by just assigning user permission to a > specific VM within Guacamole, this isn't always quite as nice as > abstracting that detail away from the user such that they don't actually > care what VM they're connecting to, just that their user experience is > consistent. > > Those are vastly over-simplified summaries of what needs to be done, but > should be a pretty good high-level overview. I think that most, if not > all, of the functionality could be implemented within an authentication > extension in Guacamole Client, and I'm reasonably certain that most of it > could be done by implementing a decorating extension that overlays data > over the JDBC module, using support for arbitrary attributes of the various > objects to store the VDI-relevant data. > > Anyone have thoughts on this? Valuable, not valuable? Things I haven't > thought about or have missed? Anyone doing anything similar trying to use > VDI on Guacamole? > > I haven't had a ton of time to work on it - mostly sketches on paper at > this point - but wanted to get it out there in the community to discuss... > > -Nick >
