VMware Communities
WoodyZ
Immortal
Immortal

Running a VM Headless (no GUI) and Controlling Shutdown/Suspend with Mac OS X Reboot/Shutdown

Running a VM Headless (no GUI) and Controlling Shutdown/Suspend with Mac OS X Reboot/Shutdown


The Subject says it all and here's the HOWTO:

The following has been tested and used under Mac OS X 10.5 and higher and VMware Fusion 3.x.

Running a Virtual Machine Headless (no GUI) is possible with VMware Fusion however its never been officially supported via the VMware Fusion GUI and VMware is aware that some users would like it to be supported via the GUI however until then here is how I do it.

To run a Virtual Machine Headless. ...

1. First run the Virtual Machine normally to make sure everything is configured as needed and in a manner that can be controlled via ssh, VNC or RDP, Web Browser, etc.  Turn off features that aren't really needed like Accelerate 3D Graphics when applicable as it lowers the memory overhead.  Do not have headless Virtual Machines automatically connect to or be connected to unneeded devices.  Use an ISO Image vs connecting to the Physical CD/DVD, etc.  Also note that the following parameter can be added to the Virtual Machine's .vmx configuration file and this will attempt to automatically answer with the appropriate answer various message boxes that can pop up.  Obviously when running headless not having a message box answered will hang the Virtual Machine as it is not displayed when running in this manner.  One should add this last after having already run the Virtual Machine normally and dispensing with any message boxes and where applicable check the 'Do not show again...' check boxes.

msg.autoAnswer = "TRUE"

2. Shutdown the Virtual Machine a then remove its entry from the Virtual Machine Library and close VMware Fusion.

3. Use vmrun to start the Virtual Machine with the nogui parameter. Have a look at: Using vmrun to Control Virtual Machines

If one then runs VMware Fusion the running Virtual Machine will remain headless since it was removed from the Virtual Machine Library.  Note that you can drag and drop the target Virtual Machine Package onto the Virtual Machine Library while it's running headless in order to attach it to the GUI however understand that this can cause the Black Screen of Death in that the Virtual Machine Display will be Black and possibly not interactive through the GUI and will probably stay that way until it is shutdown via the earlier preconfigurations made to control the Virtual Machine while running headless and then closing VMware Fusion and reopening VMware Fusion. Note that this condition does not always occur however it can and does happen so it's imperative that one has a way to perform a controlled shutdown of the Guest OS via ssh or other remote access type methods.

Note: While running headless understand that if the Mac is rebooted/shutdown without first gracefully shutting down or suspending any Virtual Machines that are running headless (or normally for that matter) this can at its worst corrupt them to a point beyond repair so it is imperative that one remains cognizant of this and take appropriate measures to always suspend or shutdown all Virtual Machines that are running headless or normally before rebooting or shutting down the Mac.  By themselves Virtual Machines running in headless mode require either direct user action as they will not suspend automatically like a normal running Virtual Machines when closing VMware Fusion unless one takes additional steps to enable controlled shutdown/suspend upon a controlled reboot/shutdown of the Host, Mac OS X and this will be covered within the three topic covered below.

  • Starting a Virtual Machine without User Login


  • Starting a Virtual Machine upon User Login


  • Shutdown/Suspend Virtual Machine upon Mac OS X Reboot/Shutdown

==========

Starting a Virtual Machine without User Login

If you want to run a Virtual Machine as a Service without having to Login then a .plist file will need to be created for the target Virtual Machine and placed in the /Library/LaunchDaemons/ folder.  The .plist file can be created using the example below or using a nice free GUI Tool named Lingon(Note: This link is for the last freeware version.  The latest is available at the App Store for $4.99.)

Hint: I often use TextEdit in Plain text mode as a buffer when copying/modifying/pasting blocks of code before pasting them into nano and or also use TextWrangler as it can access hidden files/folders and allow root access editing of files that are owned by or need to be owned by root.

In a Terminal (/Applications/Utilities/Terminal):

cd /Library/LaunchDaemons/

sudo nano com.wkz.headlessvm.plist

Copy and paste the code below into nano.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>Disabled</key>

    <false/>

    <key>KeepAlive</key>

    <false/>

    <key>Label</key>

    <string>com.wkz.headlessvm</string>

    <key>ProgramArguments</key>

    <array>

        <string>/Library/Application Support/VMware Fusion/vmrun</string>

        <string>-T</string>

        <string>fusion</string>

        <string>start</string>

        <string>/Virtual Machines/Windows XP Professional SP3.vmwarevm/Windows XP Professional SP3.vmx</string>

        <string>nogui</string>

    </array>

    <key>RunAtLoad</key>

    <true/>

    <key>UserName</key>

    <string>WKZ</string>

