9 hours ago
Hi,
Correct.
As VM's have to be able to run without logging in, they are started early. This means that the VM's run in session 0 without access to a desktop.
The trick to be able to get access to the VM console and thus have the VM's run in session 1 is to do a suspend of the VM running in session 0, followed up immediately by a resume in session 1. It's a bit of a hack, but this tends to work very well.
It is certainly better than the alternatives I managed to find which basically required circumventing restrictions imposed by Microsoft security design. I'm not aware of an official API to move a process from session 0 to session 1.
I had to go check as I remember there was some issue in this respect, but that turned out to be VMware Player only, not VMware Workstation Pro. With VMware Player even if you set the VM to continue running in the background, it suspended the VM on logoff.
At least I could not reproduce this issue on Workstation with VMware's "Keep VM's running after shut down Workstation" option checked.
Vimarun itself does not suspend/resume the VM during log off/log on.
No, it should not. The suspend/resume action is one time only and only after a shutdown and login on the same user account as where VMware Workstation is running.
This is hard to say without testing. When consuming a terminal session on a VM that was connected to another machine via RDP the session normally did not drop out. I've never tested this with running a Terminal Server in a VM. I suspect the sessions will be unresponsive for a bit, but surviving the suspend/resume action. But this is likely going to be hardware and environment specific.
--
Wil
(Today, 00:36:04)Sontec Wrote: Hi Wil,
I have an RDP/Terminal Server running on VMware Workstation Pro.
I’m considering using Vimarun to automatically start the server when the host restarts.
From what I’ve read about Vimarun, I understand that when I log on to the host,
my VM guest (the Terminal Server) may be temporarily suspended and then resumed again.
Correct.
As VM's have to be able to run without logging in, they are started early. This means that the VM's run in session 0 without access to a desktop.
The trick to be able to get access to the VM console and thus have the VM's run in session 1 is to do a suspend of the VM running in session 0, followed up immediately by a resume in session 1. It's a bit of a hack, but this tends to work very well.
It is certainly better than the alternatives I managed to find which basically required circumventing restrictions imposed by Microsoft security design. I'm not aware of an official API to move a process from session 0 to session 1.
(Today, 00:36:04)Sontec Wrote:
- Will the VM also be suspended and resumed again when I log out of the host?
I had to go check as I remember there was some issue in this respect, but that turned out to be VMware Player only, not VMware Workstation Pro. With VMware Player even if you set the VM to continue running in the background, it suspended the VM on logoff.
At least I could not reproduce this issue on Workstation with VMware's "Keep VM's running after shut down Workstation" option checked.
Vimarun itself does not suspend/resume the VM during log off/log on.
(Today, 00:36:04)Sontec Wrote: 2. If other users log in to the host, could that affect my running VMs in any way?
No, it should not. The suspend/resume action is one time only and only after a shutdown and login on the same user account as where VMware Workstation is running.
(Today, 00:36:04)Sontec Wrote: 3. Could the suspend/resume action mentioned above cause issues for active Terminal Server user sessions?
This is hard to say without testing. When consuming a terminal session on a VM that was connected to another machine via RDP the session normally did not drop out. I've never tested this with running a Terminal Server in a VM. I suspect the sessions will be unresponsive for a bit, but surviving the suspend/resume action. But this is likely going to be hardware and environment specific.
--
Wil