So I believe I've found an (known) issue with 2003 Windows Network Load Balancing and VMware.
VMware reports that WNLB on Windows 2003 Servers does not behave as expected here. Basically the article says the the NLB will point to one of the servers, not all of them, when running in unicast. They give you two fixes: use multicast; or reconfigure your Port Groups (or vSwitches) to prevent RARP Packet Transmissions. Interesting thing, with the current environment these servers are hosted in, I am unable to either run multicast or disable Switch Notify. I'll have to take that up with the Network Team, or perhaps investigate some NLB hardware.
So here's where I'm left with - these servers are not supposed to go down (hence the NLB), but they are everyday at 4AM (fun call). This is when backups are running, so I'm adjusting the time to see if the issue follows.
What appears to be happening is that when snapshots are taken for backups, the NLB seems to freak out at the one dropped ping. Currently the backups all run at once, which makes them all hiccup at the same time, killing the NLB for a good reported 45 minutes (no idea why so long). If the issue follows the backups, perhaps staggering the backups might solve the problem (let the NLB roll from one server to another).
I'll keep you posted on what I find.
------
Dustin Shaw
VCP
Notes on server implementations and fixes for VMware, Microsoft, and other fun projects.
Tuesday, March 13, 2012
Thursday, February 23, 2012
Host update fails after updating to 4.1u2
After updating vCenter Update Manager (right after updating my vCenter Server) from 4.1u1 to 4.1u2, I received the following error when trying to update on of my hosts:
Remediation did not succeed for esxihost: SingleHostRemediate: esxupdate error, version: 1.30, operation: 7: ('http://esxihost:9084/vci/hostupdates/hostupdate/vmw/vibs/cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib','/var/tmp/cache/-1699692350','[Errno 14] HTTP Error 404: Not Found')
After doing some research, I discovered what happened is that Update Manager 4.1u2 is case sensitive, whereas 4.1u1 was not. Any patches that were downloaded previous to the 4.1u2 update that contain upper case letters will fail with this error. VMware has a KB article about it here.
The patches affected are the ones below. I've put the correct capitalization on them for you. If you go to your patch repository, you can rename the files that you have to the below, and you should then be able to update your hosts. The repositories are located here:
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
bind-libs-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-utils-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib
cross_oem-vmware-esx-drivers-scsi-3w-9xxx_400.2.26.08.036vm40-1OEM.vib
vmware-esx_swMgmt_provider-4x.1.0.1-1.4.348481.vib
------
Dustin Shaw
VCP
Remediation did not succeed for esxihost: SingleHostRemediate: esxupdate error, version: 1.30, operation: 7: ('http://esxihost:9084/vci/hostupdates/hostupdate/vmw/vibs/cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib','/var/tmp/cache/-1699692350','[Errno 14] HTTP Error 404: Not Found')
After doing some research, I discovered what happened is that Update Manager 4.1u2 is case sensitive, whereas 4.1u1 was not. Any patches that were downloaded previous to the 4.1u2 update that contain upper case letters will fail with this error. VMware has a KB article about it here.
The patches affected are the ones below. I've put the correct capitalization on them for you. If you go to your patch repository, you can rename the files that you have to the below, and you should then be able to update your hosts. The repositories are located here:
- Windows2008: C:\ProgramData\VMware\VMware Update Manager\Data\Hostupdate\vmw\vib\
- Windows2003: C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\Hostupdate\vmw\vib
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
bind-libs-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-utils-9.3.6-4.P1.el5_5.3.x86_64.vib
bind-libs-9.3.6-4.P1.el5_5.3.i386.vib
cross_oem-vmware-esx-drivers-net-vxge_400.2.0.28.21239-1OEM.vib
cross_oem-vmware-esx-drivers-scsi-3w-9xxx_400.2.26.08.036vm40-1OEM.vib
vmware-esx_swMgmt_provider-4x.1.0.1-1.4.348481.vib
------
Dustin Shaw
VCP
Wednesday, February 22, 2012
Syslog not configured on ESXi 4.1u2
When I updated my ESXi host from 4.1u1 to 4.1u2, I got the following error message:
Configuration Issues
Issue detected on esxihost in datacenter: Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings in vSphere client.
I thought it was odd since the host previously never complained about the Syslog before. I compared the settings between it and the other 4.1u2 hosts that I had, and indeed, it was missing the Syslog.Local.DatastorePath setting.
The setting on my hosts was:
[] /scratch/log/messages
Once I copied this into my Syslog.Local.DatastorePath setting on the server, it was happy. I went ahead and copied the setting to my remaining 4.1u1 servers so that they will be happy when updated as well.
So apparently ESXi 4.1u2 has issues with the Syslog running on ramdisk, but ESXi 4.1u1 doesn't.
I found the following VMware KB Article that explains why it complains about it:
Syslog not configured messages on ESXi host console or in logs
------
Dustin Shaw
VCP
Issue detected on esxihost in datacenter: Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings in vSphere client.
I thought it was odd since the host previously never complained about the Syslog before. I compared the settings between it and the other 4.1u2 hosts that I had, and indeed, it was missing the Syslog.Local.DatastorePath setting.
The setting on my hosts was:
[] /scratch/log/messages
Once I copied this into my Syslog.Local.DatastorePath setting on the server, it was happy. I went ahead and copied the setting to my remaining 4.1u1 servers so that they will be happy when updated as well.
So apparently ESXi 4.1u2 has issues with the Syslog running on ramdisk, but ESXi 4.1u1 doesn't.
I found the following VMware KB Article that explains why it complains about it:
Syslog not configured messages on ESXi host console or in logs
------
Dustin Shaw
VCP
Tuesday, February 21, 2012
Installing PowerCLI on Server 2008
In attempting to install VMware vSphere PowerCLI on Windows Server 2008 x64, the following error comes up. This also happens on Server 2008R2.
Error 1406. Could not write value InstallPath to key \Software\VMware, Inc.\VMware vSphere PSDK Runtime. Verify tha tyou have sufficient access to that key, or contact your support personnel.
The prescribed fix for this is to remove the following registry key (and subkeys):
HKLM\Software\Wow6432Node\VMware, Inc.
*** Please make sure you know what you are doing in the registry before you do anything in there!!!
After that, installation proceeds successfully.
The only thing under the VMware, Inc. registry key is a "volatile" key with a UUIDHost DWord under it. Since I don't like to mess with other programs installed on the server (the one I was using has Quest vRanger installed), I exported the key, removed it, installed PowerCLI, and the imported my volatile key back in.
------
Dustin Shaw
VCP
Error 1406. Could not write value InstallPath to key \Software\VMware, Inc.\VMware vSphere PSDK Runtime. Verify tha tyou have sufficient access to that key, or contact your support personnel.
The prescribed fix for this is to remove the following registry key (and subkeys):
HKLM\Software\Wow6432Node\VMware, Inc.
*** Please make sure you know what you are doing in the registry before you do anything in there!!!
After that, installation proceeds successfully.
The only thing under the VMware, Inc. registry key is a "volatile" key with a UUIDHost DWord under it. Since I don't like to mess with other programs installed on the server (the one I was using has Quest vRanger installed), I exported the key, removed it, installed PowerCLI, and the imported my volatile key back in.
------
Dustin Shaw
VCP
Thursday, February 9, 2012
ESXi Host Unable to Update
I had a VMware ESXi 4.1 host that I was unable to update/patch using Update Manager the today.
It was coming up with the following errors when I tried:
VMware vCenter Update Manager had an unknown error. Check the Tasks and Events tab and log files for details.
And when I did that, I found this:
Could not install patches on esxihostname
Remediation did not succeed for esxihostname: SingleHostRemediate: Install error on host: esxihostname, error details: vim.fault.NoHost.
So I did some quick googling, and ran across this website that had the answer I was looking for.
The particular host that I was trying to update did indeed have an Unknown (inaccessible) VM on it (left over from yanking the storage and being sloppy...). I removed the VM from inventory, then was able to successfully patch the host.
------
Dustin Shaw
VCP
It was coming up with the following errors when I tried:
VMware vCenter Update Manager had an unknown error. Check the Tasks and Events tab and log files for details.
And when I did that, I found this:
Could not install patches on esxihostname
Remediation did not succeed for esxihostname: SingleHostRemediate: Install error on host: esxihostname, error details: vim.fault.NoHost.
So I did some quick googling, and ran across this website that had the answer I was looking for.
The particular host that I was trying to update did indeed have an Unknown (inaccessible) VM on it (left over from yanking the storage and being sloppy...). I removed the VM from inventory, then was able to successfully patch the host.
------
Dustin Shaw
VCP
Friday, January 27, 2012
Move vRanger Repository
I needed to move a vRanger Repository, but didn't want to start all my backups over, so I found a handy article from Quest that identifies how to do it.
FYI, I believe it requires vRanger 5.3 and up.
The basics are you go into SQL Management Studio, expand down to dbo.Repository to identify the repository, and change the host or target directory. Then go to dbo.RepositoryCIFS to change the sharename.
Make sure you restart the vRanger Services after making the changes.
------
Dustin Shaw
VCP
FYI, I believe it requires vRanger 5.3 and up.
The basics are you go into SQL Management Studio, expand down to dbo.Repository to identify the repository, and change the host or target directory. Then go to dbo.RepositoryCIFS to change the sharename.
Make sure you restart the vRanger Services after making the changes.
------
Dustin Shaw
VCP
Datastore Alarm Not Accurate
I had the unfortunate mishap of a VM dropping offline because it outgrew the amount of free space on the datastore it existed on. On the plus side, it happened in the middle of the night and I wasn't on call :-) The on call guy simply had to reboot the box, and it came back online.
When I got in and looked, the datastore that it existed on had 0.00 B of free space. Not very comforting, considering the fact that there were no alarms on that datastore, and there were several other Production VMs on that LUN.
To fix the alarm state, it was easy. Go into the alarm definition and disable and re-enable it. This will force it to refresh it's states and you will get to see all the pretty yellow and red icons that you've been missing.
This also will work if it is reporting a Usage Above Threshold before it should too.
------
Dustin Shaw
VCP
When I got in and looked, the datastore that it existed on had 0.00 B of free space. Not very comforting, considering the fact that there were no alarms on that datastore, and there were several other Production VMs on that LUN.
To fix the alarm state, it was easy. Go into the alarm definition and disable and re-enable it. This will force it to refresh it's states and you will get to see all the pretty yellow and red icons that you've been missing.
This also will work if it is reporting a Usage Above Threshold before it should too.
------
Dustin Shaw
VCP
Subscribe to:
Posts (Atom)