</dict>

</plist>

Save the com.wkz.headlessvm.plist file by typing Ctrl-O then Enter and then Ctrl-X to close nano.

Verify the permissions on the file using the ls -l command:

-rw-r--r--  root  wheel  com.wkz.headlessvm.plist

If it does not show as in the example above then use the following commands:

sudo chown root:wheel com.wkz.headlessvm.plist

sudo chmod 644 com.wkz.headlessvm.plist

Note: The fully qualified pathname to the .vmx configuration file must be used and in my working example I have my Virtual Machines folder in the root of the Macintosh HD not in the Documents folder in my Home folder, the latter being the VMware Fusion default location so adjust pathnames accordingly as well as other bits of information to match your environment and these are shown in maroon.

Additionally the KeepAlive key when being set to  will restart the Virtual Machine immediately if you shutdown the Virtual Machine from within the Guest OS, suspend it with vmrun or kill the vmware-vmx process so keep that in mind when first configuring and testing your settings and as such I'd keep the value set to "false" until everything is worked  out.  Also if you do not need to keep it alive under any condition, except Mac OS X Reboot/Shutdown of course, and want to be able to shutdown/suspend the Virtual Machine while logged in or just leaving Mac OS X running then use "false" for the KeepAlive key.  This key is really more for running headless on Mac OS X Server when the Virtual Machine is providing mission critical services and why one would want to keep it alive during normal operations if something was to kill the vmware-vmx process. The vmware-vmx process is the actual Virtual Machine vs the VMware Fusion process the UI.

Using Lingon is probably more intuitive and better then working directly with XML unless you just like to write code the old fashion way.  Note:  I found it better to initially create the .plist file using nano in a Terminal and then as/when needed to use Lingon to more easily edit or disable as needed.  The primary difference was when starting with Lingon it did not have the UserName and WKZ key/value and this did make a difference with permissions through multiple reboots/shutdowns during my first testing with Lingon a few years ago when Eric (etung) turned me onto it and with starting the Virtual Machine in this manner and the shutdown/suspend method described in the next section.

==========

==========

Starting a Virtual Machine upon User Login


          &


Shutdown/Suspend Virtual Machine upon Mac OS X Reboot/Shutdown

I have a folder in the root of the Macintosh HD named Scripts and this folder is included in the ${PATH} to make it easier to execute my scripts while keeping them separate from the OS and Application files.  In my Home folder in a Terminal I created a  file named .profile and added the following:

export PATH=$PATH:/Scripts

What nice about this is I also have added alias to this file which enable me to use very short commands for normally very long commands lines.

In the Scripts folder the two scripts used for the Headless Virtual Machines are, runheadless and suspendheadless and each have at a  minimum the following as examples:

runheadless:

#!/bin/bash

"/Library/Application Support/VMware Fusion/vmrun" -T fusion start "/Virtual Machines/Windows XP Professional SP3.vmwarevm/Windows XP Professional SP3.vmx" nogui

suspendheadless:

#!/bin/bash

"/Library/Application Support/VMware Fusion/vmrun" -T fusion suspend "/Virtual Machines/VMware Fusion/Windows XP Professional SP3.vmwarevm/Windows XP Professional SP3.vmx"

If you need to have more then one Virtual Machine running headless just add an addition line of code for it.

These actions could be accomplished in a single script that has to be used anyway and shown below however I find it better for my needs to do it this way, so feel free to take whatever from all of this and use it to your liking. Also if you start the Virtual Machine using the "Starting a Virtual Machine without User Login" method from above then you can either leave the command out of the StartService () function leaving that line blank or leave it as is and use the target file and comment out the vmrun line in that file and this way you can more easily switch between the two startup methods that are being discussed herein.

The most important part about the following is this is what does the controlled shutdown/suspend as well as one of the startup methods if one chooses to start the Virtual Machine headless from this script too.

The following commands need to be done as root so in a Terminal you can either change to root using sudo su or preface all command with sudo it's your choice.  Because of the number of commands and the time it takes I suggest using sudo su.

mkdir /Library/StartupItems/HeadlessVM

cd /Library/StartupItems/HeadlessVM

nano HeadlessVM

Copy and paste the following code into nano.

