Got a comment on my share and share alike post that covered setting up shared VMDK files on VI3 / ESX 3.x. Seemingly it didn’t work any longer. Work or not, I figure it’s time to revisit this in a new way, using vCLI(rCLI)! This will require the following steps:

1. Download & install the vCLI
   First download & install vCLI. I’ll wait… Ready? Fire it up and CD into the bin folder:
    
2. Next we use vmkfstools.pl to create the disk:
   vmkfstools.pl –server 192.168.15.8 -c 10G -d eagerzeroedthick /vmfs/volumes/lab/shared.vmdk -a lsilogic

3. For each VM, walk through the add hardware wizard, selecting the following:

1. Hard Disk

2. Use Existing Hard Disk

3. Browse to the location of the disk you created

4. Under “Advanced Options” Change the “virtual device node” select a device that is on an unused adaptor (generally something in the 1: or 2: range) here’s a picture to help:
   
   Note: Use the same on both VMs. Consistency is good. mmmkay?

5. Back under edit settings for the new VM, change the new disk controller’s “SCSI Bus Sharing” to “Physical”:
    
4. Repeat for both VMs
5. At this point you can power on the VMs & follow your OS vendors setup guideline for shared disks.

Hope you found this informative. Questions, comments, corrections, or requests? Drop a line in the comments!

If you are looking for a detailed explanation of the features and enhancements to the storage stacks in ESX 4 as well as the differences between storage in ESX 3.5 and 4.0, the following presentation has what you are looking for:

vSphere Storage: Features and Enhancements

This presentation was written and delivered by Nathan Small, a staff engineer working in VMware support, at the Mid-Missouri VMUG in August 2009.

While it is a somewhat known fact that you used to be able to shrink disks using vmkfstools -X in ESX 2.x, the option was removed as of ESX 3.0. The reason for this probably stems from those few customers that were not familiar with using the command properly and ended up cutting off too much of the disk and corrupted their Guest OS file system as a result.

Ever since the option was removed there have been more experienced users wanting the option to be added back to vmkfstools as they are aware of the risks and want that ability again. For those people I just mentioned, I have a treat for you:

** Use this technique at your own risk. I do not and will not take responsibility for your corrupted vmdk’s as a result of following this process, whether correctly or incorrectly **

If you have ever taken a look at the descriptor file for a vmdk file, you will the “Extent description” section:

# Extent description
RW 52428800 VMFS “foo-flat.vmdk”

The value between ‘RW’ and ‘VMFS’ is the size of disk when divided by 512:

52428800 * 512 = 26843545600 (25G)

-rw——- 1 root root 26843545600 Sep 18 19:10 foo-flat.vmdk
-rw——- 1 root root 370 Sep 18 19:11 foo.vmdk

If you want to shrink (or increase) the size of your vmdk file, alter this value in the descriptor file to reflect your new desired size*. You can do with this ‘vi’ or ‘nano’:

* For this example I will to shrink the disk to 12.5G

# Extent description
RW 26214400 VMFS “foo-flat.vmdk”

After making this change you can use ‘vmkfstools -i’ to clone this disk:

# vmkfstools -i foo.vmdk foo_1.vmdk
Destination disk format: VMFS thick
Cloning disk ‘foo.vmdk’…
Clone: 100% done.

You will discover that the cloned disk now reflects the new size of 12.5G:

-rw——- 1 root root 13421772800 Sep 18 19:13 foo_1-flat.vmdk
-rw——- 1 root root 372 Sep 18 19:13 foo_1.vmdk
-rw——- 1 root root 26843545600 Sep 18 19:10 foo-flat.vmdk
-rw——- 1 root root 370 Sep 18 19:11 foo.vmdk

This technique will also work if you try to cold migrate the VM or Storage VMotion it. This would be less cumbersome than trying to play around with another disk at the command line during a simple shrink process. Change your values and then migrate the disks via VI Client/VC to a different datastore. This will reduce disk space required for this operation and it will be a whole lot cleaner than a manual clone with vmkfstools and then a remove of the original.

SVMotion would be the a favourable option for those that do not want to incur downtime for their VM.

Late Tuesday evening I was troubleshooting an issue with a Mr. Smith from #vmware on Freenode. Yes, really, his name was smith. The issue we were troubleshooting was related to sharing VMDK files, between two VMs running on separate hosts.

After pointing Mr. Smith to my “Share and Share Alike” and feverently insisting that it would work. “Really”, I promised, “I use it all the time.” He provided me some screenshots of the error he was getting in return:

Descriptive isn’t it? So we chased it down this morning. What happened here was that one of the two VMs in the config had snapshots running. After deleting the snaps, and before the song with Leprechauns and Unicorns, the disk added on the second VM and powered on. As a result, the world was made a much happier place.

If you have any questions on this post or any others, please feel free to hit me up on twitter, or drop a line in the comments section.

Time for a new series! Are you as excited and motivated as I am? In this series we’ll cover the Tops and Bottoms of VMware disk types. What are they, how do you make them, what are the benefits and drawbacks, and when would you use them. A lot to cover? Sure IS, but that is why it’s a series. I’ll try to get these out once a week as time permits. Seems simple enough right? It is really. There are five basic food groups when it comes to VMware ESX 3.5.x and disk types:

• Zeroed Thick
• Eager Zeroed Thick
• Thick
• Thin
• Raw

Thats it really. We’ll get into the specifics of each one of these in their own post in the series. The other 6 parts of this series will explain each of these in detail.

This can be used to enable ‘MSCS’ in a box, in a lab scenario, or any other sort of setup, where more than one VM will require access to the same disk. Careful here though, your file system will need to support this as well. Read on for more.

First we need to make the disk:

Log into the service console and execute the following:
[root]# vmkfstools -c 249G -d thick /vmfs/volumes/250/shared.vmdk -a lsilogic

Reading that, it tells vmkfstools to create a 249 GB disk file, in a thick file with an adaptor type of Lsi Logic. The Thick formatting is critical, as it is what enables parts of this process. *Note, under normal circumstances Thick disk files are a security risk.

Next we add it to the VM’s

Use the existing disk:

Select the disk:

Use a new, unused SCSI Adaptor:

Last step:

There are our devices, make sure the adaptor is in Physical mode:

Hope this was helpful. Please leave any questions or thoughts in the comments.