by Duncan Epping
VMware Wolf is generating some awesome blogposts lately:
All the blog posts contain a downloadable html file with a grid. The grid contains problems followed by possible resolutions.
Great blog posts and very useful information, visit VMware Wolfs blog and download the files! Great stuff for your troubleshooting toolkit!
I wrote about RVTools 2.0 a month ago and suggested a couple of additions. Rob picked these suggestions by me and a couple of my readers up and started implementing them in his tool. Here’s the release notes for this new version:
Version 2.1 (November 2008)
- Overall performance improvements.
- New vInfo tab. The “vInfo” tab displays for each virtual machine the hostname of the guest, power state, power on date / time, number of cpu’s, amount of memory, number of nics, configuration path, annotation, ESX host name, operating system name and VI SDK object id.
- New CPU tab. The “vCpu” tab displays for each virtual machine number of cpu’s, max cpu, overall cpu usage, shares, reservations, limits, annotations, ESX host name and operating system name.
- New Memory tab. The “vMemory” tab displays for each virtual machine the memory size, max memory usage, memory overhead, guest memory, host memory, shares, reservations , limits, annotations, ESX host name and operating system name
- New snapshot tab. The “vSnapshot” tab displays for each snapshot the name, description, date / time of the snapshot, quiesced value, state value, annotations, ESX host name and operating system name.
- The header text is automatically included after a copy and past action. This version 1.1 functionality was “lost” in version 2.0.
I don’t know about you guys but for just one guy writing this FREE tool this is pretty impressive. Pick it up and be sure to have it in your VI Toolkit!
I just noticed this new KB article that deals about not being able to upgrade ESXi on a Dell box because of the fact that the virtual media is attached:
Upgrade to ESXi 3.5 Update 2.
If you cannot upgrade to ESXi 3.5 Update 2, use the following workaround:
- Connect to the DRAC through ILO, as follows:
- Open the Media tab.
- Open the Configuration tab.
- Deselect the Attach virtual media check box.
- Attach the virtual media
- Using the virtual media, boot the machine.
- When the recovery CD is fully loaded, disconnect the virtual media and proceed with the recovery.
Which reminded of the nice I/O errors this Dell DRAC virtual media produces when attached. So be sure to detach the virtual media before you actually run ESX(i). Same goes for Fujitsu blades by the way, when a virtual media has been present it also produces these nice I/O errors:
Feb 12 09:16:47 esx1 kernel: SCSI device sdc: 2097151 512-byte hdwr sectors (1074 MB)
Feb 12 09:16:47 esx1 kernel: sdc: I/O error: dev 08:20, sector 0
Feb 12 09:16:47 esx1 kernel: I/O error: dev 08:20, sector 0
Feb 12 09:16:47 esx1 kernel: unable to read partition table
Which isn’t as bad as it seems, it’s just not able to read the partition. For Fujitsu blades the only workaround I’ve seen so far was to completely disable USB before booting.
I was just reading up on my Google Reader. A lot of information been dropped over the last couple of days and more and more people are getting active on the VMware blogoshere. One of the articles that really caught my attention was the “VM Template best practices (Linux)” by Leo Raikhman.
Leo did a great job in explaining how to build up a decent Template. Leo even included a way to regularly zero out the Linux Filesystem for the purpose of VCB image level dumps with small footprints.
And although Leo’s article talks about Linux only this also applies for Windows. If you will be doing VCB then remember to zero-out your filesystem every once in a while. Linux doesn’t scrub the sectors where the files resided and neither does Windows. I wrote an article on how to do this from within Windows. Yes you can do it by hand via the “shrink disk” option in VMware Tools, but as Leo already pointed out there’s no way of scheduling that one, as far I have discovered.
So most of the stuff written about in Leo’s article applies to Windows, yeah also the partition alignment! DO IT! But the zero-out procedure won’t work, I’ve wrote one a while back and here it is:
Set WshShell = WScript.CreateObject("WScript.Shell")
Dim fso, d, dc
Set fso = CreateObject("Scripting.FileSystemObject")
Set dc = fso.Drives
WshShell.RegWrite "HKCU\Software\Sysinternals\", 0, "REG_SZ"
WshShell.RegWrite "HKCU\Software\Sysinternals\SDelete\", 0, "REG_SZ"
WshShell.RegWrite "HKCU\Software\Sysinternals\SDelete\EulaAccepted", 1, "REG_DWORD"
For Each d in dc
If d.DriveType = 2 Then
Return = WshShell.Run("defrag " & d & " -f", 1, TRUE)'
Return = WshShell.Run("sdelete -c " & d, 1, TRUE)
End If
Next
Set WshShell = Nothing
Be sure to download Sdelete before you start, and remember that this script also does a defrag. If you are running “thin” disks than doing a defrag might not be the smartest thing to do, if so just delete the following line from the vb script:
Return = WshShell.Run("defrag " & d & " -f", 1, TRUE)'
As of ESX 3.5 it was impossible to add an additional NIC to a team as active without resorting to editing the esx.conf file:
# Active and standby setup and maxActive from 1 to 2
mv /etc/vmware/esx.conf /tmp/esx.conf.bak
/bin/sed -e ’s/net\/vswitch\/child\[0001\]\/teamPolicy\/maxActive = \”1\”/net\/vswitch\/child\[0001\]\/teamPolicy\/maxActive = \”2\”/g’ /tmp/esx.conf.bak >> /etc/vmware/esx.conf
So as you can see, a “sed” command changed the maxActive from 1 to 2. But I rather not use these kinds of solutions, editing the esx.conf that is. As of ESX 3.5 U3 that’s not necessary anymore, VMware fixed this issue:
Network adapters lose bonding during scripted installation
The esxcfg-vswitch -L command now works as expected and with the same functionality as in 3.0.x.
During a scripted installation, the following two commands did not result in a bonded pair of active network adapters on virtual switch VS_VM1. Instead, vmnic3 became the active adapter and vmnic4 became the standby adapter.
esxcfg-vswitch -L vmnic3 VS_VM1
esxcfg-vswitch -L vmnic4 VS_VM1
So just use esxcfg-vswitch again and don’t edit the esx.conf anymore!