WilliamLam.com

Installing ESXi 5.1 Update 1 on Mac Mini is Now a Breeze! (No Custom ISO/patches Needed!)

by // 68 Comments

ESXi 5.1 Update 1 was just released by VMware and similar to the ESXi 5.0 Update 2 release last year, the tg3 (Broadcom) driver has now been updated to 3.123b.v50.1 which is required to support network connectivity on the Apple Mac Mini's. Prior to this, to install ESXi on an Apple Mac Mini, users were required to build a custom ISO that included the updated tg3 driver and I am happy to say this is no long necessary! In addition, having the latest driver also provides out of the box support for the Thunderbolt ethernet adapter which is great if you are looking to add an additional ethernet connection to the Apple Mac Mini.

Disclaimer: The Apple Mac Mini is not officially supported by VMware.

Here is a quick screenshot of the networking details including the Thunderbolt ethernet adapter on my Apple Mac Mini 5,3 running ESXi 5.1 Update 1:

Apple Mac Mini 6,2 Users

If you have an Apple Mac Mini 6,2 the workarounds described in this article are still required as well as an additional issue regarding the on-board NIC for the Apple Mac Mini 6,2. The issue is that the on-board NIC is not recognized and claimed by the tg3 driver because there is not a PCI ID entry in the tg3 map file. Note, BCM57766 driver is supported, just that it was missing the mapping (I believe this was the case in 5.0 as well). Working with VMware engineering, I was able to obtain the SMC fix and along with the workarounds that I built earlier for ESXi 5.0 and I have created a custom ESXi 5.1 Update 1 ISO that includes all the fixes and you will be able to install it on your Apple Mac Mini 6,2 without any further modifications.

Download: ESXi-5.1u1-MacMini-SMC-BOOT-FIX-6-2.iso

Note: From my understanding, some of these issues have been fixed but just did not make it in time for the Update 1 release. I'm hoping that we will be able to get most of these fixed in a future patch or update. This is actually pretty awesome, given that this is NOT SUPPORTED by VMware, but engineers are still willing to help the community out!

UPDATE: When trying to enable vSphere HA, the following error "Could not find a trusted signer" is thrown. To get around this problem, you will need to manually install the vSphere HA VIB and then reconfigure vSphere HA. The easiest method is to SCP the VIB from the VCSA and then using ESXCLI and the --no-sig-check flag to install the VIB.

Here are the commands to run:

scp /etc/vmware-vpx/docRoot/vSphere-HA-depot/vib20/vmware-fdm/VMware_bootbank_vmware-fdm_5.1.0-1064983.vib [email protected]:/tmp
esxcli software vib install -v /tmp/VMware_bootbank_vmware-fdm_5.1.0-1064983.vib --no-sig-check

Additional Resources:

How To Configure vCenter Server 5.0 To Work With VIN 2.0?

by // 8 Comments

Many of you know that I am a huge fan of VIN (vSphere Infrastructure Navigator) and the value it can bring to vSphere administrators and their organizations. With the latest release of VIN 2.0, there are even more exciting features and integration with both the vSphere and vCenter Operations Manager platforms. However, one of the prerequisites for using the latest version of VIN 2.0 is that you will need to be running a vSphere Web Client 5.1 Server which can be a challenge for customers still on vSphere 5.0.

There was a question raised internally awhile back ago on whether it would be possible to have VIN 2.0 function with a vCenter Server 5.0? In the VIN 2.0 release notes, there is a statement that seems to indicate this is possible:

The user interface of the vCenter Infrastructure Navigator 2.0 virtual appliance that is deployed on vCenter Server 5.0 can only be viewed from the vSphere Web Client 5.1

A feature that may not be very well known with the release of vSphere 5.1 is that the vSphere Web Client Server also supports vCenter Server 5.0 which must be manually added through the vSphere Web Client admin application. This means that vSphere administrators not only benefit from all the new feature enhancements of the new vSphere Web Client but will would also be able to get a single view of their entire vSphere 5.x infrastructure.

