So I have been doing a lot of work with OVF Tool as of late. In addition, I have been trying hard to ensure that all VMware scripts that I create can be run natively on my Mac (no particular reason). While going through this exercise I ran into some interesting error messages when attempting to deploy OVAs using OVF Tool 3.0.1 on Mac.
If you receive the error message “Remote Desktop Connection cannot verify the identity of the computer that you want to connect to.” and do not get a Connect button then the domain information being passed cannot be resolved or is not correct. To fix the issue on the Mac, go to RDC – Preferences…, ensure Domain: is blank or set correctly, and then try to connect again.
As I am sure you have heard by now, VMware recently released some updates including ESX/ESXi 4.1 Update 1, vCenter Server 4.1 Update 1 and vCloud Director 1.0 Update 1. Unlike many other bloggers, I opted not to write about the updates as I do not find any of the information all that important to talk about (i.e. it did not apply to me). However, while reading over the list of known issues with vCenter Server 4.1 Update 1 I came across an issue referring to vCenter Server instances and potential MAC address conflicts. Since I have seen a growing number of environments where multiple vCenter Server instances have been deployed, I thought I would talk about the issue and one of the best practices around deploying such an environment.
vCenter Server generates MAC addresses of virtual machines in part from an instance ID randomly generated and assigned to a vCenter Server instance at installation time. While this ID cannot be set during installation time it can be changed post installation. Why is this important? Well, if you only have one vCenter Server instance in your environment than it probably is not. Even if you do have multiple vCenter Server instances running (e.g. one for development and one for production) you will likely not run into any problems. With that said, if you have more than one vCenter Server running in your environment and by chance any of them have the same instance ID configured than it is possible that virtual machines in the vCenter Server instances with the same instance ID may have the same MAC address. As such, it is a best practice to ensure that each vCenter Server is configured with a unique instance ID.
Directions on how to check and set instance IDs are specified in the vCenter Server 4.1 Update 1 release notes and copied below.
Virtual machine MAC address conflicts
Each vCenter Server system has a vCenter Server instance ID. This ID is a number between 0 and 63 that is randomly generated at installation time but can be reconfigured after installation.
vCenter Server uses the vCenter instance ID to generate MAC addresses and UUIDs for virtual machines. If two vCenter Server systems have the same vCenter instance ID, they might generate identical MAC addresses for virtual machines. This can cause conflicts if the virtual machines are on the same network, leading to packet loss and other problems.
Workaround: If you deploy virtual machines from multiple vCenter Server systems to the same network, you must ensure that these vCenter Server systems have unique instance IDs.
To view or change the vCenter Server instance ID:
- Log in to vCenter Server using the vSphere Client, and select Administration > vCenter Server Settings.
- Select Runtime Settings.
The vCenter Server Unique ID text box displays the current vCenter Server instance ID.
- If this ID is not unique, type a new unique value between 0 and 63 in the vCenter Unique ID text box and click OK.
- If you changed the vCenter Server instance ID, restart vCenter Server for the change to take effect.
If you have existing virtual machines with conflicting MAC addresses, edit the MAC addresses to make them unique:
- Ensure that the virtual machine is powered off.
- In the vSphere Client inventory, right-click the virtual machine and select Edit Settings.
- On the Hardware tab, select the virtual network adapter for the virtual machine.
- Under MAC Address, select Manual and specify a unique MAC address.
- Click OK.
Alternatively, you can force vCenter Server to generate a new MAC address for the virtual network adapter by configuring the virtual network adapter to use a Manual MAC address, and then reconfiguring it to Automatic.
A couple weeks back, my wife asked me to take a look at her Macbook Pro as the display was scrambled with black and white shapes. After rebooting the laptop a couple times, the shapes disappeared and the Apple logo was shown with the spinning circle, but the OS was never loaded. After several failed attempts, I thought the hard drive might have died so I ordered a new one and installed it myself since the laptop was no longer under warranty. Besides a couple problems with the OS installation after the drive had been replaced, the laptop appeared to be working great.
The other day, my wife called me over again experiencing a new problem. Upon rebooting the laptop the default OS chimes were heard through the speakers, but the display remained black and the laptop kept rebooting. This time, I decided to reset the PRAM by pressing Apple+Option+p+r while powering on the laptop. This fixed the constant rebooting, by the display was scrambled with black and white shapes. While the display was not always the same, the best way to describe it was like a piano keyboard with the keys going horizontally on the screen, but also with vertical columns of mostly black with white speckles in them.
Initial Google searches for this problem turned up very little. Because the laptop was no longer under warranty, I figured it was probably hosed. After much searching, I came across the following Apple KB article from the Mac forums: http://support.apple.com/kb/TS2377. While I could not be sure, this sounded very similar to the issue. On a whim, I brought the laptop over to the Genius Bar (make sure to have a reservation: http://concierge.apple.com/store/R250) hoping for a miracle. The technician ran a GPT test on the laptop and reported that the NVIDIA card had in fact died. The bad news was the laptop repair took three days, but the good news was it did not cost a thing! My hope is that this entry will make it easier for people to find this solution if they are experiencing the same problem.