Archive

Archive for January, 2013

Tricking ESXi into seeing an SSD device

January 30, 2013 3 comments

Sometimes supported SSD drives do not appear in the vSphere Client or Web Client as an SSD, but instead as unknown or Non-SSD.

It is possible to use storage claim rules to alter this behaviour, to be able to use the ESXi host cache feature in ESXi 5.0 and above.

To start with, it is important to identify the device that is being reported incorrectly.

SelectDatastore

As you can see from the vSphere Client above, the datastore created as SharedSSD is reported as Non-SSD.

We need to identify the device that this datastore has been created on, one possible way would be to go into the properties of the datastore, and then enter the manage paths screen as shown below.

IdentifyDevice

Notice that the SATP (Storage Array Type Plugin) used for this device is VMW_SATP_DEFUALT_AA, we will need this with the device id.

We can then right click on the path and copy the name to the clipboard. In this case that would contain all the detail after Name: in the lower window. The only detail required is in this case the iSCSI t10 number.

(Although in this example we have already created a datastore on the device, it would be possible to configure a device that does not currently have a datastore as SSD except we would need to identify the device via the storage adapter.)

Once we have the device id, and SATP we can than use the esxcli command line tool (found in the ESXi shell, and vCli and vMa) to configure a claim rule.

The first setup is to create the claim rule with the required optional parameter to enable SSD.

CreateClaimRule

The next step is to ensure that the claim rule has been added.

CheckClaimRuleApplied

Notice that the claim rule previously entered is displayed as a result of the command.

Now we need to reclaim all claim rules to ensure that SSD is now enabled for this device.

ReclaimRules

Notice that in this case it was unable to unclaim the path. This can happen sometimes, and is easily fixed with a reboot of the host.

Alternatively, unclaim the device:

esxcli storage core claiming unclaim -t device -d t10.945445000000000023030000000000000000000000000000

Then load, and run the claim rule:

esxcli storage core claimrule load
esxcli storage core claimrule run

If you do not get the unable to reclaim message detailed above, you can now confirm hat the rule has been applied and that the device is now seen as SSD.

ConfirmSSDstatus

As you can see in the above, the value for Is SSD: is true.

You should now see the datastore listed as SSD in the client.

NowSSDisShown

It is also possible to use this method to allow the use of SSD for host caching when using a nested setup for testing.

Advertisements

Active Directory VM Generation IDs

January 30, 2013 Leave a comment

Virtual machine snapshot and cloning technologies provide us with a way of rolling back changes and duplicating virtual machines that can aid in testing and troubleshooting.
However, these technologies can present challenges in production environments when used, particularly when used with Active Directory Domain Controllers.

With the release of Active Directory with Server 2012, Microsoft have provided a nice new feature that can help cope with Active Directory replication between servers that may have been rolled back to a previous snapshot, or clones called the VM Generation ID, that eliminates conditions where replication is not possible.

The Problem

To ensure correct replication of changes, Active Directory uses a combination of USN (Update Sequence Numbers) updated with each replication, and Invocation IDs which are the Domain Controller’s internal references numbers. These are collectively used to uniquely reference changes to the database, and must be unique within the forest.
The “issue” is when a virtual machine is rolled back to a previous version (usually using snapshot technologies) which causes the USN to in effect be “reused” for a different change. Replication cannot continue, as the replication identification (the Invocation ID and USN combination) are the same as a previous change.

The Solution

With Active Directory in Server 2012, the VM Generation ID is stored in the domain controllers computer account object in the attribute msDS-GenerationID, this is tracked by a driver inside Windows in the VM. When an Administrator reverts to a previous snapshot, Windows compares the VM Generation ID with the ID held in its computer object in ADS (Active Directory Services), and if the two values are different, the InvocationID is reset and RID (relative ID) pool is discarded to avoid the same USN combination being reused. If the values of the VM Generation ID and hat stored in the computer object are the same, the transaction is committed as normal.

This helps to avoid situations where Active Directory Replication fails due to Administrators rolling back Domain Controllers by using snapshot and cloning technologies.

For more information check out the Microsoft document Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)

This feature is supported in ESXi versions from 5.0 build 821926 onwards as detailed in VMware ESXi 5.0, Patch ESXi-5.0.0-20120904001-standard.