Given all this information, I suspect this should work and I had an idea on how I could implement this. Since VIN 2.0 can only be used from a 5.1 version of the vSphere Web Client, we can simply deploy a VCSA 5.1 (vCenter Server Appliance) and configure it to point to our vCenter Server 5.0 environment. This will then allow us to use VIN 2.0 with our vCenter Server 5.0 environment while still maintaining our vCenter Server 5.0 environment.

Note: Though I have opted to use the VCSA as that is the simplest method IMHO, you are not required to. The only requirement is access to a vSphere 5.1 Web Client Server which you can also install on a separate Windows server.

Here is a quick diagram of what this would look like:

For some background here is what the environment looks like:

  • VCSA 5.0 managing ESXi 5.0 hosts with running VMs
  • VCSA 5.1 (configured, but no inventory)
  • VIN 2.0 deployed onto the ESXi 5.0 hosts being managed by the vCenter Server 5.0

Here are the steps to get this working:

Step 1 - Deploy the VCSA 5.1 and configure the system as you would normally. We will only be using the vSphere Web Client from this VCSA.

Step 2 - Register your vCenter Server 5.0 environment using the admin app in the vSphere Web Client. If you are using the VCSA 5.1, you will need to follow the instructions here.

Step 3 - Deploy VIN 2.0 into the vCenter Server 5.0 environment if you have not already.

Step 4 - Open a browser and connect to the VCSA's 5.1 vSphere Web Client. The URL should be https://[VC-IP]:9443/vsphere-client and provide the vCloud Suite License key which is required to license VIN 2.0

Step 5 - Enable discovery for the vCenter Server 5.0 under the "Infrastructure Navigator" tab on the left hand side of the vSphere Web Client.

Step 6 - Once the initial discovery has completed, you should now be able to see VIN information displayed for your virtual machines.

So there you have it! VIN 2.0 functioning with a vCenter Server 5.0 environment with a bit of help from the 5.1 version of the VCSA. You will still be able to connect to the vCenter Server 5.0 environment using either the vSphere C# Client and even the 5.0 vSphere Web Client. Though with so many new features in the new vSphere Web Client, this a great way to start getting comfortable with the new interface and enjoy all the benefits from VIN.

Automating SSL Certificate Regeneration in VCSA 5.1 & 5.5 (vCenter Server Appliance)

by // 4 Comments

The VCSA (vCenter Server Appliance) provides a very simple way of regenerating the self-signed SSL Certificate by using the VAMI web management interface. This is extremely useful if you change the IP Address or hostname of your VCSA and want a proper SSL certificate with the correct common name, especially important if you are plan on using something like vCenter Orchestrator which validates this. To regenerate the SSL Certificate, you just need to login to the VAMI web interface by pointing your browser to the following address: https://[VC-IP]:5480 and under the Admin tab there is a option to "Toggle certificate setting".

After enabling this option, you will need to reboot your VCSA for the new SSL certificate to be generated. Once the VCSA is booted up, you will need to go back into the VAMI interface and disable this setting, else another SSL certificate will be generated upon the next reboot.

I was recently asked if it was possible to automate the SSL regeneration via the command-line without using the GUI which would be very useful for automated VCSA deployments. In looking into this, it turns out the process is quite simple and the present of a file within the VCSA will determine whether a certificate regeneration is required.

To enable certificate regeneration, run the following command which will "touch" (create) allow_regeneration file under /etc/vmware-vpx/ssl directory:

touch /etc/vmware-vpx/ssl/allow_regeneration

To disable certificate regeneration, you just need to remove the file after the VCSA has rebooted. Behind the scenes, this is what is happening when you are toggling the option in the VAMI interface and now you can automate this from the CLI without using the GUI!

UPDATE (09/04/13)

For the new VCSA 5.5, there is a new option that you can specify which will re-generate the SSL certificate and then delete the file without requiring manual intervention after reboot. You would still need to create the /etc/vmware-vpx/ssl/allow_regeneration file but if the contents of the file contains "only-once", it will delete the file automatically which is nice from an Automation perspective.

To re-generate the SSL certificate and automatically have it clean itself up, run the following command:

echo only-once > /etc/vmware-vpx/ssl/allow_regeneration