Yellow Bricks

by Duncan Epping

Howto

HOWTO: ESXi and SSH

· ·

I’ve noticed many of the hits on my blog are related to ESXi. One of the most asked questions is how can I SSH to an ESXi hosts? Looking at my wordpress stats, this is also one of the top searches.

By default this isn’t possible. But there’s a way to get this working, just do the following:

  1. Go to the ESXi console and press alt+F1
  2. Type: unsupported
  3. Enter the root password(No prompt, typing is blindly)
  4. At the prompt type “vi /etc/inetd.conf”
  5. Look for the line that starts with “#ssh” (you can search with pressing “/”)
  6. Remove the “#” (press the “x” if the cursor is on the character)
  7. Save “/etc/inetd.conf” by typing “:wq!”
  8. Restart the management service “/sbin/services.sh restart”

Done!

ESXi 3.5 Update 2 on a USB memory key

· ·

For those like me who would like to check ESXi 3.5 update 2 but don’t want to install on a local harddisk. Here’s a good pdf about how to install it on a USB memory key. It’s fairly easy and I just booted my IBM X61 laptop with ESXi.


In short:

  1. First get the following tools: 7-Zip(Free), WinImage(Demo)
  2. Download the ESXi ISO
  3. Open the ISO with 7-Zip
  4. Extract “install.tgz”
  5. Open “install.tgz” with 7-Zip
  6. Click on “install.tar”
  7. Browse to “usr\lib\vmware\installer\”
  8. Open “VMware-VMvisor-big-3.5.0_Update_2-103909.i386.dd.bz2”
  9. Extract “VMware-VMvisor-big-3.5.0_Update_2-103909.i386.dd”
  10. Open WinImage and go to Disk, click on “Restore Virtual Harddisk Image on physical drive”
  11. Select a physical drive
  12. Select “VMware-VMvisor-big-3.5.0_Update_2-103909.i386.dd”
  13. And click “yes” to write the DD image to the USB Disk

Done! For a more detailed procedure check the pdf above, it also includes screenshots!

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,

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.