Is NFS Right for VMware?

VMware on NFS shines in day-to-day operations and is the easiest environment to live with

George Crump

December 13, 2008

3 Min Read
Network Computing logo

10:45 AM -- VMware 3.x provided the capability to utilize NFS mounted file systems to host VMware virtual machine image files known as VMDKs. After a slow start, NFS is starting to get a lot of attention on the VMware storage radar. However, there are some common misconceptions that you need to be aware of.

First, this is really not a Fibre Channel vs. IP protocol debate. It is really an NFS vs. VMFS debate. Actually, it is not even an NFS vs. VMFS debate. NFS is just a transfer protocol. This is really a VMFS vs. the file system of the chosen NAS debate. Each NAS manufacturer -- EMC Corp. (NYSE: EMC), NetApp Inc. (Nasdaq: NTAP), ONStor Inc. -- has its own file system, and the merits of that file system should be compared against VMFS. That said, there are some general capabilities that most of these suppliers bring to the table because of the sharing nature of a NAS.

VMFS is the file system that VMware provides on block-based systems to host virtual machine images, a file system that is sharable and clusterable on a SAN. That is no small feat, but as file systems go it has its limitations, and those limitations can be nicely answered by NFS. NFS and the NAS that utilizes it are by their nature a sharing-based device. VMDKs are essentially files, so it is not a great leap to propose that something designed to serve files might be well suited to the task.

Where VMware on NFS shines is in day-to-day operations. It is by far the easiest environment to live with. Creating and provisioning a VMware Datastore and configuring for VMotion using a NFS mounted service is simple. Resizing those stores, both larger and smaller, is just as easy and requires no service interruption with the virtual machines. In contrast, when using VMFS most VMware administrators will stop their virtual machines prior to attempting a datastore or even VMDK expansion just to be safe. Shrinking a datastore no matter how many precautions you take can cause big problems and is generally not advised.

The fact is that NFS is an IP-based protocol and not even an IP-based storage protocol. So that greatly simplifies operations and reduces cost. Planning however cannot be thrown to the wind. If performance problems develop, the complexity required to scale out an IP infrastructure begins to rival the alleged complexity of Fibre Channel.You may hit that performance wall sooner with IP than with Fibre Channel, since many infrastructures are still 1-Gigabit Ethernet based. 10-Gigabit Ethernet can solve much of the performance bottleneck, but thus far a standard 10-GigE NIC in a VMware Host only achieves about 40 to 50 percent of the available bandwidth because of queuing issues. To get around this, VMware developed NetQueue, which, when combined with a supported card from suppliers like Intel Corp. (Nasdaq: INTC), Neterion Inc. , and Solarflare Communications Inc. , achieves almost full line speed. All of that leads to added cost and complexity, which again minimizes some of the advantages.

There are some other challenges with NFS/NAS and VMware. You can't boot the ESX server with it, just the virtual machine, so if you want to boot everything from shared storage you will need to mix in another protocol. Second, it does not support RDM and, therefore, Microsoft Clusters. If that is important for you, again you will have to mix in another protocol. Finally it seems that, thus far, NFS support is the last protocol covered for some of the newer VMware features like Storage VMotion and Site Recovery Manager.

What we are seeing is that NAS/NFS is ideal for medium to low I/O requirement workloads, and Fibre is good for medium to high requirement workloads. In a future entry, we will look at the logic behind mixing the two and how hard that is to put together.

George Crump is founder of Storage Switzerland , which provides strategic consulting and analysis to storage users, suppliers, and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.

Read more about:

2008

About the Author(s)

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights