Yellow Bricks

by Duncan Epping

Storage

VCB and independent disks

· ·

Most of you probably knew that it is impossible to snapshot an independent/persistent disk. And if you didn’t, in short: a disk that is in “independent/persistent” mode can’t be snapshot because it needs to write it’s changes immediately to the virtual harddisk. When using a snapshot(nonpersistent) writes go to a delta file.

So as I said in this article, using this mode on a specific disk is a nice way to get the full image VM without for instance that gigantic data disk. But some of you might need the snapshot functionality, and it’s not possible to change the disk state from the VirtualCenter client when the VM is up and running.

But it is possible to change the state via the command-line when the VM is running. So if you want to change the state in a VCB script for a specific disk, or want to change the state for a VM without shutting it down here you go:

Find out what the current mode is from the command line:

vmware-cmd <path to vmx file.vmx> getconfig scsi0:0.mode

Set the new mode from the command line:

vmware-cmd <path to vmx file.vmx> setconfig scsi0:0.mode “persistent”

Keep in mind that this is, as far as I know, not supported and should be tested thoroughly before using. I would prefer doing it manually and keeping it that way. Or you could always use the script that I blogged about a while back, it makes it possible to dump specific disks without having to resort to unsupported methods.

By the way, with the setconfig option you can set most vmx options!

 

Which VM is connected to an RDM?

· ·

A friend of mine asked me if there was a way to find out which VM’s were connected to a certain RDM disk. I’ve been looking all over but couldn’t find a simple command to do this. So I ended up on the forums and found a powershell script which creates a list with all the necessary info one would like to have:

$report = @()
$vms = Get-VM | Get-View
foreach($vm in $vms){
foreach($dev in $vm.Config.Hardware.Device){
if(($dev.gettype()).Name -eq “VirtualDisk”){
if(($dev.Backing.CompatibilityMode -eq “physicalMode”) -or
($dev.Backing.CompatibilityMode -eq “virtualMode”)){
$row = “” | select VMName, HDDeviceName, HDFileName, HDMode
$row.VMName = $vm.Name
$row.HDDeviceName = $dev.Backing.DeviceName
$row.HDFileName = $dev.Backing.FileName
$row.HDMode = $dev.Backing.CompatibilityMode
$report += $row
}
}
}
}
$report

All credits for this great script go to LucD!

Defraging a VMDK

· ·

Team Fusion wrote a great post on “defragging” vm’s and why you shouldn’t do it. Or at least be very careful about it. Make sure to read it!

Before we begin, it’s important to note that defragmentation isn’t a necessary task – your virtual machine will still work just fine even if you never defrag, and the effects of fragmentation are usually not noticeable. Personally, I’ve never feel the need to defrag. However, if for some reason you do feel the need to defrag, here’s how to do it. Note that snapshots get in the way of proper defragmenting.

Single initiator zoning

· ·

I’ve been doing VMware Design Reviews lately and so are my colleagues of the PSO department. A Design Review is quick scan of your design documentation by a VMware consultant. The consultant will hold your docs against best practices and propose changes to the design.

One of the things we encounter on a regular base is that admins took the easy path for their Storage Design zoning. So what’s zoning? In short: a way to partition your fabric into smaller subsets. These small subsets provide you with a better security and less interference.

You can do zoning in two ways, Soft and Hard. With “soft zoning” you use the device WWN in a zone without any restrictions to what port this WWN is attached. With “hard zoning” you put the port into a specific zone. So what do I prefer? I would prefer “hard zoning” because you need to know how your devices are connected and it makes troubleshooting a lot easier.

So now I’ve chosen a way  to zone I can just write down all my port numbers, create a zone and drop them in and I’m done… Well not so fast, that’s another choice one has to make before you start. How am I going to zone, single initiator zoning or multi initiator zoning? So what’s a single initiator zone: a single hba in a zone with the target device(s). And a multi initiator zone is all initiators that need to communicate with a device(s) in one zone. As one can imagine multi initiator zones are really easy to setup but definitely not my first choice.

Single initiator zones are the way to go. If there’s no need, and for ESX there isn’t, for initiators to be able to communicate with each other then they shouldn’t be able to. Not only is this more secure, because initiators can’t communicate with each other, it also cuts out a lot of rubbish on your fibre. Rubbish as for instance “Registered State Change Notifications”. Although RSCN storms don’t occur that often anymore as they used to it’s still a risk of contention and should be avoided when possible. So if you’re doing a design or preparing for one keep this in mind: Single Initiator Zones are the way to go!

There are a whole bunch of good articles on the net about zoning, read them you might learn a thing or two:

Have fun,

Queuedepth, how and when

· ·

So you’ve heard this probably from a few dozens of people by now when you don’t hit the expected SAN performance: Set your queuedepth to a larger size.

So how do you set this queuedepth? Find out for which module you’ll need to set this option:

vmkload_mod -l | grep qla

Now set it to a depth of 64 for module qla2300_707

esxcfg-module -s ql2xmaxqdepth=64 qla2300_707
esxcfg-boot –b

So now you’ve set the queue depth to 64 for your HBA cards, but why? Well I hope the answer is:”because I monitored my system with esxtop and I noticed that the “QUED” value was high”.

So there’s your when. You’ll need to set this setting if you notice a high “QUED” value in esxtop. Take a look at the following example I borrowed from a great blog on this subject:

As you can see in the example, the “ACTV” has a value of 32. Indeed 32 active commands cause that’s the default queue depth for qlogic cards. And 31 outstanding commands, in other words if we bump up the queue depth to 64 than all the commands should be processed instead of queued in the VMkernel.

What will this result in?