After sharing VMware's story on how they leverage Apple Mac Mini's for their OS X build infrastructure, I thought it was only fair to reach out to Yoann Gini to see if he would also like to share some of his experiences working with VMware and Apple OS X. I was able to catch up with Yoann and you can find our chat transcript below.

Company: Fortune 500
Product: VMware vSphere
Hardware: Apple Mac Mini

[William] - Hi Yoann, I appreciate you taking some time out of your evening to share with us some your experiences working with VMware ESXi and Apple OS X. Your recent tweet was really the motivation behind this series, so thank you. Before we dive in, can you quickly introduce yourself?

[Yoann] - I’m a french computer scientist, working as a freelance consultant and trainer on Apple products for Enterprise and Education. I also work on network architecture and security, doing reverse engineering for fun in my spare time. All Apple OS X focused. You can find more details on my website.

[William] - Awesome. So, based on your tweet, I assume you have some experience working with Mac Mini's and VMware vSphere? Can you share with us some of the customer environments you have been in and how you have solved the challenges leveraging vSphere?

[Yoann] - Yes, I have two main setup with vSphere at this time (and my lab). One with 10 Mac Minis hosting up to 20 OS X VM which is basically building agent for an iOS forge for a Fortune 500 company (I can’t tell the number of iOS project build on it). The other one with three Mac Mini hosting two VM, one for Open Directory, DNS, File Sharing and the other for e-mail serving around 500 users.

[William] - Wow, Mac Mini's really being used in a Production environment! How cool! What was the reason for selecting the Mac Mini versus an Xserve or Mac Pro? How did the customer react to using a non-supported platform? Were there any challenges?

[Yoann] - When these two projects started, the Xserve was already stopped, so it wasn’t an option. For Mac Mini vs MacPro, it was only a matter of reasonable risk versus unreasonable cost. Mac Mini is unsupported by VMware and Apple as a virtualization node, but it’s really cheap and, it works. Mac Pro is supported, but it so expensive with the following challenges:

- don’t fit in a server rack
- can’t be exploited at 100% (especially the new Mac Pro with super duper graphical card totally useless for most server jobs)
- really can’t be exploited at 100% if you read the Apple EULA who seems to don’t allow us to run more than 2 (or maybe 3) Apple OS X per Mac hardware…

The last point is that the most important decision for one of my customers: buying expensive hardware officially supported can be OK if at least we can run a lot of Apple OS X VM on it. But the Apple limitation is a real PITA when you try to develop Apple OS X Server and Virtualization in the Enterprise. It so stupid that in at the end, customers prefer to place the same amount of money in multiple Mac Mini instead of one good Mac Pro. It allows hardware redundancy for the same price + an iSCSI storage and it leverage the risk due to unsupported hardware.

For me, the real challenge is here, the legal imbroglio with Apple legal things (and contacting Apple SE about this subject does not help, the only answer is, ask your legal department).

They also have other challenges: IT against everything with an Apple on it. It always fun to start a meeting telling the team in charge of Virtualization that they will have to support a non-supported small form factor system without a redundant power supply. But we always find a solution, Apple Consultants are used to this situation. It's a common denominator to all OS X and iOS deployment in enterprise.

[William] - Interesting, so it looks like the Apple EULA played a pretty large role in the organization's decision. At this point, you have selected the hardware platform and you knew you were going to Virtualize on vSphere. Can you talk a little bit about the applications, was this a new environment you were building out or was this a migration from an existing infrastructure?

[Yoann] - For the iOS forge, it was a new environment. The system was a Java based application and a pilot has been done in the past. So blank page here. A project leaded by company needs increasing with iOS software demand. For the more traditional server setup with all internal services like directory service, DNS, mail, etc. It was an existing setup on dying Xserve. We’ve done the migration on vSphere to take away all hardware problem (we’ve got more and more disk failure and random problem on the Xserve in the end).

[William] - For the environment which you had to migrate your existing Apple OS X systems running on the Xserve, what type of tools did you leverage? Were there any tips and tricks you used or things people should look out for if they are attempting a similar migration?

[Yoann] - We’ve taken the opportunity of hardware to Virtualize the systems and  migrate to a newer system version. So we’ve just followed the recommended migration path in this situation. We’ve installed a new system on the vSphere setup and then we’ve imported our data inside with a combination of directory export/import feature and rsync for files.

