Keep access to VM when logged off HOST - VMWare / VBOX

Hi folks
HYPER-V and KVM systems still allow access to VM's when the main user is logged out of the Host -- I have some users who don't have an account on the Host but have accounts on VM's -- anyway to ensure that VM's created with VBOX or VMWARE can still run in background and be accessible even when the main HOST user has logged out of the Host system.

I believe anyway KVM VM's can run automatically from boot as can HYPER-V VM's so nobody needs to be logged on to the HOST to start required VM's so a normal boot should enable all the required VM's by just "auto starting" them.

These VM's are accessed remotely from the users own laptops.

Cheers
jimbo

Jimbo, I worked out some procedures to allow VMware VMs to be run without having to logon and to continue to run when the user logs off.

Currently, VMware has functionality built-in called "Shared VMs" that allows for this. However, VMware has announced that after version 16.x this feature will no longer be available. So the steps below are a workaround to allow standard VMware VMs to start without a user having to logon and to remain running after a user logs out.

I hope this helps someone! I worked this out because

1) I'm not a fan of Hyper-V (won't get into reasons now)
2) I wanted to have a Plex Server start automatically within a VM without ever having to logon to my system.

Okay, enough said. Here is the procedure:

I would have to verify this, but it is possible that the ability to suspend the VM upon shutdown / reboot may require Win 10 Pro, not Home because it will require a Group Policy and I think that Home has no Group Policy editor. I may be wrong on that point. However, you can still start the VM(s) without having to logon.

VMware workstation had a feature called "Shared VMs" that allowed a VM to run without a user needing to logon to Windows. VMware has announced that this feature is deprecated and will no longer be available after VMware Workstation 16.x. However, I have a procedure that will still allow you to run VMs without the need to logon.

NOTE: Be aware that this procedure will start the VM with no GUI. As a result, you will want to make sure that the VM is configured to allow access via remote desktop so that you can connect that way. In addition, you may want to set your VM to autologon so that any programs you want to run within the VM can launch at startup. For example, this is the procedure you would want to follow for a Plex Server VM. Note that this applies only to the VM. You do NOT need to logon to the host system to allow the VM to run.

Verify the location of VMware Workstation. By default, it is located here:

C:\Program Files (x86)\VMware\VMware Workstation

Within that folder you should find the vmrun.exe file.

Now, locate the path to the .vmx file for the VM that you want to automatically run.

Example: "D:\VMware Virtual Machines\Windows 10 21H1 Clean Install Test Platform\Windows 10 21H1 Clean Install Test Platform.vmx"

Create a batch file that looks like this (modify the paths as necessary):

"C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" start "D:\VMware Virtual Machines\Windows 10 21H1 Clean Install Test Platform\Windows 10 21H1 Clean Install Test Platform.vmx" nogui

Option 1: This will run the VM upon logon.

Open Run and type "Shell:Common Startup"
Drag and drop the batch file that you created into this location. Click Continue to allow the batch file to be run as Administrator.

Option 2: This will run the VM without the need to logon.

Run the task scheduler, right-click Task Scheduler Library, select Create Task.
Give a name to the task, choose Run whether user is logged in or not, configure for Windows 10.
On the Triggers tab, select New... begin the task at startup. Make sure that the Enabled checkbox is checked.
On the Actions tab, select New... > Start a Program should be selected for the action. For Program/Script specify the full path and file name of the batch file.

Example: "C:\Scripts\Autostart VM.bat"

Click on OK, then OK again and enter your credentials.

--------------------
To suspend the VM when the host is shutdown

Setup another batch file on the host with a command in it like the one below. Modify the paths as necessary:

"C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" suspend "D:\VMware Virtual Machines\Windows 10 21H1 Clean Install Test Platform\Windows 10 21H1 Clean Install Test Platform.vmx"

Then set it run when the host shuts down by placing the batch file in "C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Shutdown". Open the Group Policy editor "gpedit.msc" and then in "Computer Configuration - Windows Settings - Scripts" add your batch file to the shut down script option.
--------------------
Additional Information

If you don't want to access your VM via Remote Desktop, you can gain access to it via the VMware GUI by doing this:

1) From the VMware GUI, select the VM in question (you won't see a GUI, so just click within the space where it would normally appear) and press CTRL-J to suspend it.
2) Once suspended, press CTRL-B to resume the VM.

Result: The VM is now visible.

IMPORTANT: Once making the GUI for the VM visible, if you logout the VM will be suspended so you will need to lock the system rather than logging out if you want it to remain running. If you do not make the VM visible, it will continue to run even when you logoff.

