Yellow Bricks

by Duncan Epping

File Level Recovery from within a VMDK backup

· ·

Today there was a cool article released on the Storage Nuts & Bolts blog. It’s about file level recovery from within a VMDK based on an NFS datastore. NFS is just mentioned cause this is the preferred way to go for the NetApp family, but it doesn’t matter NFS or VMFS the solution they came up with works for the both of them.

This option was recently discovered and further developed (Registry entries and Batch script) by one of the NetApp SE’s (Mike Arndt) and it’s very effective and free for those customers that already have a CIFS license with their NetApp arrays, which is a very large percentage. The other important factor is that Mike has made it a point-and-click process. Great job Mike!!!

As part of their VMware Disk Developer’s Kit, VMware provides a vmware-mount.exe utility that allows for mounting an existing VMDK on a Windows Driver letter. We’ll be using this utility as well to mount the VMDK as well as some Registry Entries and a Batch Script to further simplify the file recovery process.

I don’t to republish the complete article, so visit the blog and use the script and registry settings these guys created. Especially the first option with registry settings, which give you the possibility to mount a VMDK with just a “right click – mount” action is great!

Howto: Check if a LUN is being locked by the host?

· ·

I just came across the following on the VMTN forum which is a very useful command in my opinion. When metadata changes for a LUN, that LUN is being locked by a host. Sometime the lock isn’t released, which can cause weird situations. In this case you would want to know which host is locking the LUN, especially when you’ve got over a dozen hosts. Rubeck posted a reply on Vliegenmeppers question on the forum:

esxcfg-info -s | grep -i -B 12 pending

Thanks guys,

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.