Yellow Bricks

by Duncan Epping

esxi

Disabling the VMFS-2 module! Exploring the next generation of ESX

· ·

When I started out with ESX 3.0.x the first thing I wanted to do was disable the VMFS-2 driver. There’s no need for it when you’re not accessing VMFS-2 volumes and removing it can lead to performance gains or at least a faster rescan of your storage. Removing it, according to to this section of the VMware website, was supposed to be really easy:

vmkload_mod -u vmfs2

Unfortunately, this just unloads the module and every time the server gets rebooted the module is loaded again. Same goes for the esxcfg-module command, it unloaded it but after a reboot the module was loaded again. You could add the command to /etc/rc.local of course. This would unload the module every time the server booted. I’m not a big fan of manually changing files like this, and luckily as of the next generation of ESX(vSphere) this doesn’t seem to be necessary anymore:

esxcfg-module -d
-d|--disable - Disable a given module,
indicating it should not be loaded on boot.

The funny thing is when I run the “esxcfg-module -l” command it still lists the module as loaded. If I run the “esxcfg-module -q”, which only queries the enabled modules, it’s not listed. After a closer investigation I noticed that the following line changed in “/etc/vmware/esx.conf”:

/vmkernel/module/vmfs2/enabled = "false"

I did a cross-check, it’s most definitely not loaded. Cool, remember this one “esxcfg-module -d”. It will come in handy some day.

VMFS recognized as a snapshot what to do? Exploring the next version of ESX…

· ·

Your VMFS has been recognized as a snapshot, what are you going to do? Hopefully most of you have read my previous post on this topic by now. If you didn’t, be very ashamed and start reading my EnableResignature post before you continue.

I was just playing with a VMworld Europe lab manual, which was about the next version of ESX/vCenter(Part of vSphere). I noticed the following new command on the command-line: esxcfg-volume. I did a help and the following showed up:

-l | --list
-m | --mount <vmfs uuid|label>
-u | -- umount <vmfs uuid|label>
-r | -- resignature <vmfs uuid|label>
-M | --persistent-mount <vmfs uuid|label>

As you can imagine this command will come in handy when a VMFS/LUN is being recognized as a clone or snapshot! With version 3.5 you needed to change an advanced setting. This setting wasn’t specifically for just one LUN, but for all of them, which is a risk. With the next version of ESX you could do the following if a volume has been detected as a snapshot and you want to resignature it:

  1. esxcfg-volume -l
  2. esxcfg-volume -r 49ba276a-c9e135b6-26f8-000c29123ede

Or if the current cloned volume isn’t connected you could also just mount it:

  1. esxcfg-volume -l
  2. esxcfg-volume -m 49ba276a-c9e135b6-26f8-000c29123ede

And if you are absolutely sure the cloned volume will not return you could mount it persistantly, which is the equivallent of “EnableResignature=0, DisallowSnapshotLUN=0”:

  1. esxcfg-volume -l
  2. esxcfg-volume -M 49ba276a-c9e135b6-26f8-000c29123ede

Don’t you just love this new exciting command-line magic! There’s more to come over the next days/weeks.

btw: there’s also a way of doing this from the GUI… Just add a new LUN, select the LUN that you want to mount, depending on what needs to be done pick “Assign a new signature” or “Keep Existing Signature”. But where’s the fun in that?

Powershell and importing .CSV files

· ·

I’ve been playing around with powershell yesterday. We needed to create over 100 VM’s and there’s no point in doing that all by hand. The customer provided us with a .csv file that contained specific info on these VM’s. It took me a while to figure out how to read the info.csv file and how to actually use it. But as always it’s actually fairly simple and that’s why I decided to write it down:

Before we even start, the CSV should be formatted as follows:

vmname,cluster
VM001,HA-DRS-Yellow-Bricks

Read the complete csv file into a variable:

$csv_info = Import-Csv c:\scripts\info.csv

For every line in the csv variable do something:

foreach ($line in $csv_info) {
write-host " This is virtual machine $($line.vmname) on cluster $($line.cluster)"
}

This line would print something like this:

This is virtual machine VM001 on cluster HA-DRS-Yellow-Bricks

As you noticed in the example above we used $line.vmname to get the name of the VM printed and $line.cluster for the cluster name, cool huh! BTW, Alan’s quick reference guide really helped me out!

vmktree 0.3.0 out of beta!

· ·

If we look at the VMTN community today there are a whole lot of people sharing powershell scripts, perl and even .net programs. Back in the days of ESX 2.x there wasn’t such a huge community, but there was one tool that everyone knew about and probably everyone tested and used at one point, vmktree!

Lars Trøen is man behind vmktree and he just released 0.3.0. For those of you who don’t know what vmktree is:

vmktree is a free web tool that shows you the graphs of resource usage of VMware ESX Server, VMware Server (on Linux), GSX Server (on Linux) and a few other data center devices (ilo/ilo2/rsa2/ds4000).

On VMware Server (and GSX) and ESX 3.x vmktree provides it’s own agent that collects system statistics and does not depend on vmkusage like it does on ESX 2.x. On ESX 3.x there is no agent installed on the ESX server itself as all values are polled from the machine vmktree is installed on.

vmktree is compatible with ESX and ESXi and needs to be installed outside of the Service Console, in contrary to previous versions. Lars created a great howto, which includes a CentOS jeos VM. I hope Lars can find some extra time and get that live esxtop back in again!

Increasing the queue depth?

· ·

One of the most promising blogs of this moment is definitely Frank Denneman‘s blog. Frank is a freelance consultant with a focus on virtualization and storage. His latest addition “Increasing the queue depth” is an excellent article and really shows that Frank knows what he’s talking about!

When it comes to IO performance in the virtual infrastructure one of the most recommended “tweaks” is changing the Queue Depth (QD). But most forget that the QD parameter is just a small part of the IO path.

The IO path is made up of layers of hardware and software components, many of which can have a huge impact on the IO performance. The best results are achieved when the whole system is analysed and not just the ESX host alone.

I’m not going to copy and paste his entire article of course. Head over to his website and start reading. I can also recommend these articles: SRM and HP Continous Access DR Group Design and HP CA and the use of lun load balancing scripts. Don’t forget to bookmark the site or add it to your rss reader!