mac

The ability to perform an ESXi Scripted Installation over the network has been a basic capability for non-Apple hardware customers since the initial release of classic ESX. However, for customers who run ESXi on Apple Mac Hardware (first introduced in vSphere 5.0), being able to remotely boot and install ESXi over the network has not been possible and customers could only dream of this capability which many of us have probably taken for granted.

Unlike traditional scripted network installations which commonly uses Preboot eXecution Environment (PXE), Apple Mac Hardware actually uses its own developed Boot Service Discover Protocol (BSDP) which ESXi and other OSses do not support. In addition, there are very few DHCP servers that even support BSDP (at least this may have been true 4 years ago when I had initially inquired about this topic). It was expected that if you were going to Netboot (equivalent of PXE/Kickstart in the Apple world) a server that you would be running a Mac OS X system. Even if you had set this up, a Netboot installation was wildly different from a traditional PXE installation and it would be pretty difficult to near impossible to get it working with an ESXi image. With no real viable solution over the years, it was believed that a Netboot installation of ESXi onto Mac Hardware just may not be possible.

tl;dr - If you are interested in the background to the eventual solution, continue reading. If not and you just want the goods, jump down a bit further. Though, I do think it is pretty interesting and worth getting the full context 🙂

Over the last couple of weeks there have been several reports coming in from customers that the local SSD device found in newer Apple Mac Pro 6,1 were no longer being detected by ESXi. Starting with ESXi 5.5 Patch03 and ESXi 6.0, the Apple Mac Pro 6,1 was officially supported but it looks like the latest versions of the Mac Pro 6,1 that are being shipped contain a slightly different local SSD device which is not recognized by ESXi.

This was not the first time that this has happened, when the 2014 Mac Mini were first released, they too had a similar issue in which a custom VIB was required to get the internal device to get recognized by ESXi. There is an internal bug (PR 1487494) that is currently tracking the issue and if you are also experiencing this problem, please file an SR and have the GSS Engineer attach your case to this bug.

In the meantime, there is an unofficial workaround which was discovered by one of my readers (Mr. Spock) that by installing the community SATA-XACHI VIB over on Andreas Peetz VIB Depot site, both ESXi 5.5 and ESXi 6.0 will then recognize the local SSD Device. You will need to either use VMware Image Builder or Andreas ESXi Customizer tool to create a custom image if you decide to install ESXi directly on the local SSD device. I personally would recommend installing ESXi on USB device, this would allow you to install the VIB as a post-installation and not requiring a custom ESXi image.

This week I learned about a really cool use case from one of our customers who is using vCloud Director to provision Mac OS X virtual machines to their end users both from a development standpoint but also for troubleshooting and demo purposes for their field and QA organizations. Instead of having to manage hardware assignment across large user base, they have built a completely self-service environment for requesting access to Mac OS X VMs, which I thought was pretty neat.

One issue that they were running into was that when they deployed a Mac OS X VM from their vCD Catalog which is a clone operation, they found that the cloned instances contained the exact same serial number as the source VM and that was giving them some problems. I had pinged a few of our engineers to see if they had any ideas and it turns out that the Mac OS X serial number is generated based off of the uuid.bios property of a VM.

Once I found this out, I knew the exact problem because this was something I had seen before when I had worked with vCD. When deploying a vApp from a Catalog in vCD, the bios.uuid property of the VMs are all kept identical and this would explain why the serial number was the same. This behavior is documented in this VMware KB 2002506 and it also includes a solution to the problem. Once the customer made the change, they were now able to deploy new Mac OS X instances with uniquely generated serial numbers. For regular vSphere or Fusion environments, when cloning a Mac OS X VM, the serial number should always be unique as this problem is only specific to vCD. I should also note that once the serial number has been generated, changing the existing bios.uuid will not force the serial number to change.

Last year, a standalone Virtual Machine Remote Console (VMRC) was released for Windows as part of vSphere 5.5 Update 2b which provides an alternative way of launching the VM console due to NPAPI deprecation. There was of course a huge request for Mac OS X support and the VMRC team has been working hard and today I am please to announce that standalone VMRC is now available for Apple Mac OS X which you can download using the following URL: www.vmware.com/go/download-vmrc

Note: Mac OS X 10.8 or greater is required to use the new Standalone VMRC. The release notes will be updated to reflect this requirement

There are currently two methods of launching a remote console to a Virtual Machine using the vSphere Web Client as seen in the screenshot below:

Using HTML5 VMRC simply by clicking on the thumbnail preview

Using the new Standalone VMRC by clicking on the "Launch Remote Console" link

When using the Standalone VMRC method, instead of opening the VM console in the browser, it will launch the native VMRC application on your system whether that be Windows or Mac OS X. All basic functionalities of the Standalone VMRC is available as you would expect such as power operations, device management, etc.

Note:There is not a specific version of vSphere that is required to directly launch the Standalone VMRC. However, to launch it within the vSphere Web Client, you will need vSphere 5.5 Update 2b or greater.

