You might want to allocate less, not more memory and processor cores to the VM. Fusion needs them to function via the host (Mac) OS.
Try it with just one processor core and a minimal (1024 MB) RAM for the guest and see how things go.
Coach300 wrote:
You might want to allocate less, not more memory and processor cores to the VM. Fusion needs them to function via the host (Mac) OS.
Try it with just one processor core and a minimal (1024 MB) RAM for the guest and see how things go.
According to VM guest settings, I am already using one processor core. Are you sure I can use 1 GB of RAM for Mac OS X guests (.7 to .9)? Apple says its minimum RAM requirements are 2 GB of RAM even for old 10.7.
I hadn't fully understood the guest OSs to be MacOSs. But, see what Fusion suggests when you allocate RAM to the guests. Fusion may be what needs the RAM, more so than the guest.
I haven't attempted to ever run a Mac OS as a guest, but on my older (mid 2010) MBP I ran Windows 7 pretty well in 6.02/Mavericks with 1024MB RAM->guest. I didn't change that setting when I started running it on a brand new (6 days old) MBP even though it has 16GB RAM and a quad-core Haswell processor.
Hi
We plan to set up our product buildfarm on Mac mini 2.3GHz Quad Core i7 with 8GB RAM. We would be running the BUILD and TEST. We have two choices:
1. Directly setup everything on the Mac mini itself for Build and Regression test.
2. Create 2 VMs on the Mac mini with VMware Fusion. One for Build and another for Test.
We want to go for #2 as it is always good to have the VMs so that we can take the backup and make multiple copies of it as the setup (installing lot of 3rd party libraries) takes lot of time. The only question was from performance and maintenance point of view. If we allot 2GB RAM for each VMs and disable the XWindow (GUI) on it as we do not need to access the remote desktop on the build VMs.. we can just login with ssh.. then it won't affect the performance, right?
Has anyone noticed any drawback of having VMs on Mac mini?
sandy2010 wrote:
Hi
We plan to set up our product buildfarm on Mac mini 2.3GHz Quad Core i7 with 8GB RAM. We would be running the BUILD and TEST. We have two choices:
1. Directly setup everything on the Mac mini itself for Build and Regression test.
2. Create 2 VMs on the Mac mini with VMware Fusion. One for Build and another for Test.
We want to go for #2 as it is always good to have the VMs so that we can take the backup and make multiple copies of it as the setup (installing lot of 3rd party libraries) takes lot of time. The only question was from performance and maintenance point of view. If we allot 2GB RAM for each VMs and disable the XWindow (GUI) on it as we do not need to access the remote desktop on the build VMs.. we can just login with ssh.. then it won't affect the performance, right?
Has anyone noticed any drawback of having VMs on Mac mini?
My old Mac mini is decent for basic testings in VMs. Bumping 4 GB to 8 GB of RAM helped a lot to avoid disk swapping a lot with its swap. If performance is important, get a faster Mac like the newest Mac Pro with plenty of RAM?
Your configuration will work fine. I regularly run similar configurations (mid-2011 Mini with 4 GB RAM running one Mac OS X Guest VM with 2 GB RAM allocated). If you have both the host and guest doing processor or disk intensive work then things will slow down a bit, but if you are only taxing one or the other things should stay snappy.
Thanks.
How about having 10.8 VM on Mac mini 10.9 and running the build on the VM and regression test on Mac mini? We want to support 10.8 and 10.9 for our binaries.
Building in a VM and regressing on the hardware will probably work fine. Unless you're compiling millions of lines of code your build should be pretty snappy. You should consider spooling up the VM specifically for building and shutting it down afterwards so that all hardware can be dedicated to regression most of the time.
Build servers and QA labs are like pets: you have to raise them from infancy and learn their individual quirks. No amount of reading or preparation can stand in for what you will learn actually doing it. Set up the machine the way you think it should be and try it out. If it's rubbish then try again until you get it right. Even once you've gotten it right things will evolve over time until today's solution looks terrible and it's time to build a new one. Good luck!
Thanks.
I have setup the 10.8.5 VM on 10.9 Mac mini using VMware Fusion 6.0.2. There is a directory on the host that is shared with the VM.. and I can see it in "/Volumes/VMware Shared Folders" directory.. The build script is run from the host.. It extracts the source archive in this shared directory, connects to the VM (passwordless) and build the sources on the VM.. But, I see that configure/build fails with either "Input/output error" while creating config.log/config.status or "Cannot allocate memory" for Makefile..
This setup has worked fine with our previous builds when the VMs were Linux and Windows. This is the first time, we have OS X as guest and seeing lot of issues.
I see that the second type of error (Cannot allocate memory) for Makefile.xxxx occurred because it was actually a symlink to another Makefile.. but this link was not created.. When I Manually tried to create it on the VM, then it says 'permission denied'.
I then shutdown the VM and added the following line in .vmx file:
sharedFolder0.followSymlinks = "TRUE"
and booted the VM again.. But, I see the same issue..
BTW, we never had to add the above line for CentOS and Windows VMs in Fusion 4.1.3
Started a new thread for this with the correct subject..
I've had intermittent problems with the shared folder facility on VMWare Fusion so I just avoid it completely and move files around via the network using command line tools and shell scripts. rsync has all the options necessary to keep/transform symlinks and you should be able to get a clean, build-able copy of your source using it.
Zack
Thanks..
Actually, the symlink is created during build.. We need to get this working.. Moreover, I do not see any documentation on this..
