Wednesday, June 20, 2012
Wednesday, June 13, 2012
Poor performance when running virtual machines on a local or direct attached SAS storage with IBM HS23 blades
When running virtual machines on a local or direct attached SAS storage with IBM HS23 blades, you experience these symptoms:
To workaround this issue run these commands in either the DCUI or via an SSH session:
esxcli software vib remove -n ilfu
esxcli software vib remove -n LSIProvider
Restart the ESXi 5.0 host.
This issue does not occur with VMware vSphere Hypervisor 5.0 Update 1 IBM Customized image.
For more information read the following article from IBM
- Slow virtual machine I/O performance
- I/O starts as expected, but then decreases
- No errors or events are logged in the vmkernel.log file
- The esxtop command reports high DAVG values during the slow performance
To workaround this issue run these commands in either the DCUI or via an SSH session:
esxcli software vib remove -n ilfu
esxcli software vib remove -n LSIProvider
Restart the ESXi 5.0 host.
This issue does not occur with VMware vSphere Hypervisor 5.0 Update 1 IBM Customized image.
For more information read the following article from IBM
Tuesday, June 12, 2012
VMware Security Patching Guidelines for ESXi and ESX
Please see the following KB article from VMware
Thursday, June 7, 2012
How to enable ipv6 temporary addresses and make them preferred for outgoing connections in CentOS
Enter these two command from a root shell:
sysctl net.ipv6.conf.all.use_tempaddr=2
sysctl net.ipv6.conf.default.use_tempaddr=2
To make them permanent add these two lines in /etc/sysctl.conf
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2
After that restart network service:
service network restart
sysctl net.ipv6.conf.all.use_tempaddr=2
sysctl net.ipv6.conf.default.use_tempaddr=2
To make them permanent add these two lines in /etc/sysctl.conf
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2
After that restart network service:
service network restart
Wednesday, May 30, 2012
Optimize Windows XP and Windows 7 for file sharing
Click on the "Start" menu and in the "Run" line type "Regedit" and hit Enter.
Navigate to the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache
The default value of the LargeSystemCache key is "0" (zero). Highlight "LargeSystemCache" and right click it. From the menu select "Modify".
In the new window change the value data from "0" to "1" (one) and click OK.
Next, locate the following key in the registry:
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size
By default the "Size" value will be set to "0" or "1". Follow the procedure outlined above to modify the value and change it to "3".
Once you have updated these values close the Registry Editor and reboot the system for the new settings to take effect.
The changes we've made to the registry should resolve the Event ID 2017 and 2021 errors and Source Srv/Lanman errors in the Windows Event Log. This will ensure that shared files and folders remain accessible to network users without the need to reboot the system. This should also keep mapped network drives from disappearing as well as optimize overall network performance of the file server.
For more info read the following article
Navigate to the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache
The default value of the LargeSystemCache key is "0" (zero). Highlight "LargeSystemCache" and right click it. From the menu select "Modify".
In the new window change the value data from "0" to "1" (one) and click OK.
Next, locate the following key in the registry:
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size
By default the "Size" value will be set to "0" or "1". Follow the procedure outlined above to modify the value and change it to "3".
Once you have updated these values close the Registry Editor and reboot the system for the new settings to take effect.
The changes we've made to the registry should resolve the Event ID 2017 and 2021 errors and Source Srv/Lanman errors in the Windows Event Log. This will ensure that shared files and folders remain accessible to network users without the need to reboot the system. This should also keep mapped network drives from disappearing as well as optimize overall network performance of the file server.
For more info read the following article
Wednesday, May 23, 2012
Upgrading VMware Update Manager to version 5.0 Update 1 fails while updating SQL Express instance
Upgrading VMware Update Manager 4.x or 5.0 to VMware Update Manager 5.0 Update 1 fails.The setup fails while updating the SQL Server Express instance.
The installed version of SQL Server Express is 10.50.2500.0, which is the same as the redistributable version bundled with vSphere 5.0 Update 1.
This can be checked with SQL Management Studio. Right-click the SQL Server instance and select Properties to verify the version.
This issue can occur if the version information for SQL Server Express in the registry is incorrect. The vSphere installer checks this registry key and compares it to the version string of the bundled SQL Express setup:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\VIM_SQLEXP\MSSQLServer\CurrentVersion
If these version strings do not match, the vSphere installer will attempt to upgrade the database even though the database version is already up to date.
To resolve this issue run regedit and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\VIM_SQLEXP\MSSQLServer\CurrentVersion
Change the value of the key to match the version string of the redistributable Microsoft SQL Express installer. For example, the version string is 10.50.2500.0 for SQL 2008 R2 SP1 Express.
Click OK and close the Registry Editor.
Update VMware Update Manager again to verify.
For more information read the following article from VMware KB
The installed version of SQL Server Express is 10.50.2500.0, which is the same as the redistributable version bundled with vSphere 5.0 Update 1.
This can be checked with SQL Management Studio. Right-click the SQL Server instance and select Properties to verify the version.
This issue can occur if the version information for SQL Server Express in the registry is incorrect. The vSphere installer checks this registry key and compares it to the version string of the bundled SQL Express setup:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\VIM_SQLEXP\MSSQLServer\CurrentVersion
If these version strings do not match, the vSphere installer will attempt to upgrade the database even though the database version is already up to date.
To resolve this issue run regedit and navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\VIM_SQLEXP\MSSQLServer\CurrentVersion
Change the value of the key to match the version string of the redistributable Microsoft SQL Express installer. For example, the version string is 10.50.2500.0 for SQL 2008 R2 SP1 Express.
Click OK and close the Registry Editor.
Update VMware Update Manager again to verify.
For more information read the following article from VMware KB
Wednesday, May 9, 2012
How to fix the VM autostart problem in vSphere 5 Update 1
Activate the ESXi shell
Login and enter this command to obtain a list of VMs
vim-cmd vmsvc/getallvms
Note the number of each VM you want to autostart
Create a script like this one:
vim-cmd vmsvc/power.on 50
sleep 30s
vim-cmd vmsvc/power.on 15
where you put a line for each VM you want to autostart, using the VM number you note earlier.
Save this script in a datastore folder and make it executable:
chmod 777 /vmfs/volumes/datastore1/scripts/autostart.sh
add a line to your /etc/rc.local file to call autostart.sh:
/vmfs/volumes/datastore1/scripts/autostart.sh
Login and enter this command to obtain a list of VMs
vim-cmd vmsvc/getallvms
Note the number of each VM you want to autostart
Create a script like this one:
vim-cmd vmsvc/power.on 50
sleep 30s
vim-cmd vmsvc/power.on 15
where you put a line for each VM you want to autostart, using the VM number you note earlier.
Save this script in a datastore folder and make it executable:
chmod 777 /vmfs/volumes/datastore1/scripts/autostart.sh
add a line to your /etc/rc.local file to call autostart.sh:
/vmfs/volumes/datastore1/scripts/autostart.sh
Subscribe to:
Posts (Atom)