A lot of people had been waiting for this day. The Dutch VMUG Event, 12 December 2008! Over 500 people showed up, which is a great turn-up for such a small country. Not only was the place packed, the event was well organized. I want to thank the organization for all the hard work they’ve put into this event.

VMug is all about the Users and sharing knowledge so let’s talk about the sessions:

Viktor van den Berg kicked off welcoming everyone. Unfortunately I had to miss out on most of his presentation cause I needed to help out getting the VMware Demo Kit running. Richard Garsthagen was invited as the keynote speaker. Many of you know Richard of Run-Virtual.com but he is actually the guy with the coolest job title within VMware: Senior Evangelist. Richard talked about the future direction: Cloud Computing, vApp, VMsafe and more. He’s famous for his enthusiastic presentations and I think everyone will agree with me on this one. (more…)

VMware should publish more blogs like this one on Beacon Probing:

Beaconing is a software solution for detecting link failures downstream from the physical switch.ESX provides a simple and elegant teaming solution. All uplinks connected to a vswitch are assumed to connect to the same physical network (same broadcast domain) so they are all equivalent. Users can configure a list of active and standby uplinks for traffic to go out of the ESX host. If a link fails, the adapter driver detects it and marks the uplink as failed and stops using this uplink. Existing traffic will fail over to a standby uplink or redistributed to the remaining team members.

Read the full article here…

I’ve been thinking for a while about this. How can I zero-out all my vm’s with just one schedule. I don’t want to manually add a schedule every single time I roll out a VM, I want a central point for administering this.

Today I noticed the blog on using the VIX API. The VIX API can be used for all sorts of things, including copying files to all your VM’s or installing MSI on your VM’s. (Check the blog article for a complete list of supported operations for the VMRUN command.)

If you can install MSI’s then you can also run a simple vbs script:

vmrun -T virtualcenter01 -h https://virtualcenter01.yellow-bricks.local/sdk -u root -p yell0wbricks -gu user -gp userpw runProgramInGuest "[storage1] Windows/Windows.vmx" c:\windows\system32\sdelfrag.vbs

Unfortunately I wasn’t able to test it myself, but it should work just fine. If anyone is able to test it please let me know.

Thanks Carter!

Just noticed this blog article, get McAfee Antivirus for free. I tested it and it works great. As of today I’m the proud owner of McAfee Antivirus with a 1 year subscription for the total amount of $ 0,-. Thanks McAfee!

Sorry, the offer has been removed. Sorry guys,

I’ve spend a lot of time in the past trying to understand the settings for EnableResignature and DisallowSnapshotLUN. It had me confused and dazzled a couple of times. Every now and then I still seem to have trouble to actually understand these settings, after a quick scan through the VCDX Enterprise Study Guide by Peter I decided to write this post and I took the time to get to the bottom of it. I needed this settled once and for all, especially now I start to focus more on BC/DR.

According to the San Config Guide(vi3_35_25_san_cfg.pdf) there are three states:

1. EnableResignature=0, DisallowSnapshotLUN=1 (default)
   In this state, you cannot bring snapshots or replicas of VMFS volumes by the array into the ESX Server host regardless of whether or not the ESX Server has access to the original LUN. LUNs formatted with VMFS must have the same ID for each ESX Server host.
2. EnableResignature=1, (DisallowSnapshotLUN is not relevant)
   In this state, you can safely bring snapshots or replicas of VMFS volumes into the same servers as the original and they are automatically resignatured.
3. EnableResignature=0, DisallowSnapshotLUN=0 (This is similar to ESX Server 2.x behavior.)
   In this state, the ESX Server assumes that it sees only one replica or snapshot of a given LUN and never tries to resignature. This is ideal in a DR scenario where you are bringing a replica of a LUN to a new cluster of ESX Servers, possibly on another site that does not have access to the source LUN. In such a case, the ESX Server uses the replica as if it is the original.

The advanced LVM setting EnableResignature is used for resignaturing a VMFS volume that has been detected with a different LUN ID. So what does the LUN ID has to do with the VMFS volume? The LUN ID is stored in the LVM Header of the volume. The LUN ID is used to check if it’s the same LUN that’s being (re)discovered or a copy of the LUN that’s being presented with a different ID. If this is the case the VMFS volume needs to be resignatured, in other words the UUID will be renewed and the LUN ID will be updated in the LVM header.

UUID, what’s that? Chad Sakac from EMC described it as follows in his post on VMFS resignaturing:

It’s a VMware generated number – the LVM signature aka the UUID (it’s a long hexadecimal number designed to be unique). The signature itself has little to with anything presented by the storage subsystem (Host LUN ID, SCSI device type), but a change in either will cause a VMFS volume to get resigned (the ESX server says “hey I used to have a LUN with this signature, but it’s parameters were different, so I better resign this”).

Like Chad says the UUID has little to do with anything presented by the storage subsystem. A VMFS volume ID aka UUID looks like this:

42263200-74382e04-b9bf-009c06010000

1st part – The COS Time when the file-system was created or re-signatured
2nd part – The TSC Time; an internal time stamp counter kept by the CPU
3rd part – A random number
4th part – The Mac Address of the COS NIC

Like I said before, and this is a common misconception so I will say it again, the LUN ID and the Storage System product ID are stored in the LVM header and not the actual UUID itself. Not that it really matters for the way the process works though.

I think that makes it clear when to use EnableResignature and when not to use it. Use it when you want to access VMFS volumes of which the LUN ID changed for whatever reason. For instance a fail over to a DR Site with different LUN numbering or SAN upgrades which caused changes in LUN numbering.

That leaves DisallowSnapshotLun. I had a hard time figuring out when to set it to “0″ and when to leave it at the default setting “1″. But found the following in a VMworld Europe 2008 presentation:

DisallowSnapshotLun: Should be set to “0″ if SCSI Inquiry string differs between the two Array’s in order to allow access to datastores.

I googled for “SCSI Inquiry” and I found the following in a document by HP:

The storage system product ID retrieved from the SCSI Inquiry string (Example: HSV210)

In other words, when you’ve got an HP EVA 4000 and an HP EVA 8000 which are mirrored you need to set DisallowSnapshotLun to 0, when a fail-over has occurred. The SCSI Inquiry string would differ because the controllers would be of a different model. (The SCSI Inquiry string also contains the LUN ID by the way.)

When both sites are exactly the same, including LUN ID’s, you don’t need to change this setting. Leave it set to 1. Be absolutely sure that when you set DisallowSnapshotLun to 0 that there’s only 1 “version” of the VMFS volume presented to the host. If for some reason both are presented data corruption can and probably will occur. If you need to present both LUNs at the same time, use EnableResignature instead of DisallowSnapshotLun.

Depending on the way your environment is setup and the method you chose to re-enable a set of LUNs you may need to re-register your VM’s. The only way to avoid this is to use DisallowSnapshotLun and pre-register all VM’s on the secondary VirtualCenter server or use just one VirtualCenter server.

Re-registering can be done with a couple of lines of script on just one ESX box:

for i in `find /vmfs/volumes/ -name "*.vmx" `
do
echo "Registering VM $i"
vmware-cmd -s register $i
done

You can change the EnableResignature or DisallowSnapshotLun setting as follows:

open vCenter
Click on a host
Click on “Configurations” tab
Click on “Advanced Settings”
Go to “LVM”
Change appropriate setting
Click “Ok”
Rescan your HBA’s (Storage Adapters, Rescan)

It’s also possible to use the command line to enable DisallowSnapshotLun or EnableResignature:

echo 0 > /proc/vmware/config/LVM/DisallowSnapshotLUN
echo 1 > /proc/vmware/config/LVM/EnableResignature

VMware’s John Troyer revealed on Twitter a couple of hours ago a “search-able hardware compatibility guide” for VMware ESX and VMware View:

This online Hardware Compatibility Guide web application was released on December 10, 2008. To learn more about benefits and usage of this tool, please see “Help on Searching”.

This online Hardware Compatibility Guide replaces the former Hardware Compatibility Guides for systems, I/O devices, and SAN arrays for ESX 3.0 and greater versions, as well as VMware View Client. For compatibility guides of other VMware products or earlier ESX releases and VMware View Client, please use the “Other Documents” tab.

Check it out.

I would love to see some additions, for instance “supported path policy” for Storage. (MRU/Fixed) (The MRU/Fixed is actually there but you have to click on the model and then details before you see it.) But also supported versions of Software Agents for the Service Console would be a real welcome! It’s a big step forward again, and according to John they are still working on it and it will evolve over the next months.

During the VMTN Round Table podcast John Troyer just announced that within the next couple of days the “VMware Virtualization Professional Program” will be released. VVP can be compared to Microsofts MVP program. I think it’s great to see that VMware is taking the bloggers, community members and other professionals sharing knowledge serious and will be rewarding them with the “VVP” status.