Yellow Bricks

by Duncan Epping

VMware

ESXi for free….

· ·

VMware’s CEO Paul Maritz just announced that in the near future ESXi will be available for free, that’s right you can just download it. Support is optional and sold separately. ESXi will become available for free over the next couple of weeks.

Why is VMware doing this? Well I think because competition is growing and the hypervisor isn’t what the war is about. The war is about Management products and that’s where VMware can make a difference with products like Lab Manager, Stage Manager, Lifecycle Manager, Site Recovery Manager and VirtualCenter. Giving away your hypervisor for free is also a great way to have companies adopt virtualization!

Queuedepth, and what’s next?

· ·

I’ve seen a lot of people picking up on the queuedepth settings lately, especially when there are QLogic adapters involved. Although it can be really beneficial to set the queuedepth to 64 it’s totally useless when one forgets about the “Disk.SchedNumReqOutstanding” setting. This setting always has to be aligned with the queuedepth because if the Disk.SchedNumReqOutstanding 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. In other words if you set a queuedepth of 64 and a Disk.SchedNumReqOutstanding of 16, only 16 commands get issued at a time to the LUN instead of the 64 your queuedepth is set to.

You can set Disk.SchedNumReqOutstanding via the command line and via VirtualCenter:

  1. VirtualCenter -> Configuration Tab -> Advanced Settings -> Disk -> Disk.SchedNumReqOutstanding
  2. Commandline -> esxcfg-advcfg -s 64 /Disk/SchedNumReqOutstanding

Disk.UseDeviceReset section is deprecated, see this article for more info.

NIC reordering

· ·

I’ve seen this happen a lot, you’ve got multiple vendor nics in your ESX hosts and for some reason the numbering is all screwed up. So the onboard nics are vmnic0 and vmnic2 the pci nics are vmnic1 and vmnic3, this can be really confusing, and even more confusing when the renumbering is inconsistent. Instead of manually editing your esx.conf file Allen Sanabria created a python script which fixes this issue. Check out this blog for the full article and the script:

Could you beleive that VMWare says that a feature of there software will reorder your NICs after the kickstart???
So if this was the order of our NICS
03:02.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
03:02.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)
eth0 == 03:02.0
eth1 == 03:02.1
When VMWare comes up it will reorder them so that vmnic0 will point to 03:02:01 when it should be 03:02:00 Now this only happens when you have a box with multiple nics from multiple vendors. This script will take care of it for you.

Command line tips and tricks #3

· ·

Enter maintenance mode from the ESX command line:

vimsh -n -e /hostsvc/maintenance_mode_enter

Backup every running vm via vcb in just one command:

for /f “tokens=2 delims=:” %%i in (’vcbvmname -h <virtualcenterserver> -u <user> -p <password> -s Powerstate:on ^| find “name:”‘) do cscript pre-command.wsf “c:\program files\vmware\vmware consolidated backup framework\” %%i fullvm

Enable VMotion from the command line:

vimsh -n -e “hostsvc/vmotion/vnic_set vmk0″

Write cache enabled or disabled

· ·

BernieT wrote a nice blog about why you should enable write cache. Check out his findings, below a short outtake.

Explaining Write mode (basic’s).
Write through -> When a write request is received by the RAID controller, the controller will not respond to the O/S with a “write success” until the data is written to the physical disk/s.

Write back –> When a write request is received by the RAID controller, the controller will cache the request/data and respond to the O/S with a “write success”, then write the data to the physical disk/s.