vSphere – Page 83

Apple Mac Pro 6,1 (black) officially supported on ESXi 5.5 Update 2 Patch03

10.16.2014 by William Lam // 44 Comments

The much anticipated support for running vSphere on the latest generation of the Apple Apple Mac Pro 6,1 (black) is finally here with the release of ESXi 5.5 Update 2 Patch03. Due to unforeseen issues, it has taken a bit longer than expected to get the Apple Mac Pro certified, but VMware Engineering has been working hard to get all the bugs fixed and triaged with Apple and you can now run the latest release of vSphere on the Apple Mac Pro 4-core, 6-core, 8-core & 12-core configuration. I also would like to point out that when the next release of vSphere (.NEXT) is available, the Apple Mac Pro will also be certified and supported.

UPDATE (10/31) - Take a look at this blog post here for detailed instructions on installing ESXi 5.5 Update 2 Patch03 on the Mac Pro 6,1.

You can find the ESXi 5.5 Update 2 Patch03 (ESXi550-201410001) download here using Image Builder to author and ISO image which is equired to install ESXi on the new Mac Pro.

The VMware HCL has also been updated to reflect this new update:

Note: The VMware HCL currently lists 5.5 U2 as the supported release, but you will specifically need ESXi 5.5 Update 2 Patch03 for this new hardware support. I am hoping to get this further clarified on the HCL.

Here is a screenshot of the latest ESXi 5.5 Update 2 Patch03 running on an Apple Mac Pro 8-Core system courtesy from VMware Engineering:

How to evaluate the vSphere VCSA Beta running on VMware Fusion & Workstation?

10.13.2014 by William Lam // 17 Comments

If you are taking part in the vSphere Beta (available to public to sign up but still under NDA), you may have recently noticed a new milestone release (RC) that has been made available for download. Having been a long time Beta participant when I was customer and still continuing to do so in my current role, the best way to evaluate and test new VMware software is to of course run them on top of vSphere! I know this may not be an option for everyone and the next best thing would be to use VMware Fusion or Workstation.

For those of you who have tried to run the vSphere Beta of VCSA on VMware Fusion or Workstation, you may have found that it does not work as there are some input parameters that are required as part of the new VCSA deployment. These parameters leverages OVF properties which are currently not supported in VMware Fusion and Workstation and therefore the new injectOvfEnv option in ovftool can not be used.

Having said that, VMware Engineering is quite aware that this can be challenging for many customers as well as VMware Employees who make use of Fusion and Workstation on a daily basis. That is why they have built the VCSA to be quite flexible to support both vSphere as well as Fusion and Workstation, however the process may not be completely obvious for the latter. If you inspect the latest VCSA Beta OVA, which you will need to extract from the ISO, you will notice a series of "keys" that begin with guestinfo which is just leveraging custom key/value pairs for the OVF environment.

Ideally, these are passed in from the OVF Properties using either the vSphere Web Client or the new VCSA deployment tool. However, due to the lack of OVF Property support, it can also be passed in through the VMX file of the Virtual Machine.

Here are the steps to deploy the VCSA Beta using either VMware Fusion or Workstation:

Step 1 - Download the VCSA Beta which is available as an ISO

Step 2 - Extract the contents of the ISO and add the .ova extension to following file located in vcsa/vmware-vcsa (this is the VCSA OVA)

Step 3 - Upload the OVA using either VMare Fusion or Workstation (you can either double click or just go to File->Open) but make sure you do not power it on after deployment. (this is very important)

Step 4 - Locate the directory in which the VCSA was deployed to and open up the VMX file and append the following (make sure to change the IP information and passwords based on your environment):

guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.addr = "192.168.1.90"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.1"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.time.tools-sync = "True"
guestinfo.cis.appliance.ssh.enabled = "True"

Note: The example above is a very basic VCSA deployment which should suffice for the majority of you. If you wish to deploy a more complex scenario, you can inspect the VCSA OVA for additional parameters and see their expected values.

Step 5 - Once you have saved your changes, go ahead and power on the VCSA. At this point, the guestinfo properties that you just added will be read in by VMware Tools as the VCSA is booting up and the configuration will begin. Depending on the speed of your hardware, hopefully in a very short amount of time you will have a fully configured VCSA that is ready for your evaluation and testing.

Here is a screenshot of running the VCSA Beta on both VMware Fusion and Workstation:

If you wanted to take this one step further and automate the entire deployment, you can leverage the ovftool to deploy the OVA as shown with the Fusion example below:

'/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/ovftool' --name=vmware-vcsa --acceptAllEulas --allowExtraConfig /PATH/TO/VCSA/OVA '/Users/lamw/Documents/Virtual Machines.localized'

and then append the specific configuration using either an echo or here-statement. You can also do the same on Windows leveraging either plain Windows Bat script or PowerShell.

Hopefully for those of you who only have access to Fusion or Workstation, you can now also take part in the vSphere Beta if you do not have a vSphere lab that can be used. I would also recommend checking out the vSphere Beta Community as there is a new contest that launched today for finding bugs in the latest RC release. Not only can you help improve the product through your feedback, you can also win some some $$$ in doing so!

Community stories of VMware & Apple OS X in Production: Part 9

10.09.2014 by William Lam // Leave a Comment

Company: Connell Insurance
Software: VMware vSphere
Hardware: Apple Mac Mini

[William] - Hi Bryan, thanks for your time this afternoon. I know you have been pretty busy these last couple of weeks and I am glad we got some time with you to chat about your environment. Before we get started, can you please introduce yourself and what you are currently responsible for?

[Bryan] - Hi William. Thanks for the interest! My name is Bryan Linton. I'm currently the IT Director for Connell Insurance, an independent Insurance Agency in Southwest Missouri. We’ve been around for a long time but have been growing more rapidly in recent years. We currently have around 40 employees.

We have most of our systems in a secure off-site datacenter, but I still need some support systems onsite, and that's where your project bringing together inexpensive Mac Minis with ESXi caught my attention.

[William] - Can you tell us a bit more about your Mac Mini infrastructure? What is the hardware and software configuration and the type of workload you are currently running on them?

[Bryan] – First of all, I didn't buy the "server" versions of the Mac Mini - I just ordered the standard Mac Minis with stock RAM and storage. My only exception to going stock was on the CPU. For that, I went all-out and ordered the i7 quad-core processors since I knew I’d be using them as servers. But I bought a large SSD, a data doubler kit that allowed me to mount the second hdd, and 16GB of RAM, and installed all those myself, since it was cheaper than spec’ing it that way from Apple.

I also bought a 16GB low-profile USB flash drive to use as my install point and boot device. It's working fine booting and running ESXi 5.5. I’ve always used ESXi embedded on my servers going all the way back to version 3.5, so I was already comfortable and familiar with booting and running ESXi from a flash drive. So to summarize the hardware, that's a quad-core i7, 16GB of RAM, a 1TB spinning HDD and a 500GB SSD as datastores, booting ESXi 5.5 from a tiny flash drive that barely protrudes from its USB port.

On the software side, I downloaded your turnkey ISO for ESXi 5.5 for the Mac Mini. Your advice to enable support for the Thunderbolt Ethernet adapter was easy to follow, and that gave me two 1GigE NICs for whatever I need. The installation was about as simple as you can get.

My workload currently is very light. We just opened a branch office, so that’s where I’m using the Mac Mini. I installed a DC for the site, and have set up just one other support machine so far. It runs the management software for our video surveillance, alarm system remote administration, and the controller software for my WiFi access points. I’ll probably add (or move) other support roles to this machine before long. It's not working that hard and to be honest, is probably faster than the 6-year-old Xeon-based server currently filling the support-system role inside our main office. The two offices are very well-connected, so I can move around support systems almost without concern for which site uses them most. So I do foresee loading up the Mac Mini with more work.

Here is a picture of Bryan's setup:

[William] - What was the deciding factor on choosing a Mac Mini versus Mac Pro or any other platform? Given the Mac Mini is consumer grade hardware and is currently not a supported platform, were there any architecture decisions you had to make on the infrastructure or application side to accommodate for this fact?

[Bryan] – The Mac Pro is fantastic hardware, so if you need heavy-duty power behind your VMs it's certainly worth looking at. But if you really beef up a Mac Pro you're back in the cost realm of what server hardware typically costs. I honestly didn’t look at the compatibility or support of the Mac Pro with ESXi because we didn't need that kind of power for our new branch office.

As for other platforms considered, we’re largely a Dell shop. We use their small-form-factor desktops for our user workstations. I considered using one of our retired workstations as a “server”, but was afraid it would be too slow, even with an SSD, and it didn't have any more RAM capacity than the Mac Mini. Plus it's obviously bigger and less power-efficient, and it’s probably less hardware-compatible with ESXi. That’s why we ultimately chose the Mac Mini.