#!/bin/sh

. /etc/rc.common

StartService ()
{
    /Scripts/runheadless
}

StopService ()
{
    /Scripts/suspendheadless
}

RunService "$1"

Save the HeadlessVM file by typing Ctrl-O then Enter and then Ctrl-X to close nano.

Next make the HeadlessVM script executable.

chmod a+x HeadlessVM

Next create a StartupParameters.plist file for the HeadlessVM script.

nano StartupParameters.plist

Copy and paste the following code into nano.

{
  Description     = "HeadlessVM";
  Provides        = ("Runs/Suspends Virtual Machine Headless on OS X Startup/Shutdown");
  Uses            = ("Disks");
}

Save the StartupParameters.plist file by typing Ctrl-O then Enter and then Ctrl-X to close nano.

The permissions on these files are important and if not set properly will not execute properly so an ls -l should show as follows:

-rwxr--r--  root  wheel  HeadlessVM
-rw-r--r--  root  wheel  StartupParameters.plist

This equates to 744 and 644 respectively and if need be use the chown and or chmod command shown above eairler with these masks and the   permissions for Group and Others must only be read only.

Note: There are other methods of Starting a Virtual Machine upon User Login however to do a controlled shutdown/suspend of a headless Virtual Machine, while there may be other methods, using the StopService ()function in the above script while using /Library/StartupItems is the only method that I personally know of and information show here in part was derived from Start Me Up: Writing and Understanding OS X StartupItems and direct usage on my own system and use habits.

After creating/modifying these files Mac OS X needs to be rebooted and make sure that the Virtual Machine is either manually suspended or not running when first creating the files in this last section as the Virtual Machine will not shutdown/suspend until after the reboot and then on the next reboot/shutdown cycle.  Also note that I choose to suspend headless Virtual Machines vs shutting them down when rebooting/shutdown the Host because it's a faster process in either direction although it can be coded to shutdown.  Be aware the shutting down takes longer and in that essence leaves more room for error if the Host decides to hiccup during a reboot/shutdown.

Needless to say even though this will handle a controlled shutdown/suspend on the Virtual Machine in order to safety reboot/shutdown the Host don't forget to make regular user data backups and backups of the Virtual Machine Package itself so as to have a clear and clean recovery plan when something go wrong and remember that it is a known fact that Time Machine is not 100% reliable under all conditions to backup/restore Virtual Machines and should not be relied upon so make a manual backup of the Machine Machine with it shutdown, not suspended and VMware Fusion closed.

Have fun running your Virtual Machines headless! Smiley Happy

==========

WoodyZ - VMware vExpert, 2009 & 2010

VMW_vExpert_Q109_200px.jpg

Message was edited by: WoodyZ

This was originally posted in mid Nov, 2010 and the formatting was corrupted during the VMware Web Site upgrade in Dec, 2010 and has been now been cleaned up some to correct what showed as errors in coding due to the new version of software being used in the forums.  Some clean up remains to be done.

Reply
0 Kudos
17 Replies
idle-jam
Immortal
Immortal

Thanks for this in depth tutoria! awesome!






iDLE-jAM | VCP 2, VCP 3 & VCP 4

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Reply
0 Kudos
dav0101
Contributor
Contributor

Many thanks for good info!!

For KeepAlive I'm not sure. Since vmrun returns as soon as the vm-image has started, this will

1) make launchd think it quit and infinitely try to respawn a new one

2) if the vm-instance crashes at a later stage, since launchd looses it's child as soon vmrun daemonizes the process, there is no way for launchd to detect a crash.

= KeepAlive will not work, unless there is a way to have vmrun (or similar) to stay in the foreground.

Am I wrong?

Reply
0 Kudos
WoodyZ
Immortal
Immortal

Am I wrong?

Simply put, yes. Smiley Happy

Now that's not to say that your experience may not very however it certainly is easy to test by setting the flag on that key and then reboot the Host and then once at the Desktop simply kill the vmware-vmx process and watch it come back to life, then kill it again and watch it come back to life. Smiley Happy

FWIW As an IT Professional and as a general rule I do not intentionally post inaccurate or untested information and in most cases the information I provide comes from direct first hand experience from testing and or regular use. Smiley Wink

Reply
0 Kudos
dav0101
Contributor
Contributor

I'll do some tests, just figured it returns, so launchd will respawn.

Need the suspend thing though and think the good ol StartupItem is maybe the smoothest way to go.

