VMware VMFS (Virtual Machine File System) is VMware, Inc.’s cluster file system designed for VMware Infrastructure or VMware vSphere. Basically VMFS used to store virtual machine disk images, including snapshots.

According to Wikipedia,

• VMFS version 1 was used by ESX Server v1.x, which is no longer sold. It didn’t feature the cluster filesystem properties and was used only by a single server at a time. VMFS1 is a flat filesystem with no directory structure. — Officially named “VMware File System”
• VMFS version 2 is used by ESX Server v2.x and (in a limited capacity) v3.x. VMFS2 is a flat filesystem with no directory structure. — Officially named “VMware File System”
• VMFS version 3 is used by ESX Server v3.x and vSphere (4.x). As a most noticeable feature, it introduced directory structure in the filesystem. Older versions of ESX Server cannot read or write VMFS3 volumes. Beginning from ESX 3 and VMFS3, virtual machine configuration files are stored in the VMFS partition by default. — Officially named “VMware Virtual Machine File System”

In order to know the exact VMFS version number, see below:

1. VMware ESX 3 – VMFS ver 3.21
2. VMware ESX 3.5 – VMFS ver 3.31
3. VMware vSphere 4 – VMFS ver 3.33
4. VMware vSphere 4.1 – VMFS ver 3.46

Please take note that migration between different VMFS version may cause some problem in the sense of vSphere vStorage features, probably you may read more here or refer to vSphere Upgrade Guide.

I found that the partition table for vSphere 4 is totally different as ESX 3.5 did. At 1st was confusing as I only have 1 logical drive with RAID 1 configuration on my vSphere 4 machine, but when I did the cat /proc/partitions, it showed as 2 physical devices as sda and sdb.

I tested to delete the partition table from the fdisk utility as I did on usual Linux, but is not success. The system will roll back to the existing partition table before I tried to make the changes automatically. You may see the IO error happen when you try to write the partition table. At the same time, I found that there is a vmdk with similar 8GB of flat file and vmdk was created on the existing datastore which reflect the local storage on the vSphere host. It is viewable through CLI and vCenter client both. After some research, looks like the virtual disk is referring to vSphere core module and important mount point such as / & /var/log. Whenever I tried to remove the virtual disk from the ESX host, I get denied with error message of the virtual disk in use.

This 2 screen shots had helped me to understand that the new system partition method in vSphere 4, which is totally different as it did in ESX 3.5. At the mean time, I also found that to format the rest of the unclaim partiton on the local HDD for VMFS 3 file system as Datastore is compulsory during the setup too. Therefore, sizing on the partitions require to be planned prior to final deployment.

More review will be publish after my test on this. If the success of this products is true, we should able to save some money for some of the cases which may not require big SAN box to their environment to entitle the HA, DRS and Vmotion features. Stay tune.

You can have a look about the technology from here

Have a look here:
VMware ESX VMFS LUNs Report.

I would suggest you try snackcheck and smtp_send.pl scripts provided by YellowBricks.

Sending snapcheck html email from the service console
# /usr/local/bin/smtp_send.pl -t toyouremail@malaysiavm.com -s ” `hostname` Diskspace report of the VMFS volumes” -f fromemailadd@malaysiavm.com -m “`cat /var/log/vdf.html`” -r SMTPserver

To enable this on ESX host, you need to browse to the configuration tab of the ESX host, and right click the data store and select properties, and click on manage paths option in the GUI wizard. Click on Change button after that, and choose the Round Robin (Experimental) option and click OK. You will need to go through this process 1 by 1 to ensure you had round robin from each ESX host to each of the VMFS Data store.

For VM Guests, Just right click the VM and choose edit setting, and select to the hard disk which has shown as Mapped Raw LUN on the summary tab. Click on the Manage Paths and follow by the change button, and same you can easily configure to have the Round Robin enable.

ESX Host Configuuration

Wizard View for each Data Store connection from ESX

Policy Option which allow to change for Round Robin

Select the option of Round Robin

VM Guests Configuration

Click on Manage Paths to continue with the Round Robin Option in the next screen

You will actually see the same display and option at the last 2 steps compare the VM guests and ESX Host

As for the today, more users are actually deployed the mission critical and high I/O servers on the virtualization environment, but we do see some I/O bottle neck which cause by the storage performance always. VMDK do provide flexibility from management perspective, but it does sacrifice the performance you may require for your databases, files transfers and disk performance. I had run a couple of test with real case scenerio instead of I/O meter that been always use widely, and here is the summarize result I would like to share.

In disk perfomance, we always split it to 2 categories as sequential and random I/O. in sequential mode, you will see the huge different while you try to perform the file transfer locally or through network. My test environment is running with SAN storage from fiber channel with same LUN size and raid group which are created from the Storage Level. The only differences is VMFS Vs Raw.

Raid Group design 7+1 raid 5 configuration and run on MetaLun configuration

Each LUN size is 300GB

Performance monitoring tools = Virtual Center Performance Chart

VM Test Machine = 4 Vcpu, 8GB Memory

Operating System = SLES 10 x32, x64 ; Windows Server 2003 x32, x64

Sequential : RDM is out perform VS VMFS as it able to achieve > 2 times higher through put during the file transfer locally on the VM

Random I/O : The Raw Device Mapping is still out perform the VMFS and getting the similar through put with sequential file transfer. Multi session with random database query is been executed in the test

for NFS file transfer from VMFS to VMFS, I do see the bottle neck happen much more earlier than RDM.

Highest I/O rate for RDM = 180MB/s as during sequential files copy and DB query

Highest I/O rate for VMDK = 100MB/s during sequential files copy and DB query