The main limitation of the consumer-grade hardware in the Mac Mini, for us, was RAM. The Xeon processors in my "proper" servers running in our CoLo aren't ever taxed nearly as much as the other compute resources, so to me the i7 quad-core CPU seemed more than adequate. Having the RAM maxed out at only 16GB, though, made me put extra thought into how I can make the best use of ESXi’s transparent page sharing between VMs. We’re mostly a Windows shop, so it made sense to me to standardize on a single Windows Server version for a given Mac Mini, and try to keep all those VMs at the same patch level. That way, the odds are better that many of the core OS pages in RAM will be identical, meaning the use of TPS will increase, and more RAM will be available to run applications (or even more VMs). We chose Server 2012 Standard as the go-to Windows server OS, and I look forward to loading up the Mac Mini to see just how far ESXi’s advanced memory management techniques will let me push it.

The other constraint was network connectivity. For example, I have just 2 NICs, and I'm currently in the process of working out a backup strategy. I think I'm going to use a backup appliance running on the Mac Mini with a relatively inexpensive NAS as the backup destination, and if needed I can dedicate a physical NIC to that, but with only two NICS, I have to think a lot about network traffic management. I have a couple of other ideas that involve using a thunderbolt dock and/or USB 3.0 NICs to increase the number of USB ports and NICs available to me. The big question there is driver support in ESXi, but I haven’t yet researched or tested those ideas at all.

[William] - You mentioned the current workload is pretty light and you plan to deploy additional Window Servers. What type of workloads will these Virtual Machines be running? Do you see a need to scale up your Mac Mini infrastructure from what you have today?

[Bryan] - I'm not yet ready to put critical production data on them. Not until I have a better feel for what backup looks like, and until I really push the limits of the hardware resources. But support systems like I mentioned above - Wi-Fi controller, NVR for surveillance (with the data stored off-box), things like AV management, Spiceworks, syslog servers, additional DCs to provide a global catalog server, a DFS namespace server, and maybe a replica file server synced with DFS replication are all good possible candidates for running on a Mac Mini.

We have an email archiving system that has to run somewhere. Its data is stored on a remote share and DB, but the processing can happen anywhere, and Mac Mini will handle it fine. That lets me keep resources free for the mission-critical apps that run on my "real" servers that DO contain our critical production data. If I can improve user experience by offloading non-critical support systems to the Mac Mini, there's less resource contention on my vCenter-managed hosts, and user responsiveness should benefit from that.

I also have software firewalls that I use to create a "double-router, Dual-NAT" environment so I can run or build machines in a test, isolated environment, with internet connectivity, with the IP addresses they use (or will use) in production without conflict. They run in perfect isolation. The Mac Mini can host those software firewalls along with any machines that are either being built, or perhaps being restored from backup for exploratory purposes, or even for testing of upgrades or new software in a mirror environment before it goes into production.

As for scaling up, so far I haven't considered adding a Mac Mini ESXi host to my vCenter environment. But I might consider that if two things happened:

Apple starts supporting more RAM in the Mac Mini.
VMware decides to support the Mac Mini hardware officially.

Actually, as I get more time and experience using this setup, number 2 may diminish in importance. Time will tell.

[William] - Your last reply was quite interesting. You mentioned you have not considered adding your Mac Mini ESXi hosts to vCenter Server? I’m curious to hear why the support of Mac Mini would dictate the ease of centralize management? Is it from a support standpoint that you did not want to do this or additional licenses?

[Bryan] - My Dell ESXi servers are managed by vCenter, but I have three of them, which is my license limit currently. If I had a free slot for the Mac Mini I'd certainly use it. But I'd have a hard time justifying the purchase of *additional* licenses for vCenter to bring machines under management that aren't even officially supported. But yeah - if I had the licenses I'd have no hesitation in managing them via vCenter. I get around it currently thru the use of shared data stores.

[William] - Bryan, it was really great chatting with you and thanks again for sharing your experiences on how you have leveraged VMware and Apple Mac Mini’s in your production environment. Here is the last question that I have asked all my past interviewees, do you have any final advice or words of wisdom for someone looking to embark on a similar journey? Any particular resources you would recommend for someone to start with?

[Bryan] - Well, virtuallyGhetto is THE place to go for those resources. Without your pages I would not have made the leap. My advice would be: Don't expect it to do what a $5,000 investment will do. If you plan to run mission-critical apps or host production data, KNOW what your backup and recovery process looks like and TEST it.

If you understand you're striking out somewhat on your own, and you don't mind being a pioneer for the fun of it, do your due diligence, and if it seems like a fit, enjoy it! It's honestly fun to show people my rack. "That's our server. It's running ESXi 5.5." "...Really?!?"

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.