However a basic bash or python script that both execs vmrun and listens to SIGTERM and makes a graceful suspend even in nogui mode would be simplest (still using launchd).

best

d

Reply
0 Kudos
dav0101
Contributor
Contributor

I've tried now and can verify KeepAlive does NOT work with vmrun.

  • launchctl load (the plist that runs vmrun start win.vmx)....
3/18/11 1:26:17 PM     .com.vmware.fusion[23390]     adaptor daemon booted
3/18/11 1:26:17 PM     .com.vmware.fusion[23390]     connector "vmlocal" booted
3/18/11 1:26:17 PM     kernel     vmnet: Setting peer info for hub: 1,...

  • after 10sec the vmware has launched completely and will then return.
  • so, below we see launchd thinking it died (which is not true) and therefore keep respawning.

3/18/11 1:26:27 PM     com.apple.launchd.peruser.501[147]    
     (livestore_launchd_vmware_pqlabs) Throttling respawn: Will start in 10 seconds
3/18/11 1:26:37 PM     com.apple.launchd.peruser.501[147]    
     (livestore_launchd_vmware_pqlabs) Throttling respawn: Will start in 10 seconds

...
Required Behaviors (vmrun doens't qualify here)
  • You must not fork your process and have the parent process exit.
  • You must not daemonize your process.
    This includes calling the daemon function, calling fork followed by exec, or calling fork followed by exit.
    If you do, launchd thinks your process has died.
Reply
0 Kudos
WoodyZ
Immortal
Immortal

I have to admit that I had not previously checked the logs for this since when I originally wrote this I had only tested killing the vmware-vmx process and it came back and the VM was accessible and usable.  However having now looked at the logs I see what you're saying although regardless of what Apple says the vmware-vmx process is restarted when killed however from what Apple says this certainly is not the best way to keep the VM alive if it crashes so I'll have to remove the KeepAlive aspect from the OP, however I may not get to it for a few days or so.  I personally do not need to keep the VM alive if it crashes and can restart when necessary and I included KeepAlive in the post more for a solution for use with OS X Server as that is where it would be more mission critical to have it restarted automatically if it crashed.

Anyway thanks for the follow up and as long as you do not use KeepAlive the rest of the information presented should be usable as is as a reference to customizing for ones own use.

Reply
0 Kudos
dp_fusion
Enthusiast
Enthusiast

I had thought the nogui option was removed in recent releases of Fusion. Also that while it did work in earlier versions, it was never a supported option. Is any or none of this true?

As for restarting a vm after a crash, launchd is not the best solution for the reasons Apple states. Another solution is to use one of the open source daemon watching programs. These are often already running in many server environments and do a good job, generally. This is especially true if running clustered servers.

Nice writeup, Woody.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

VMware has never officially supported running a Virtual Machine in Headless Mode from the VMware Fusion UI even though in VMware Fusion 2 there was a hidden and unsupported fluxCapacitor settings that provided a Headless UI option it was removed in VMware Fusion 3 as a result of changes to the rendering engine.  At the present time the only supported method for running Headless is to use vmrun with the start command and the nogui parameter however if you did not remove the Virtual Machine started in this manner from the Virtual Machine Library prior to starting it then there were issue with VMware Fusion in some earlier releases where it would automatically reattach to the VMware Fusion UI just upon opening the UI and was unwanted behavior and I figured out early on the trick was to remove it from the Virtual Machine Library prior to starting via vmrun and it would not then automatically reattach to the UI just because the VMware Fusion app was started afterward.  These points I though I made clear in my OP however I have to admit that I never really finished the document when first published and only because of several users needing help in this area did I take the time to cleanup the mess made to this document by the December Website Upgrade fiasco that still several months later has unresolved and on going near daily issues but don't get me started on that.

As far as the information I've presented in my OP the only issues I see, and will remove when I have the time, is the use of the KeepAlive key however it's real simple just do not use it and the rest of the information is usable and or can be modified to suite ones own particular habits/needs/wants.  FWIW I don't believe using KeepAlive was ever the primary focus and reason for the document to begin with it and was always more two fold in how to, through automation start a Virtual Machine in Headlless Mode without having to have logged in first to the Users Desktop and more importantly provide a automated noninteractive mechanism without the express need of user intervention to preform a controlled suspend/shutdown upon reboot/shutdown of the Host.  This was always the primary focus and motivation behind making this document even though it had already been discussed in varying degrees by myself and others along the way as the calls for wanting an officially supported Headless Mode via the VMware Fusion UI which unfortunately 3 major versions later still doesn't exist just like the missing Virtual Network Editor that VMware Workstation has and not VMware Fusion.  Look at all the hoops and jumps and discussions that have taken place over the years in this particular area and is a major and glaring shortcoming of VMware Fusion to date.  DaveP provided VM@Work Tokamak to help automate this issue however unfortunately it like so many other things has falling by the wayside.

Reply
0 Kudos
dp_fusion
Enthusiast
Enthusiast

Just tried an experiiment regarding the validity of "nogui" as a vmrun parameter and it is indeed still there.

Check first to see if it is a script or a binary:

bash-3.2$ file "`locate vmrun`"

/Library/Application Support/VMware Fusion/vmrun: Mach-O executable i386

It's a binary so no point in exploring it directly. Let's see if it has a help screen and if it includes "nogui" (it does, shown in red below):

bash-3.2$ /Library/Application Support/VMware\ Fusion/vmrun


vmrun version 3.1.2 build-332101

Usage: vmrun [AUTHENTICATION-FLAGS] COMMAND [PARAMETERS]

AUTHENTICATION-FLAGS
--------------------
These must appear before the command and any command parameters.

   -h <hostName>  (not needed for Fusion)
   -P <hostPort>  (not needed for Fusion)
   -T <hostType> (ws|fusion)
   -u <userName in host OS>  (not needed for Fusion)
   -p <password in host OS>  (not needed for Fusion)
   -vp <password for encrypted virtual machine>
   -gu <userName in guest OS>
   -gp <password in guest OS>

POWER COMMANDS           PARAMETERS           DESCRIPTION
--------------           ----------           -----------
start                    Path to vmx file     Start a VM or Team
                         [gui|nogui]

stop                     Path to vmx file     Stop a VM or Team
                         [hard|soft]

reset                    Path to vmx file     Reset a VM or Team
                         [hard|soft]

suspend                  Path to vmx file     Suspend a VM or Team
                         [hard|soft]

pause                    Path to vmx file     Pause a VM

unpause                  Path to vmx file     Unpause a VM

.

.

.

many more lines of useful output follow.

So the rumors of the demise of nogui are debunked. Shouldn't have put it off so long to test this. Thanks to whomever bumped this thread, and to WoodyZ for the scripting examples.

I've used vmrun in the past but have ignored the "Team" aspect. Need to dig into that a bit more. The only other experience I have with VMware products is ESXI and VMWare Player for Linux and Windows. This has all become more interesting to me since I purchased a Mac Server last year to replace my aging Sun Solaris servers.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

I've used vmrun in the past but have ignored the "Team" aspect.

Just an FYI, VMware Fusion does not support the use of "Team" as Teams are only supported on VMware Workstation.

Reply
0 Kudos
dav0101
Contributor
Contributor

Just wanna share the StartupItem I ended up using.  Was using launchd at first but since I need the graceful suspend on shutdown I used woody's tip on using StartupItem init.d style!

Some tips on stuff that's good to think about along the way.

  • For the vm, do not use the disk-setting "split in 2GB files". Reason is that with many snapshots or a large disk, it's easy to end up with "too many open files" since the mac defaults to 256 for one app, (which is weird behaviour anyway)
  • After rebuilding the disk and cleaning up existing snaps (if any), reboot the vminstance.
  • Do a snapshot when your windows-rig is as you want it, name it xyz_something

So what I do is let it revert to snapshot upon every boot. This to ensure windows doesn't gets some crazy ideas since last shutdown. But also ensure the state is clean even after a power-failure.  (I've seen odd things happen to the image if you just pull the plug)

