VMware Communities
sonicbuddha
Contributor
Contributor

Fusion as virtual machine server

I am in a situation in my work environment where I am restricted to Apple hardware and, although I would like to, I do not have access to a Linux box to run VMWare Server. Therefore I would like to set up Fusion so that I can run multiple virtual operating systems upon OS X Server. This leads to several parameters that would make this process easier. I doubt this would be the first time someone has asked these questions so I appreciate being pointed in the right direction.:

1) Running headless

2) Running w/o a user logged in at console

3) Running multiple OS at a time

4) Starting Fusion at boot

5) Starting specific OSes when Fusion starts

6) When running multiple OSes, is it possible to tie a specific OS to a specifc processor?

Thanks

0 Kudos
8 Replies
WoodyZ
Immortal
Immortal

I doubt this would be the first time someone has asked these questions so I appreciate being pointed in the right direction.:

If you doubt this would be the first time any of this has been asked an answered before then why didn't you search the forum first!?

Most if not all of what your asking has been asked and answered before so a search of the Forum using the Community Search text box in the upper right hand corner should yield the answers.

1) Running headless

Have a look at: headless search

2) Running w/o a user logged in at console

Have a look at:

3) Running multiple OS at a time

Have a look at: running multiple virtual machines

4) Starting Fusion at boot

Have a look at: starting fusion at boot

5) Starting specific OSes when Fusion starts

See number 4

6) When running multiple OSes, is it possible to tie a specific OS to a specifc processor?

If there is I'm unaware of it however I believe I've read that you can't.

RDPetruska
Leadership
Leadership

6) When running multiple OSes, is it possible to tie a specific OS to a specifc processor?

This is possible for the Workstation, Server, and Player products, so I assume it is possible for Fusion as well. Add to the vmx file(s) the following lines:

processor0.use = "FALSE"

for each logical processor your host sees (starting with 0). Make sure to set one of them to "TRUE".

0 Kudos
WoodyZ
Immortal
Immortal

Despite adding these lines to the .vxm file the Guest is still using both processors on my MBP so I do not think these settings work in Fusion.

0 Kudos
sonicbuddha
Contributor
Contributor

Thanks for all the help. Sorry that I haven't accessed this thread in a while but I have been able to take some time to come up with what I think is a suitable solution, considering.

What I wanted was a solution similar to vmware-server, which isn't currently available for OS X. So, I cobbled together the recommendations offered here.

Fusion requires a user to be logged in to launch the machines. Afterwords you can kill the gui and the machine continues to run in the background. This is workable, but if your machine hangs up for some reason, there is no console or means of reattaching to the backgrounded machine (that I know of). This didn't seem acceptable, so a user dedicated to running the machines as background processes that could remain logged in at the console was required. This was a security risk I wasn't satisfied with, so, using the command offered in some of the threads listed above, it is possible to return to the login screen if fast user switching is enabled:

/System/Library/CoreServices/Menu\ Extras/User.menu/Contents/Resources/CGSession -suspend

Another thread suggested having a login script launch the machines and then use this command to log the user out. But this meant you couldn't really use this user since every time you logged in as this user, it launched the machines again and logged you out. This eliminated the usefulness of having a "console user". The answer was to have the machines launched at boot and then return to the log in screen. In this way users can administrate the server or log in as a console user and administrate guest machines. This is my start up script, which checks until the vmmanager user is logged in (5 times) and then launches all the machines in a specific directory and returns to the log in screen. Note one caveat: your virtual machines cannot have spaces in their names. I've also used these tags in hopes of a suspend upon shutdown, but it doesn't seem fully successful. Its not a perfect solution, but it works. Comments appreciated. Feel free to use at your own risk; support not supplied.

signal.suspendOnHUP = "TRUE"

signal.powerOffOnTERM = "TRUE"

Before you consider using reading this documentation on how startup scripts work on OS X:

http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/StartupItems.htm...

#!/bin/sh

. /etc/rc.common

StartService () {

ConsoleMessage "VM-Manager: Starting"

for ((count=0; count<6; count+=1)); do

if ( who | grep -qE '^vmmanager.*console'); then

ConsoleMessage "VM-Manager: Starting VMWare Machines"

for machine in /Users/Shared/VirtualMachines/*vmwarevm; do

ConsoleMessage "VM-Manager: Starting $machine"

sudo -u vmmanager -H open $machine

done

/System/Library/CoreServices/Menu\ Extras/User.menu/Contents/Resources/CGSession -suspend

break

else

sleep 5

fi

done

}

StopService () {

ConsoleMessage "VM-Manager: Suspending machines"

killall -HUP vmware-vmx

}

RunService "$1"

0 Kudos
sonicbuddha
Contributor
Contributor

I've been working with killing the gui and logging out instead of leaving the machines running in a user switched out but I've found that, after logging out and then logging back in, the gui window for the machine hangs upon attempting to reattach. I should note here that I am working with terminal based installs only. The machine is still running in the background so it does not seem to be a virutaulization as much as a front end problem. If I suspend and restart the machine or revert to a snapshot when the window is hung, the machine's window becomes responsive again. It seems that there is some connection between the gui and the running machine that exists even when the "head" is killed. When the user logs out, the connection is disrupted. I've been looking for processes, but, at this point, it is not obvious to me what process, lock, or socket is being lost when the user logs out.

Is there a resolution for this?

0 Kudos
admin
Immortal
Immortal

Fusion requires a user to be logged in to launch the machines.

I don't think this is actually true (though the workaround isn't obvious); I haven't personally tried and so can't definitively say. I'll try once I catch up on work and get some free time.

This is workable, but if your machine hangs up for some reason, there is no console or means of reattaching to the backgrounded machine (that I know of).

Reopening the virtual machine should connect to it, but this only works for the user you originally ran the virtual machine with (since it'll still be locked) - it won't work if you ran the virtual machines without a console in the first place. However, Fusion's built-in VNC server may provide some of what you want.

0 Kudos
sonicbuddha
Contributor
Contributor

I would appreciate any work and/or guidance and am available for testing, if you can give me some suggestions. The above script works, but its problematic. I've found ARD can hang up when using the fast user switching logout command, listed above. My workaround has been to send the WindowServer a -HUP and restart the "client", after which I can connect again.

I've experimented with killing the gui and force logging out the user by killing the loginwindow process, but that has its shortcomings as well. Once the user is logged out and then logged in again, relaunching the gui to reattach hangs the gui window and it can only be resumed by putting the virtual machine to sleep and resuming it. Its relatively moot since killing the loginwindow process, which works fine in a normal environment, with auto login the system just bounces back to logging the auto user back in again. I've looked into logging in to the console from the command line and have yet to have sucess.

Bottom line, launching w/o a console user, attaching via VNC, and firewalling the VNC ports I'd use would be what I consider my most acceptable solution.

0 Kudos
admin
Immortal
Immortal

Try

0 Kudos