The other great thing about the Standalone VMRC is that it can function without vCenter Server and the vSphere Web Client and you can actually use it to connect to VM directly on an ESXi host. To use the VMRC without the vSphere Web Client, you will need to construct the VMRC URI which looks like the following:

vmrc://clone:[TICKET]@[HOST]:[PORT]/?moid=[VM-MOREF]

where TICKET is obtained by calling the AcquireCloneTicket() method using the SessionManager in vCenter Server. The HOST will either be the Hostname/IP Address of vCenter Server and the PORT should be default to 443 and you will need to specify the VM MoRef ID. In the case of a standalone ESXi host, you would just change the HOST property. If you do not wish to use the clone ticket, you can also just provide the following URI which will prompt for your ESXi credentials

vmrc://@[HOST]:[PORT]/?moid=[VM-MOREF]

Once you have generated the VMRC URI, you MUST launch it through a web browser as that is how it is passed directly to the Standalone VMRC application. In my opinion, this is not ideal especially for customers who wish to automatically generate this as part of a VM provisioning workflow to their end users and not having to require a browser to launch the Standalone VMRC application. If you have some feedback on this, please do leave a comment.

In the mean time, a quick workaround is to use the "open" command on Mac OS X along with the VMRC URI which will automatically load it into your default browser and launch the Standalone VMRC application for you.

open 'vmrc://clone:cst-VCT-52e44ad7-712f-9f45-a9ee-13ec6a74acaf-[email protected]192.168.1.60:443/?moid=vm-18'

UPDATE (05/31/15) - If you are connecting directly to an ESXi host you can either use the vSphere API to query for the VM MoRef ID or you can easily pull it by running the following command directly in the ESXi Shell:

vim-cmd vmsvc/getallvms

I am sure there are probably a few of you asking, what about for Linux users? Well, you can probably guess what is being worked on next 😉

There was a lot of buzz this week on the announcement of the first vSphere Beta that is available for anyone to sign up for (still a private Beta with NDA rules), however one announcement that was probably missed is that the folks over on the VMware Fusion team just released their second Tech Preview of VMware Fusion (Build 1943533). Why is this such a big deal? Well, it includes one very exciting new feature that I have been asking for a awhile now, which is the ability to connect to an ESXi host or vCenter Server using VMware Fusion! VMware Workstation has had this feature for awhile now and I have been hoping the Fusion team would eventually implement something similar and It looks like they have finally answered 🙂

You now can connect either a Workstation, ESXi host or vCenter Server using VMware Fusion! If you are like me who primary uses a Mac and you do not want to run a single Windows VM just to be able to use the vSphere C# Client, you can now use VMware Fusion to connect to a vSphere system and perform some basic VM operations, which includes managing Virtual Hardware 10 VMs. You can even use this latest version to connect to the beta version of ESXi host.

Under the File menu, there is now a new option called "Connect to Server" or you can use Command+K for keyboard shortcut.
Here is a screenshot of connecting to a Mac Mini running ESXi 5.5:

Here is screenshot of connecting to one of my remote vCenter Servers:

As you can see this is a super handy feature and you can also have multiple connections to various vCenter Servers, ESXi hosts including Free ESXi! This alone is worth grabbing the latest Tech Preview of VMware Fusion! I can not wait for this feature to be officially released with VMware Fusion, this is going to be a must have feature for any VMware/Apple user!

Here is an exclusive for my Twitter followers! Last week I had the chance to catch up with Simon Bennett, Product Manager for both VMware Fusion & VMware Workstation and just chat about some random topics. Simon was kind enough to offer me seven free VMware Fusion 6 Professional license keys, each valued at $129 USD. I personally already had a copy of VMware Fusion which I use all the time on my iMac whenever I need to quickly spin up Virtual Machines. I thought I would extend this generous gift from Simon onto my Twitter followers, since several of you mentioned you would like one after I tweeted about the gift.

I had thought about giving it to the first seven followers that responded and realized that would have been unfair to folks who were not watching their Twitter stream at that very moment (which nobody does, least I do not). So, if you want a super easy way to win a free VMware Fusion 6 Professional license key, take a look below an please CAREFULLY READ all directions.

How to Win:

Leave a short comment on this post on what this VMware Fusion license key would enable you to do, whether that is solving a particular problem or challenge.In addition, what is the one feature that you are most excited about for new users or what new feature would you like to see for existing VMware Fusion customers. Simple, right? I will randomly select seven winners from the list of comments in one weeks time, so make sure you leave your Twitter handle in the post else you will not be eligible to win. This is open to everyone, you do not need to reside in the US to win.

Winners:

Primary Sidebar

Search this website

Author

William Lam is a Staff Solutions Architect working in the VMware Cloud on AWS team within the Cloud Platform Business Unit (CPBU) at VMware. He focuses on Automation, Integration and Operation of the VMware Software Defined Datacenter (SDDC).