Nick,
I see Mark's valuable contribution, mine is probably *much* less so
because I struggle to avoid the ogre in the room that you want to ignore
(understandably!).
To that end I can really only acknowledge the good idea, and let you
know it's been read by others. Technically I've gone a short way down
this track in using Guacamole to access different VM's, and from there
considering how one might improve things to make a more comprehensive
package.
Unfortunately I keep banging up against the M$ thing, which is bloody
frustrating because it works so well. If it wasn't for that I expect
this would be very popular.
As things stand at the moment I wonder whether you have any particular
use case, or have had anyone ask about such deployment (other than the
odd enquiry I've seen on the mailing list)? My reason for asking is
really just to prompt a little discussion/thought as to how many would
use such a thing? It seems to me one could spend a lot of time on it;
it'd be good to know there were those that would use the result.
I should add, at the risk of doing exactly what you didn't want (but
please bear with me), that as much as want to rally and rail about M$
policies I have spent a lot of time trying to research how one might
legitimately achieve the end result that people might want (all the
while using something along the lines of what you propose). In this I've
had various clients that really just want to run a simple subset of
progs - let's say M$ Office as an example - remotely.
None of these people would have an issue paying M$ the standard OEM OS
fee they pay for a PC, but as that isn't allowed by policy (and the
legit way is incredibly complex/expensive) I've looked at using Wine,
Crossover, ReactOS etc. Really, I've gone through a *lot* of calories
but unfortunately haven't yet found a suitable way forward, so I'd be
very keen to know if you or anyone else has figured out a solution?
I realise this goes further than you wished to ringfence the discussion,
so please ignore it as you wish, but on the off-chance I've overlooked
something that could make a VDI system such as this more pertinent or
widely applicable I thought I'd put it out there...
Cheers, Luke.
On 2/09/2020 2:34 a.m., Nick Couchman 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