#!/bin/sh

. /etc/rc.common

VMRUN_BIN="/Library/Application\ Support/VMware\ Fusion/vmrun";
VMX_IMAGE="/Users/foo/Win7.vmwarevm/Win7.vmx";
VMX_SNAPSHOT=march_20;

StartService ()
{
     ConsoleMessage "Starting WinVM..."
     ConsoleMessage "Starting WinVM... reverting to snapshot: $VMX_SNAPSHOT"
     eval $VMRUN_BIN -T fusion revertToSnapshot $VMX_IMAGE $VMX_SNAPSHOT
     ConsoleMessage "Starting WinVM... start $VMX_IMAGE"
     eval $VMRUN_BIN -T fusion start $VMX_IMAGE nogui
}

StopService ()
{
     ConsoleMessage "Suspending WinVM..."
      eval $VMRUN_BIN -T fusion suspend $VMX_IMAGE
     ConsoleMessage "Suspending WinVM done!"
}

RunService "$1"
Reply
0 Kudos
dmouck
Contributor
Contributor

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>Disabled</key>

    <false/>

    <key>KeepAlive</key>

    <false/>

    <key>Label</key>

    <string>com.wkz.headlessvm</string>

    <key>ProgramArguments</key>

    <array>

        <string>/Library/Application Support/VMware Fusion/vmrun</string>

        <string>-T</string>

        <string>fusion</string>

        <string>start</string>

        <string>/Virtual Machines/Windows XP Professional SP3.vmwarevm/Windows XP Professional SP3.vmx</string>

        <string>nogui</string>

    </array>

    <key>RunAtLoad</key>

    <true/>

    <key>UserName</key>

    <string>WKZ</string>