It was really simple with Apple OS X Server, you just have to ensure that your directory service is there and then put all the data in the good place before starting every services.Another option is use common Apple OS X imaging system like DeployStudio or Carbon Copy Cloner to create a image from your existing system and deploy it on your virtual system.

Is not as simple as vCenter Converter but when we’ve done our “state of the art” migration, we’ve got only a 5 min shutdown on a Sunday morning. All linked service like TSE, Citrix, Cisco Call Manager and custom app haven’t seen any thing. Only a reboot needed for Windows based system.

[William] - Very nice, it sounds like you got the process pretty much nailed down. How about after everything has been migrated over to vSphere. How does the customer manage the environment, are they running vCenter Server or are these stand alone systems?

[Yoann] - In this setup, we have a vCenter Server and we use the vSphere Web Client to handle it. By the way, it work like a charm from Safari on OSX, no more needs of Windows VM on our Mac to manage the setup and create new VMs.

[William] - I am with you on that, I too used to run a Windows VM just to use the vSphere C# Client. I’m glad I can use the vSphere Web Client on my Apple OS X system to manage my vSphere environment. In terms of Apple OS X guest management, how do you go about handling that and how do you go about provisioning new Virtual Machines?

[Yoann] - Just like any other Mac hardware, since ESXi supports NetBoot, I can use my existing provisioning system for free. I know that vSphere include some provisioning system to create VM on the flight when needed but I didn’t have the time to play well with it. At the end, Apple OS X VM are just like real Mac with HA in addition, I use all pre existing system without a change. It can even simplify my deployment (no need of Xsan and Load Balancer for HA for example).

[William] - Yoann, these are some great tips! I wanted to thank very much for taking the time and sharing with us your experiences with running Production Apple OS X workloads using VMware vSphere and Apple Mac Mini’s. Before I let you go, I wanted to ask if you had any recommendations for others looking to either Virtualize their existing Apple OS X deployments or looking to building out a new environment using VMware?

[Yoann] - Yeah, talking about HA, it remind me existing setup I have. I have some customer setup I’ve created and I still maintain who use Xsan (the Apple’s cluster file system) with Barracuda Load Balancer in front of two or more OS X Server to handle HA for all services (web, file sharing, databases, etc.).

It works but it’s hard to maintain and definitively not accessible for un-experienced system administrators. If I had to do it again, this kind of setup will end directly on a vSphere system with Fault Tolerance and things like that. It will be cheaper in so many ways (iSCSI instead of Fibre Channel, less time consuming, no need to have advanced knowledge on all network protocols, no need to play with clustered system like MySQL Cluster who’s a really PITA to make it work, etc.).

I also considered deploying free ESXi for all new setup, whether it is a Mac Mini or Mac Pro. The only challenge is that there is no vCenter Server with Free ESXi and you would need a Windows VM to be able to use the legacy vSphere C# Client. If you want or need to use the vSphere Web Client, you would need a vCenter Server license. However, the vSphere Essential Kit is not that expensive and it make sense for SMBs.

With this kind of a setup, it is really easy to manage: simple to deploy a new VM, simple hardware redundancy and can easily be expanded in the future. Keeping everything simple. Need to add a Windows server for accounting? Add a VM. Need HA? Add a Mac Mini and iSCSI storage. No service interruption.

If you are interested in sharing your story with the community (can be completely anonymous) on how you use VMware and Mac OS X in Production, you can reach out to me here.

 

One thought on “Community stories of VMware & Apple OS X in Production: Part 2

  1. “if you read the Apple EULA who seems to don’t allow us to run more than 2 (or maybe 3) Apple OS X per Mac hardware”

    I had to go back to the SLA (e.g. for Mavericks http://images.apple.com/legal/sla/docs/OSX109.pdf ) to check this. And I’m not 100% sure that that IS what it’s saying. § 2.B.iii reads to me like it’s saying that for every license of OSX you get via the App Store you are permitted to run 2 more virtualised copies. not that that is the limit of virtualised machines per machine, but that you get to copy the OS install twice in to VMs.

    i.e. With a volume or maintenance license I think you can run more than 2 OSX VMs per Apple device

Thanks for the comment!