Remote access

[DavidHeath]

I'm totally new to this and writing a business case for a Proxmox installation for our training team to work anywhere in the world. We have an existing internet connection into the server room. From following WAY too many links, it would seem that I could install tailscale on the Proxmox server and make a physical connection to the internet service, probably via a switch with VPNs configured, as there will also be local connections within the room. So, I guess my question boils down to wondering what the clients on the remote stations (and local!) and how exactly they connect - how do we identify the VM they have been assigned?

With further digging in the admin manual, it seems that the relevant VM could be connected to the login name via resource pools. Is that true? if so, it simplifies thing a lot! Although if two people want to use the same VM, does it spin up multiple independent versions?

...as an added question, could we use thin client stations for the travelling suite? I'd expect yes, but I want to be sure... and to understand what they might look like. Further, what does the connection string look like? Is it a single IP address with port numbers (I see 8006 is the configuration port), or is it a named connection to a virtual machine name?

 

[g.moffatt]

Hi David. Proxmox VE can host the VMs for this, and thin clients can be suitable endpoints. The main thing to clarify is whether trainees need access to the VM controls, or mainly to the desktop and applications inside each VM. That'll be the starting point and determines which route to go towards.

An example of what someone would do during a typical training session would help. Would each trainee need their own independent environment, including the ability to make changes and restart it?

As per your question around access / identity. Resource pools can help organise that access. You assign permissions to users or groups on individual VM's or on a pool of resources. A pool does not automatically allocate one machine to each person, so the assignments need to be configured. The User Management documentation explains that model. Documentation here.

If two people connect to the same VM, they are still accessing the same virtual computer. Proxmox does not automatically create another copy when the second person connects.

Let's start there.

Cheers,
Gareth

 

[DavidHeath]

Hi David. Proxmox VE can host the VMs for this, and thin clients can be suitable endpoints. The main thing to clarify is whether trainees need access to the VM controls, or mainly to the desktop and applications inside each VM. That'll be the starting point and determines which route to go towards.

An example of what someone would do during a typical training session would help. Would each trainee need their own independent environment, including the ability to make changes and restart it?

As per your question around access / identity. Resource pools can help organise that access. You assign permissions to users or groups on individual VM's or on a pool of resources. A pool does not automatically allocate one machine to each person, so the assignments need to be configured. The User Management documentation explains that model. Documentation here.

If two people connect to the same VM, they are still accessing the same virtual computer. Proxmox does not automatically create another copy when the second person connects.

Let's start there.

Cheers,
Gareth

Thanks for all that. Reading more after posting, it seems that I should create a 1:1 mapping between users and resource pools, with each pool containing a single VM. Note that users (training students) will never need access to controls - they will simply open and use the VM.

I guess that the only time we'd contemplate multi-use VMs would be if we were running the same course in multiple locations - highly unlikely. Also, how easy is it to revert a VM to a 'base model' prior to a training session?

Also, what remote client software would we run on those thin clients? It's not an area I'm particularly familiar with.

Note that I'm a little stale on networking these days... but I was a Novell CNE back in the late 90s.