Fusion 6 - Auto start virtual machine broken again? WTF?

[xray64]

I hope this is user-error on my part, but it seems the auto start of virtual machines is once again broken!

I have a virtual machine marked to start automatically, but it ONLY makes it to initial launch screen (black screen with big play button). It requires me to actually click the big PLAY button to start the virtual machine.

I know this feature was once removed and only after much bitching from the community here was it brought back.

Thanks.

Ironically, we went through this in 2011 - Autolaunch of VMs with Fusion 4

[ShaddamIV]

Double-clicking the virtual machine's file itself (the .vmwarevm file) causes Fusion to start, and the VM to start with it.

I'm confused.

[ln045]

I am running Mavericks, fusion 6.02 and Windows 8.1. Macbook pro with external monitor. VMware fusion on the external monitor.

Auto start does not work in full screen but does on single window.

Don't know if that helps anyone?

[admin]

Also, according to Apple engineers, doing anything to any Preferences plist file directly - like editing it or deleting it - will not work as of 10.9 (and was unlikely to work before that.) It's just the persistent storage for the actual data that's kept in memory. The 'defaults' tool changes that data which then gets pushed to disk at some point in the future.

Think of it as editing a vmx file for an open VM - the vmx doesn't know about the changes and will overwrite it with the in-memory data.

(I have no idea why I have different fonts here!)

Double-clicking the virtual machine's file itself (the .vmwarevm file) causes Fusion to start, and the VM to start with it.

Double-clicking a VM in the Finder tells Fusion to open it and power on; it has nothing to do with autostart.

Auto start does not work in full screen but does on single window.

That's strange. In your System Prefs > General, do you have "Close windows when quitting" on or off, and if on, do you have your VM windows open or closed when you quit?

[WoodyZ]

lrucker wrote: The 'defaults' tool changes that data which then gets pushed to disk at some point in the future.

Think of it as editing a vmx file for an open VM - the vmx doesn't know about the changes and will overwrite it with the in-memory data.

You're telling me something I already know as I do read the OS X Man Pages!   Aside from that, it's common sense that one only modify settings via alternate methods when the Target is not running.  BTW  defaults writes to disk are usually done in real time, the main thing it to not use it on an open file unless necessary and then use appropriate methods to push the changes to memory when/where applicable!  In a case such a with VMware Fusion one should only use defaults when it's not open. 

[WoodyZ]

I'd also like to point out that even though ShaddamIV had toggled the state of the "Start automatically when VMware Fusion launches" check box nonetheless it apparently had not written to the powerOnAtStartup.cfg array in the com.vmware.fusion.plist file as it should have so there is definitely an issue and he is not the only one with that issue.  My suggestion of using defaults to write to the powerOnAtStartup.cfg array com.vmware.fusion.plist file was meant to see if that would make any difference having the value present and it didn't which furthers the reasonable assumption that there is a bug in VMware Fusion regarding this feature!

[admin]

Mac apps don't write to the plist file, they set NSUserDefaults; they have no control over when that gets pushed to the plist and looking in there doesn't tell you what the actual state of the defaults are. That's why I mentioned it above; the different behavior in 10.9 has come up frequently on the Apple devforums.

[ShaddamIV]

Well, Fusion seems to *write* a plist file - at least, when I delete com.vmware.fusion.plist from the preferences folder (while Fusion is not running), and then I start Fusion, *and then the VM*, it creates a new plist file.

[ShaddamIV]

My VM is now auto starting again. I have no clue why. I had repaired permissions according to WoodyZ's suggestion before, and now I've been repairing them after having started from the recovery partition. However, Disk Utility didn't tell me it had fixed permissions on any Fusion related files.

Ok, it's running again and I'm happy. But this being a digital machine, I would expect something to consistently work - or not. I'm not so sure about machines that change behavior without my having any clue as to why.

Thank you for all the support.

[ShaddamIV]

Grrr. The VM stopped auto starting yesterday. This is really bizarre. The only thing I can think of that made a difference is that I had removed the Dock and Spaces plists over the week-end, and yesterday actually set some preferences in Spaces - after which the VM stopped auto starting. This is bizarre. I'll delete the Dock and Spaces plists again, and see whether that makes any difference, and report here.

[ShaddamIV]

Yup. Spaces plist is the culprit (~/Library/Preferences/com.apple.spaces.plist). After deleting it, and then rebooting, my Fusion VM auto-starts up again.

Wow.

[WoodyZ]

lrucker wrote: Mac apps don't write to the plist file, they set NSUserDefaults; they have no control over when that gets pushed to the plist and looking in there doesn't tell you what the actual state of the defaults are. That's why I mentioned it above; the different behavior in 10.9 has come up frequently on the Apple devforums.

First of all I'm not using OS X 10.9 Mavericks as a Host nor is everyone else either and regardless prior to OS X 10.9 defaults did write immediately to disk as I can use defaults to set a target VM to start automatically and then immediately open VMware Fusion and the target VM starts.  While this behavior may have changed in OS X 10.9 the write still occurs however the synchronization can occur moments to minutes later.  I've been using defaults to manipulate .plist files for  the last 7 years and have not had any issues although I guess I'll see exactly how things have changed in OS X 10.9 as I start to use it.

As far as NSUserDefaults is concerned saying "Mac apps don't write to the plist file, they set NSUserDefaults;" is antics with semantics and if one does not want to wait then using - (BOOL)synchronize; is probably the way to go.