</dict>

</plist>

Note that in Fusion 4, the path to vmrun has changed. It can be found in /Applications/VMware Fusion.app/Contents/Library/vmrun .

Also, I found that for the VM to start up as a service, I had to remove the following lines from the plist:

    <key>UserName</key>

    <string>WKZ</string>
Reply
0 Kudos
WoodyZ
Immortal
Immortal

dmouck wrote:

Note that in Fusion 4, the path to vmrun has changed. It can be found in /Applications/VMware Fusion.app/Contents/Library/vmrun .

Also, I found that for the VM to start up as a service, I had to remove the following lines from the plist:

    <key>UserName</key>

    <string>WKZ</string>

I made the original post on Mar 16, 2011 and it is normal and expected to have to edit/modify various information as things change as with the path to vmrun however as to removing the UserName you should have just substituted your own for mine (again, normal and expected) although keep in mind that this was done on Snow Leopard and if running Lion that may require additional changes as well.

Reply
0 Kudos
davman
Contributor
Contributor

Very Good! Thanks!

Just one little thing to solve for a really perfect work:
when I do user logout from host and re-login again, he guest machine is disabled.
I have to kill the process and re-launch it again.

Is someone knows why? Is there any solution?

I put the main plist file in /Library/LaunchDaemons/ and in /Library/StartupItems/

I put the main bash scripts in /Library/StartupItems/

I put the specific files (for headless start and suspend) in /Users/Shared/VMWare/bin/ (quite next to the VMWare image)

I'm using Lion on host and Snow Leopard Server as Guest.

Thanks to everybody, genius!!!

Reply
0 Kudos
bfly88
Contributor
Contributor

I know I am dragging up an old thread but I have an issue with the behavior of the VM once running. I am using Lion and a StartupItem script with Fusion 4. The behavior is the same if I use launchd.

Problem:

The VM launches perfectly fine and works beautifully. The problem lies when I login to the host system and then logout. When I logout the VM processes are killed effectively doing a force shutdown of the VM. Any ideas what could be the problem? In case it matters, when starting the VM I am getting these errors but the VM runs fine:

Jun  4 08:48:31 server.local vmware-vmx[7906] <Warning>: 3891612: (connectAndCheck) Untrusted apps are not allowed to connect to or launch Window Server before login.

Jun  4 08:48:31 server.local vmware-vmx[7906] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.

_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

Yes, this is an old thread and what was presented here is not officially supported either.  Additionally I'm not in a position at the moment to work with the older version of VMware Fusion or Mac OS X so I really can't do (and honestly don't want to do) any testing with what is a totally officially unsupported manner of running VMware Fusion as I no longer have a need to run any VM's Headless, sorry.

Reply
0 Kudos
bfly88
Contributor
Contributor

FWIW, this is the reason for my issues:

https://developer.apple.com/library/mac/#technotes/tn2083/_index.html

However, this isn't the case (r. 5544764) . This message is really telling you is that you're trying to connect to the window server from the wrong context. You see this message if you try to connect to the global window server service from outside of the pre-login context before the user has logged in; typically this means that you're trying to use the window server from a daemon.

You should not attempt to fix this by convincing the window server to trust your program; doing so will just cause other problems further down the road. For example, if you do successfully connect to the window server from your daemon, you still have to deal with window server lifecycle issues described previously.

Instead, you should fix this problem by changing your code to run in the correct context. If you need to connect to the window server in a pre-login context, create a pre-login launchd agent. For an example of this, see Sample Code 'PreLoginAgents'.

I guess I should have used VirtualBox instead.

Reply
0 Kudos