3) When done, make sure to close the VM GUI. A warning will be displayed indicating that some VMs are still powered on. Choose "Run in Background". If you don't do this, the VM will not be suspended cleanly when you physically shutdown or reboot the system.

NOTE: If you do not want to have to deal with this every time, within the VMware GUI, choose Edit > Preferences... Workspace > Keep VMs running after Workstation closes. By doing this, you won't be prompted after closing the VMware GUI whether you want to keep the VM(s) running.

Reminder: To keep the VM running, make sure to LOCK your system rather than signing out. If you do not bring the GUI to the foreground, you can sign out and the VM will continue to run.

Hi there

@hsehestedt

Thanks for the info -- I can't understand why VMWare is making a meal of this -- they used to have "VMWare server" which allowed that.

Just look how simple it's becoming using Linux Hosts with their Hypervisor these days !!!



Surely some sort of "Autostart" feature in Windows should be possible in the VM setup -- after all VMWare starts some services automatically now anyway.

No need to logon even as root -- just boot the machine - the VM('s) start automatically even without a desktop GUI -- and you can go on your way !!!!!.

Can all be done from the xml config file for the appropriate VM if you don't want to use the Virtual machine manager GUI. !!!

Cheers
jimbo

hsehestedt said:

I would have to verify this, but it is possible that the ability to suspend the VM upon shutdown / reboot may require Win 10 Pro, not Home because it will require a Group Policy and I think that Home has no Group Policy editor.

Click to expand...

On Home you can create the specific registry entry for the policy, so it should work without the editor.
This one in particular I have no idea how it's called, a quick search reveals it:

Hopachi said:

On Home you can create the specific registry entry for the policy, so it should work without the editor.
This one in particular I have no idea how it's called, a quick search reveals it:

How to add a shutdown script (not by using gpedit.msc or active directory)?

I have created a script I want to deploy on my XP workstations as a shutdown script. I know I can add my script as a shutdown script with the UI (gpedit.msc), but I want to automate the deployment...

serverfault.com

Click to expand...

Hi there

@Hopachi

the problem seems to be the fact (at least on VMWare WKS rel 16.x that the VM (Windows VM's) is assigned to a specific user so if that user logs out the VM may be still running in the background but can't be accessed .

On Linux Hosts KVM Windows VM's run just fine straight from boot without even a GUI running. I'm playing around with a W11 VM on a Linux host now under VMWare WKS 16.x to see if I can access the VM remotely. I can run both VMWare VM's and KVM VM's concurrently so I should be able to RDP to either of them from a "remote" laptop.

Shutting / suspending a VM isn't the issue -- starting a VMWare VM at boot seems on Windows hosts not to be possible as you need to be a foreground user to start the VM.

Test 1 -- Bring up VM on Linux Host (VMWare running) and from laptop RDP to it.
Test 2 -- logout of the Host machine and see if W11 VM still acessible --- KVM VM's OK, will test VMWare and see what happens.

Cheers
jimbo

OK @jimbo45 good luck.
I've only added a minor detail on that interesting procedure @hsehestedt posted.

Hi there
1) VMWare RDP from remote laptop with user logged on to Host works as designed -- no problems there with standard RDP connection.

2) User logs off the HOST --RDP disconnects



If User then re-logs on to the Host machine the VMWare VM is powered off so really pretty useless if you say just want to have the HOST running Windows (or other) VM's with the terminal locked / running in headless mode.

Under KVM the VM is accessible stright from Host boot up (if boot automatically when host is booted is enabled.

Here Host in "terminal mode" - no user logged on but KVM W11 VM acessible from remote laptop




Much more useful !!!!

I know VMWare WKS is really for a single workstation - so what I would be looking for on VMWare is the old VM server which did what I wanted -- seems the latest release of WKS has removed some useful features.


Cheers
jimbo

jimbo45 said:

Just look how simple it's becoming using Linux Hosts with their Hypervisor these days !!!

Click to expand...

Hyper-V in WIndows makes it even easier.

Save the VM state when host shuts down:



Restore VM state when host boots:



That's it.

Kari

Kari said:

Hyper-V in WIndows makes it even easier.

Save the VM state when host shuts down:

View attachment 6051

Restore VM state when host boots:

View attachment 6050

That's it.

Kari

Click to expand...

Yep - dead easy. Now I have worked out how to get sound in Hyper-V for Linux (Ubuntu at least), I have no reason to use any other Hypervisor. All my Windows are Pro based. I never run Home in Hyper-V as that cannot run in enhanced mode.

Also as @Jimbo says, if you sign out from Host, the Hyper-V VM continues to run, so a user with account on VM can access the VM but not the Host (unless they also have account on Host).

Obviously, on W10 non server versions, only one person can RDP to a VM at a time.

I have yet to test if two users can rdp to separate VMs but I see no reason why not so long as only one user per VM logged in.

cereberus said:

Yep - dead easy. Now I have worked out how to get sound in Hyper-V for Linux (Ubuntu at least), I have no reason to use any other Hypervisor. All my Windows are Pro based. I never run Home in Hyper-V as that cannot run in enhanced mode.

Also as @Jimbo says, if you sign out from Host, the Hyper-V VM continues to run, so a user with account on VM can access the VM but not the Host (unless they also have account on Host).

Obviously, on W10 non server versions, only one person can RDP to a VM at a time.

I have yet to test if two users can rdp to separate VMs but I see no reason why not so long as only one user per VM logged in.

Click to expand...

Thanks guys - especially @cereberus and @Kari

Two users can RDP to different VM 's concurrently on HYPER-V -- tested OK -- from different remote RDP sessions of course as Windows is essentially a single user system.

Thanks also for the info on VM in HYPER-V continuing to run if user logs off HOST - -- BTW multiple users can logon to a single Linux VM running on HYPER-V concurrently by nature of Linux being a multi-user system.

Cheers
jimbo

jimbo45 said:

Thanks guys - especially @cereberus and @Kari

Two users can RDP to different VM 's concurrently on HYPER-V -- tested OK -- from different remote RDP sessions of course as Windows is essentially a single user system.

Thanks also for the info on VM in HYPER-V continuing to run if user logs off HOST - -- BTW multiple users can logon to a single Linux VM running on HYPER-V concurrently by nature of Linux being a multi-user system.

Cheers
jimbo

Click to expand...

Yeah I tested multiple vm sessions (one user per session) and it works fine.

My opinion only so no need to jump on me for this:

While I prefer to use Microsoft native stuff wherever I can, the one big exception for me is the Hypervisor. I hate Hyper-V with a passion.

I seem to frequently have difficulties moving a Hyper-V VM from one location to another. Also, on 3 out 3 machines, it has caused network problems for me on the host PC. I'm sure that is not what most others experience, but my config may be different from that of most people.

hsehestedt said:

My opinion only so no need to jump on me for this:

While I prefer to use Microsoft native stuff wherever I can, the one big exception for me is the Hypervisor. I hate Hyper-V with a passion.

I seem to frequently have difficulties moving a Hyper-V VM from one location to another. Also, on 3 out 3 machines, it has caused network problems for me on the host PC. I'm sure that is not what most others experience, but my config may be different from that of most people.

Click to expand...

I am not sure why you have difficulty moving the vms. The trick is to remove the vhds and isos from the vm, transfer to new pc, and then reinstating vhds.

Regarding network issues, it may be related to issues with external switches.

Hi there
not sure why moving VM's around whatever VM system you are using should cause any problems --that's the purpose of typical VM's is to be hardware independent and possibly scaleable. OK moving Windows VM's can cause a problem with activation based on a moved / copied VM having a new uuid which Windows activation might detect as different hardware but if you keep the same uuid in the VM's config that shouldn't happen.

Meanwhile moving VM's should be simple by loads of means --snapshotting, exporting, taking a macrium or equivalent image of the VM and / or the Host system, replicating the VHD's, duplicating Host and or VM's physical disks etc etc.

Of all the problems one could have with VM's I think the least likely one should be copying / moving them -- at least that's been my experience with them so far.

Cheers
jimbo

Ah yes, moving...
Moving VMs was something done pretty much differently (as in different ways to do it) on each hypervisor. Though the basics are the same; you copy / move your virtual disk and you are as good to go.

I've now got used to how Hyper-V manages it.
Where in VirtualBox I had to dig in the XML config for the ID's and stuff, I still find this very handy also on QEMU/KVM, I can copy the XML as a kind of manual export/backup.

Simply copying or moving the disk without the UUID of machine would show some problems in Hyper-V.
Thanks to @Kari and @cereberus tutorials here I found how to better export so that a 'move' can be done properly in Hyper-V.

My non-activated test machines can just be moved with the disk alone.
But those activated VMs would need to be moved with ID and all, and also best to have all the specs as before instead of guessing those each time in config.