I cannot remember the last time I burned a CD or DVD. I can remember the last time I attempted to create a bootable USB device from an ISO. Unfortunately, I have memories of wasting time creating bootable USB devices as well. In this post I will discuss how to use UNetbootin to make creating bootable USB devices easy.
For those of you using a Mac and more specifically running Mavericks, you may have noticed that your quotes and quotations look a little different. The change is known as smart quotes and while they may look nice, the can cause quiet a bit of problems including formatting issues in other products like Log Insight.
Recently my laptop decided it no longer wanted to start. While it was in the Genius Bar, I dug up an old Macbook Pro (called MBP throughout the rest of this post) and began to configure it so I could use it for work. Configuring a different laptop gave me the opportunity to try out some new/updated applications and see if I could find more ways to be productive (I will cover this in a future post). In addition, it brought up some old issues I had experienced and gave me a chance to fix them and document them. In this post, I would like to talk about the problems I experienced attempting to connect to a Juniper Network Connect (called JNC throughout the rest of this post) VPN and how I was able to get it resolved.
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.