In a recent thread on the VMTN PowerCLI Community someone asked if it is possible to get historical hard disk statistics. I referred the user to my Datastore usage statistics post, where I showed how to use the “disk” metrics to get that information.
But getting the individual vDisk statistics is a bit more tricky compared to getting the datastore statistics, as I showed in that post. The “disk” metrics hold the information, but the Instance that points to the MoRef value of a VM makes it a bit more tricky to retrieve.
Be forewarned, the “disk” metrics hold usage data for all the vDisks that a specific VM has on a specific datastore. You will not be able to get individual vDisk statistics, unless the vDisks are stored on different datastores !
On the positive side, the “disk” metrics will allow you to see how your vDisks increase in size over time. For your Thick vDisks that increase will be by expanding them, and for your Thin vDisks it will also show the natural growth.
In the vCenter Client, since vSphere 4, you can find a Storage Views tab on several of the VI containers. The data in these Storage Views is collected and provided by the vCenter Storage Monitoring plug-in.
Have a look at David Davis‘s post, called Using VMware vSphere Storage Views, for more information on what you can do with the Storage Views.
Some time ago I got a question from Andrew how the Multipathing Status presented in the Storage Views could be detected and reported upon by a PowerCLI script. What looked rather simple at first, turned out to be a bit more difficult than I anticipated.
In our PowerCLI book we presented a Delete-Harddisk function in Chapter 7.
One of our readers asked if that function could be used to remove orphaned VMDK files from one or more datastores. Now unfortunately that is not the case since the function we presented in chapter 7 uses the ReconfigVM_Task method to remove the harddisk.
In the PowerCLI Community there are some thread that provide scripts to report on orphaned VMDK files, but most of these are quite old.
So I decided to write a new script that would report on orphaned folders and VMDK files and that would have an option to remove these folders and files.
When you try to migrate a guest, that is using one or more RDM disks, you might see this message.
The reason this is most probably because the LUN IDs are different on the source and the destination ESX server.
One solution is:
- stop the guest
- write down the Physical LUN ID
- remove the RDM disk(s)
- vMotion the guest
- add the RDM disk(s) to the guest based on the Physical LUN ID
- start the guest
But why do this the hard (manual) way when we have PowerCLI ?
On the Yellow Bricks blog there was today a very interesting entry called Performance : Thin Provisioning. Besides the link to the excellent VMware document called Performance Study of VMware vStorage Thin Provisioning, Duncan also included some tips and tricks.
Since I’m in favour of automating as much as possible in my vSphere environment, I decided to have a look how all this could be scripted.
One of the interesting new features in vSPhere is vStorage Thin Provisioning. I’m not going to explain what Thin Provisioning is all about. For that you can consult several knowledgeable blogs (for example this entry on Virtual Geek) and/or books (for example Scott Lowe’s excellent Mastering VMware vSphere 4.0).
The problem I have with Thin Provisioning, is that there are a lot of existing guests and templates out there that were created with Thick VMDKs in the past. The only documented way I could find to convert these Thick VMDKs to Thin VMDKs was to use svMotion from the vSphere client.
Now that is not a solution I want to (or can) use in an automated environment. Continue reading