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.

This appears to be an old problem that keeps popping up, but I just experienced it for the first time. I was tasked with deploying 20 Windows VMs (more on this in a later post) for a project. I did so via templates and once the systems came up, I set the appropriate IP addresses as well as other configuration information. The last step was to reboot the VMs. After reboot about half of the VMs were responsive to ICMP and RDP while the other half were not.

To my surprise, upon checking the network configuration on the hosts that were unresponsive from the console, I found the default gateway was not set. It was a long day at work (>12 hours) and I thought I just missed something (more on why I did not automate this task in the later post as well). I set the default gateway, rebooted, and the same problem occurred.

Why was the default gateway configuration being lost on reboot and how can it be fixed?

I was trying to set up some permissions on vCenter Server using PowerCLI. Here is an example of a command I was running:

 foreach ($role in 'Host','Virtual Machine','VMware vCenter Update Manager') {
Set-VIRole–Role (Get-VIRole -Name ) -AddPrivilege (Get-VIPrivilege -Name 'Virtual machine')
} 

PowerCLI returned the following:

 WARNING: There were one or more problems with the server certificate: 
* The X509 chain could not be built up to the root certificate. 
* The certificate's CN name does not match the passed value. 
Name                      IsSystem 
----                      -------- 
newTestRole               False 
newTestRole               False 
newTestRole               False

This looks like it worked, however upon looking at the permissions on vCenter Server, the checkboxes for these three options were not selected. If you attempt the command with any other permissions it works as expected (i.e. the checkboxes are selected).

Why was this not working?

My group is in the process of deploying multiple vCloud Director instances and as such I thought it would be a good idea to download and test out the vShield product suite, which is one of the required dependencies for vCloud Director. To date, my group has never had a need for vShield Manager as we use another software firewall to perform the same functions. I work more closely on the systems side of the house and as such I am not always involved with all the networking projects going on. With all of the problems experienced by the network team (no fault of there own) deploying software firewalls (all fault here) in the past, I thought it would be a good idea to be involved with vShield from the beginning.

vShield is comprised of one or more of the following components:

• vShield Manager (one required per vCenter Server, free) - vCenter Server like management tool for all vShield products
• vShield Zones (one per host, free) - firewall for traffic between VMs
• vShield Edge (requires license) - provides edge security including LB, NAT, and VPN as well as gateway services
• vShield App (one per host, requires license) - interior, vNIC level firewall for all traffic between VMs even if they are on the same host
• vShield Endpoint (one per host, requires license) - introspection-based antivirus solution

For testing purposes, I decided to deploy a vShield Manager appliance as well as a vShield Zones appliance. Deploying the vShield Manager appliance is simple and since the VM is small the task takes very little time to complete. I powered on the VM and was surprised to find that the VM booted to a login in prompt and no other information was displayed. It was only upon reading the quick start guide that I realized I needed to:

• Log into the VM with admin/default
• Type: enable
• Enter the admin password
• Type: setup
• Follow the prompts

I recently ran into an issue where I needed to diff two files and determine what text was different though I did not want text to be marked as different if it appeared on different lines. As an example, if I had the below two files, I wanted diff to return nothing

$ cat file1 
Some text Blah 
$ cat file2 
Blah Some text

To my surprise, when I ran diff it returned:

$ diff file1 file2 
1d0 < 
Some test 
2a2 > 
Some test

Looking at the diff man page, the only relevant option I could find was --ignore-all-space, but this flag had no impact on the result of the command. The reason why this option did not work was because it only removed spaces on the same line between the files. For example:

$ cat file3 
Some text 
$ cat file4 
S o  me tex t 
$ diff file3 file4 
1c1 < 
Some text 
--- >
S o  me tex t 
$ diff --ignore-all-space file3 file4 
$

Now, you may be wondering why I desired the functionality to diff two files with the same text on different lines. I was trying to create a configuration synchronization script, but I learned that the configuration output was different depending on what order commands were executed on the device. In my particular case, the two devices I was comparing were initially configured differently so the lines did not always match up.

So how do you compare two files where the text is the same, but the text appears on different lines?