Yellow Bricks

by Duncan Epping

vSphere

esxcfg-scsidevs, Exploring the next version of ESX!

· ·

Whenever I do a beta test of a product / OS the first thing I do is check if all the features / commands that I used with the previous version still exist. When I did an “esxcfg- tab tab” on the next version of ESX one thing stood out, esxcfg-vmhbadevs was gone. I use this command a lot when investigating SAN problems, same goes for esxcfg-mpath by the way. Both print really valuable information that I usually copy & paste for keeping track of changes.

With the upcoming version of ESX(vSphere) a new command will be introduced which replaces esxcfg-vmhbadevs: esxcfg-scsidevs.

This new command has a couple of extra command line options and prints more detail than ever before, of which -l is probably the most useful. Using “esxcfg-scsidevs -l” results in:

mpx.vmhba2:C0:T0:L0
   Device Type: Direct-Access
   Size: 6144 MB
   Display Name: Local VMware, Disk (mpx.vmhba2:C0:T0:L0)
   Plugin: NMP
   Console Device: /dev/sda
   Devfs Path: /vmfs/devices/disks/mpx.vmhba2:C0:T0:L0
   Vendor: VMware,   Model: VMware Virtual S  Revis: 1.0
   SCSI Level: 2  Is Pseudo: false Status: on
   Is RDM Capable: false Is Removable: false
   Is Local: true
   Other Names:
      vml.0000000000766d686261323a303a30

One of the options I used the most with esxcfg-vmhbadevs was “-m”, which would result in the following:

vmhba0:0:0:5 /dev/sdb5 49b785f3-f263cec4-a4bd-000c29123ede

For esxcfg-scsidevs the option -m also displays this information, but VMware has added the VMFS name which makes it clear what the relationship is and saves me the extra step of matching ID’s with names manually:

mpx.vmhba0:C0:T0:L0:5 /dev/sdb5
  49b785f3-f263cec4-a4bd-000c29123ede  0  Storage1

So far I’m happy with the improvements in the service console / remote cli! Up next: iSCSI.

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?

VMware vCenter Data Recovery

· ·

During VMworld I quickly wrote down the steps that VMware vCenter Data Recovery takes when backing up VMs. I added one step which isn’t unimportant, changed block tracking(4):

  1. Create a snapshot of disk(s)
  2. Hot add disk(s) to Data Recovery appliance
  3. Create hashes of (hopefully variable) blocks
  4. Read data of changed blocks if previous backup exists
  5. Dedupe(using variable chunk sizes) and create SHA1 hash for index
  6. Store data (possibly encrypted)
  7. Remove hot add disk(s)
  8. Remove snapshot

Compared to the current VCB installable and current feature set VI 3.5 offers this is a huge enhancement. (VMware vCenter Data Recovery will be part of the vSphere products.) Creating deduplicated back ups of only the changed blocks based on variable chunk sizes will give every user the opportunity to have a decent backup scheme. VMware vCenter Data Recovery utilizes the new VMware Consolidated Backup API by the way. For those afraid that the dedupe datastore gets corrupted an automated short integrity check is performed once a day and a thorough integrity check once a week.

Keep in mind that not only VMware will be able to utilize these new features. Because VCB is changed to an API a much tighter integration with 3rd party backup tools can be expected in the near future!

I would love to get my hands on a beta version of the product as soon as it’s available to play around with it some more and tell you more about the rich feature set this product will have. Unfortunately it’s not available yet and you will all have to wait, but I will keep you posted.