Yellow Bricks

by Duncan Epping

VirtualCenter

Command line tips and tricks #2

· ·

Three totally different command line tips/tricks this time:

  1. Dump a specific disk via the VCB Proxy monolithic(1 big chunk):
    Open a cmd and goto your VCB installation path
    “vcbexport.exe -M 1 -d test01.vmdk -s TestVM/TestVM.vmdk”
  2. Any swapping going on or more info on memory usage in general:
    Open a putty sesion to your ESX box
    “watch -n 1 cat /proc/vmware/sched/mem”
  3. Reinitialize the VirtualCenter Database:
    Stop the service
    Start vpxd.exe with the option “-b”
    CAUTION, this will wipe out the entire database, this is a last resort!

Virtual Machine tweaks for a better performance

· ·

Over the last couple of months I gathered the following tweaks for a better performance insight the virtual machine, besides disabling / uninstalling useless services and devices:

  1. Disable the pre-logon screensaver:
    Open Regedit
    HKEY_USERS\.DEFAULT\Control Panel\Desktop
    Change the value of “ScreenSaveActive” to 0.
  2. Disable updates of the last access time attribute for your NTFS filesystem, especially for i/o intensive vm’s this is a real boost:
    Open CMD
    fsutil behavior set disablelastaccess 1
  3. Disable all visual effects:
    Properties on your desktop
    Appearance -> Effects
    Disable all options.
  4. Disable mouse pointer shadow:
    Control Panel -> Mouse
    Click on the tab “pointers” and switch “enable pointer shadow” off.

So if you’ve got an addition, please post it and I’ll keep updating this blog post!

Scalable Storage Performance PDF

· ·

I was just reading up on the PDF’s I gathered over the last couple of weeks and found the Scalable Storage Performance pdf extremely useful. It contains a good explanation about the queue depth setting and much more….

To reduce latency, ensure that the sum of active commands from all virtual machines does not consistently exceed the LUN queue depth. Either increase the queue depth as shown in the VMware Infrastructure 3 Fibre Channel SAN Configuration Guide (the maximum recommended queue depth is 64) or move the virtual disks of some virtual machines to a different VMFS volume. You can find the guide at
http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_san_cfg.pdf.
Also make sure to set the Disk.SchedNumReqOutstanding parameter to the same value as the queue depth. If this parameter is given a higher value than the queue depth, it is still capped at the queue depth. However, if this parameter is given a lower value than the queue depth, only that many outstanding commands are issued from the ESX kernel to the LUN from all virtual machines. The Disk.SchedNumReqOutstanding setting has no effect when there is only one virtual machine issuing I/O to the LUN.

Customization spec fails part II

· ·

A while back I blogged about the customization specification wizard failing when entering the password. Today I visited the same customer again. This problem only occurred when running it from the VirtualCenter itself. Today I upgraded the VirtualCenter server to 2.5 Update 1 and the problem is solved… Still don’t know why it happened,

VMware ESX 3.5 Template Deployment Bug

· ·

I just encountered the same bug that Aaron Delp blogged about in January:

It appears we have found a possible bug in the Deploy from Template Command in ESX 3.5. When you create a Windows Server based template and then try to deploy directly into an Active Directory with customization, the new system will get an error that a service failed to start when the machine is launched. This is because the VMWare BootRun service is not removing itself properly after deployment. This does not happen with deployments into a workgroup.

If you aren’t familiar with the BootRun service, this service will make all of the customizations after the sysprep work is complete during the deployment. You usually never see it because it runs on the first boot, makes the changes, and then removes itself from the machine.

In this case, the files are removed but the service entry is still there, hence the error that it can’t start up. VMWare has confirmed this to be a problem and they are investigating.

This customer runs the latest and greatest version of ESX and VirtualCenter so it appears that the bug hasn’t been fixed yet.