Using VMware ESX Virtual Switch Tagging with HP Virtual Connect
Using Multiple VLANs with HP Virtual Connect Flex-10

One thing that I wanted to really clarify was that you can present multiple VLANs to FlexNICs on the same LOM, but you can’t present the same set of VLANs to FlexNICs on the same LOM. I’m not sure that I made that clear enough in my other post. So, if you have VLANs 100, 101, 102, 103, and 200, you can present any number or combination of those to all the FlexNICs on a single LOM—but it must be in a non-overlapping configuration, so that the same VLAN isn’t presented to multiple FlexNICs on the same LOM. I plan on posting some sample configurations, with graphics, that should clarify things even more.

The other thing I wanted to clarify was why I posted an article about presenting multiple VLANs to FlexNICs on the same LOM. Usually, this topic comes up in the form of a question (and I’ve had several readers e-mail me about this) like this: “You state that you can’t present the same set of VLANs to multiple FlexNICs on the same LOM. Why in the world would you want to do that?”

That’s a good question! In a Flex-10 environment, you normally wouldn’t want to do that, and not just for the reason that it doesn’t work (although having a configuration that works is usually quite beneficial). Consider the value proposition behind Flex-10: it provides four logical NICs (the FlexNICs), each of whose bandwidth can be adjusted as needed, up to 10Gbps, based on the traffic requirements. Now consider the reason why administrators normally use multiple NICs: more bandwidth. Considering that you can allocate bandwidth easily with a FlexNIC, there’s no need to use multiple FlexNICs on the same LOM to handle the same VLANs. A single FlexNIC can handle multiple VLANs just fine because you can allocate more bandwidth to that FlexNIC easily. And since presenting multiple VLANs to FlexNICs on different LOMs works just fine, you can use one FlexNIC from each LOM to gain redundancy. All the reasons for wanting to use multiple NICs are addressed by using only two FlexNICs, one from each LOM, and presenting as many VLANs as you like to those two FlexNICs.

However, having said all that, it is the default configuration in many VMware environments to present VLAN trunks to all ports on all ESX/ESXi hosts (i.e., to present the same set of VLANs to all ports). In a Flex-10 environment, you’ll have to break out of that line of thinking. Hence, why I posted the information that I posted, so that VMware administrators would realize they can’t follow the same configuration guidelines in the Flex-10 environment as they would follow in a more “traditional” networking environment. Just as virtualization with VMware requires server admins to approach things differently, the functionality offered by Virtual Connect also requires server admins to think a bit differently about how network connectivity is presented to VMware ESX/ESXi hosts.

Have more questions, or need additional clarification? Speak up in the comments. Thanks for reading!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Follow-Up About Multiple VLANs, Virtual Connect, and Flex-10

• Using Multiple VLANs with HP Virtual Connect Flex-10
• Using VMware ESX Virtual Switch Tagging with HP Virtual Connect
• Blades and Virtualization Aren’t Mutually Exclusive: Part Four, HP Traditional Expansion Options
• VMware ESX, NIC Teaming, and VLAN Trunking with HP ProCurve
• NetApp iGroup Strategies for VMware ESX

However, there is a key caveat to this approach that applies when using HP Virtual Connect Flex-10 and HP blades that have Flex-10 LOM (LAN on Motherboard) interfaces. As you might already know, Flex-10 LOMs have the ability to “subdivide” themselves into four logical instances, each of them a valid PCIe function, which are called FlexNICs. These FlexNICs appear as real, actual, physical NICs to the operating system installed on the blades. This includes VMware ESX/ESXi. In the Virtual Connect Manager, though, you have the ability to fine-tune the amount of bandwidth allocated to each of these FlexNICs, up to the shared maximum of 10Gbps.

This is pretty cool, but there is one limitation of which you must be aware—a limitation that is particularly significant in VMware ESX/ESXi environments. When you use the Multiple Networks option to map multiple VLANs onto a FlexNIC, you can’t map the same VLAN onto two different FlexNICs from the same LOM.

The FlexNICs are noted as LOM 1:a, LOM 1:b, LOM 2:a, etc. Again, as noted earlier, up to four FlexNICs are presented to the operating system on the blade. When you start assigning network connections in a Server Profile in Virtual Connect Manager, these network connections will bounce back and forth between the LOMs (assuming there are no other network interface cards in the server blade):

First network connection > LOM 1:a
Second network connection > LOM 2:a
Third network connection > LOM 1:b
Fourth network connection > LOM 2:b
…
Seventh network connection > LOM 1:d
Eighth network connection > LOM 2:d

As far as I know, there is no way to change this behavior.

With that in mind, what this means is that you can’t map the same VLANs to the first, third, fifth, and seventh network connections, or to the second, fourth, sixth, or eighth network connections. Why? Because each of these connections are logical FlexNICs on the same LOM, and you can’t map the same VLANs to more than one FlexNIC on the same LOM.

Perhaps an example would help. Consider the configuration shown in this figure, in which multiple VLANs are mapped to all eight connections in Virtual Connect Manager:

This screenshot shows how the VLANs are mapped for each of those eight network connections:

As you can see, I have the same set of five VLANs mapped onto all eight network connections (all eight logical FlexNIC instances). But only the first two show OK—the rest show Critical. Why? Because these logical FlexNICs have the same VLANs mapped to them as were mapped to the first FlexNIC, and therefore Virtual Connect Manager has placed them into a Critical state (they’ll be reported as “Down” to an operating system on the blade).

This behavior is the strange behavior I tweeted about a few days ago, where I couldn’t figure out why Virtual Connect was behaving in the way that it was. Now I know why!

Contrast that first configuration with the configuration shown in this screenshot:

In this case, you’ll note that I do not have the same VLANs mapped to more than one FlexNIC on the same LOM. As a result, Virtual Connect Manager does not place any of the FlexNICs into a Critical state, and all eight show OK (and will be reported as Up to an operating system on the blade).

So what does this mean? In its simplest terms, it means you can’t use VST on all the FlexNICs—some of the FlexNICs will have to carry “ordinary” traffic to VMware ESX/ESXi port groups that have no VLAN ID specified. In the image above, you can see that the first three pairs of FlexNICs each carry a specific type of traffic. The matching output of esxcfg-vswitch --list for this VMware ESX host shows that the port groups on each of the three matching vSwitches do not have any VLAN IDs specified. This is because, in this configuration, these three pairs of FlexNICs carry only a single type of traffic, and that single type of traffic has no VLAN tags attached. Therefore, the VMware ESX/ESXi port groups must not have a VLAN ID specified in order for traffic to flow.

But it also presents some other interesting design considerations. If your VMware ESX Service Console (or VMware ESXi Management interface) is on the same VLAN as some of your virtual machines, you’ll run into an issue—you won’t be able to map the VLAN to one set of FlexNICs for Service Console traffic and then map that same VLAN to another set of FlexNICs for other virtual machine traffic. In effect, it greatly reduces the extent to which you can use VST on VMware ESX/ESXi hosts.

Of course, the other way of handling it is to assign only two network connections, map multiple VLANs to those network connections, assign the full 10Gbps of throughput to those two FlexNICs (network connections), and use a single vSwitch design.

As far as I can tell, this is not documented by HP in the Virtual Connect (or Flex-10) documentation. So, you might want to bookmark this article, or post it to Delicious.com or similar. Finally, as always, I’d love to hear any feedback or clarifications in the comments. Thanks!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Using Multiple VLANs with HP Virtual Connect Flex-10

• Follow-Up About Multiple VLANs, Virtual Connect, and Flex-10
• Using VMware ESX Virtual Switch Tagging with HP Virtual Connect
• VMware ESX, NIC Teaming, and VLAN Trunking with HP ProCurve
• Link State Tracking in Blade Deployments
• VLANs and Port Groups

If you have a question you’d like to see addressed during the session, here’s your opportunity to submit your question in advance! Use the form below to submit questions to be considered for inclusion in the Ask The Experts session. The panel will select a small number of questions that will be addressed during the session at VMworld 2009, along with questions submitted by the audience during the session.

Thanks, and I look forward to seeing many of you in San Francisco later this year!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Submit a Question for VMworld 2009 Ask the Experts Session

• TA2259 Ask the Experts at VMworld 2009
• VMworld 2009 Spouse Activities
• Spouse Activities for VMworld 2009
• Heading to VMworld 2007!
• A Collection of VMworld 2007 Links

Only time will provide the full picture, but an initial glance at Altor’s press release and a pre-release discussion I had with Altor lead me to believe that VMsafe really will change the landscape of security solutions in VMware environments. By leveraging VMsafe in fast-path mode—meaning that the security solution runs as a module in the hypervisor—Altor is able to provide not only firewalling functionality but also intrusion detection functionality as well. In fact, the intrusion detection features can be configured to work only on traffic that successfully passes through the firewall rules.

Altor also claims much greater performance with Altor VF 3.0, up to ten times the performance of a virtual machine-based security solution. And, of course, Altor has ensured that their virtual firewall product can apply firewall rules at various levels within the VMware vCenter Server hierarchy, and the product also helps protect the hypervisor management interfaces as well (the Service Console interfaces in ESX, Management interfaces in ESXi).

The initial release of Altor VF 3.0 will use a separate web-based management console, but Altor Networks did indicate that they are investigating the use of a plug-in for the vSphere Client for more integrated management. Future versions of Altor VF also plan to address vApp integration, something that is missing from the initial release.

For more detailed information or for the full press release, visit Altor Networks’ web site.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Altor Announces VMsafe-Integrated Altor VF 3.0

• First Look: Altor Networks VNSA
• A Couple of Product Announcements
• OVF Format Released, VMAN Initiative Launched
• VMware ESX 3.5 U2 Validated via SVVP
• VMware’s Virtual Datacenter OS

When used in conjunction with ESX Server, shared uplink sets force the use of EST because VLAN tags are stripped away by the Virtual Connect switch. Therefore, the ESX Server can’t use the VLAN tags, and must resort to a different vSwitch—each with one or more pNICs as uplinks—for each VLAN/associated network. This solution may be useful in some situations, but typically wouldn’t scale well for environments with many different VLANs.

It turns out that a firmware revision to the HP Virtual Connect software addresses this problem. As I’ve recently had the opportunity to work with an HP Virtual Connect Flex-10 module (you can expect to see some articles on Flex-10 in the near future), I wanted to revisit the idea of using HP Virtual Connect with VMware ESX/ESXi. In this post, I’ll describe how you go about configuring HP Virtual Connect so that you can use Virtual Switch Tagging (VST) and Shared Uplink Sets together. Each of the steps is described in one of the sections below.

Configure VC for VLAN Mapping

Before you even create the Shared Uplink Set, you must first configure the Virtual Connect module to use VLAN mapping instead of VLAN tunneling.

To access the option for configuring VLAN mapping, you can use the menu bar across the top of the right side of the HP Virtual Connect Manager. Simply click Configure > Ethernet Settings, then click on the Advanced Settings tab. There you will see the option to either tunnel VLAN tags or map VLAN tags. Choose to map VLAN tags. Optionally, you can click the check box to force server connections to use the same VLAN mappings; this will eliminate a step later but limits the overall flexibility of the solution. It’s up to you if you want to use this option.

Create the Shared Uplink Set

Now you’re ready to create the Shared Uplink Set. Using the menu bar across the top of the right side of the HP Virtual Connect Manager interface, simply choose Define > Shared Uplink Set. Specify a name for the uplink set, then choose the external uplink ports. While you here, you can also go ahead and create the associated networks you’ll need later.

Create the Associated Networks

Either while you’re creating the Shared Uplink Set or after the Shared Uplink Set has been created, you can add the Associated Networks. While you are editing the Shared Uplink Set, simply click the Add Network button under the Associated Networks area and define one or more VLANs. The following parameters are available when you define an Associated Network:

• Network Name and VLAN ID: These are pretty self-explanatory. The VLAN ID here needs to match the external VLAN ID on the rest of the network.
• Native: If this VLAN is marked as the native VLAN on the rest of your network, check this box. This network would then receive all of the untagged traffic on the uplink set.
• Smart Link: If you would like this network to be marked as down if the uplinks go down, check this box.
• Private network: With this box checked, the network will act like a private VLAN–nodes on this network cannot communicate with each other.
• Advanced: This area allows you to set a custom speed for either the preferred speed or the maximum speed.

After you’ve defined the Associated Networks, then you’re ready to create the Server Profile—and that’s where the real magic in making VST is found.

Assign Networks in the Server Profile

Once again, you’ll use the menu bar across the right side of the HP Virtual Connect Manager to create a Server Profile. Simply select Define > Server Profile. In the Server Profile, you’ll add a network for each NIC present in the server blade (for a blade with Flex-10 NICs and a Flex-10 module, you will have eight NICs). When prompted for what network to associate to that NIC, choose Multiple Networks. Then click the small Edit button just to the right of the Network Name drop-down to show the Server VLAN to vNet Mappings screen.

The fact that you selected “Multiple Networks” when you added the connection to the Server Profile means that Virtual Connect will pass the VLAN tags up to the blade. The fact that you configured the Virtual Connect module to use VLAN mapping now means that you can create an association between the VLAN tags that a server uses and an corresponding Associated Network.

If you want to keep the server’s VLAN tags and the Associated Networks’ VLAN IDs matched up, just follow these steps:

1. Check the box labeled Force Same VLAN Mappings As Shared Uplink Sets.
2. Choose the Shared Uplink Set from the drop-down list.
3. Place a check mark next to each Associated Network/vNet/VLAN. This tell the Virtual Connect module to include that VLAN.
4. Place a check mark under Untagged for whichever Associated Network is should be handled as the untagged (native) VLAN.

If, on the other hand, you want to specify different server VLAN tags than Associated Network/vNet VLAN IDs, leave the check box for Force Same VLAN Mappings As Shared Uplink Sets unchecked, and specify the server VLAN ID that should be used for each Associated Network/vNet. For example, if the server was using VLAN ID 10 to refer to the Production network, but the Production network was using VLAN 1000 on the Associated Network and on the rest of the network, then choose the Associated Network that represents the Production network and specify a server VLAN ID of 10. This allows you to create a mapping between the VLAN tags the server uses and the VLAN tags the rest of the network uses.

After you’ve defined the Server Profile and created the vNet mappings, attach the Server Profile to a blade running VMware ESX/ESXi and you’re good to go! Within VMware ESX/ESXi, you would configure the vSwitches, distributed vSwitches, and port groups as you would normally.

How I Tested

My testing was performed on a HP Virtual Connect Flex-10 module running firmware revision 2.10. The Flex-10 module was uplinked via a single 10Gbps connection to an HP ProCurve switch. The blades were running VMware ESX 4.0.0.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Using VMware ESX Virtual Switch Tagging with HP Virtual Connect

• HP VirtualConnect Clarification
• Using Multiple VLANs with HP Virtual Connect Flex-10
• Follow-Up About Multiple VLANs, Virtual Connect, and Flex-10
• Link State Tracking in Blade Deployments
• Xsigo I/O Director Tips and Tricks

Rightfully so, some readers and other bloggers pointed out that PVSCSI isn’t supported for boot disks (Rich Brambley put up a really good post, for example). Rich, among others, suggested moving virtual machines back to a “two disk model,” with a boot disk and a separate data disk; this would allow for the greater performance of the PVSCSI controller on the data disk. This seemed to be a reasonable workaround. I don’t recall hearing about any significant issues with VMXNET3. Using the newer network driver seemed to be a good move all the way around.

Unfortunately, there is another drawback to both of these devices. Rich caught this drawback in his article, but relegated it to a small mention at the very end of the article that even I overlooked at first (emphasis mine):

There are some other factors to consider as well. For example, vSphere Fault Tolerance cannot be enabled on a VM using PVSCSI.

That’s right—you cannot use VMware Fault Tolerance (FT) on a virtual machine that is using the PVSCSI device. However, this restriction doesn’t just apply to the PVSCSI device; it also applies to VMXNET3! VMware FT cannot be enabled on a virtual machine using either the VMXNET3 or PVSCSI devices; vCenter Server will simply report an error that the network interface or disk controller isn’t supported for VMware FT.

In my opinion, this is a significant enough limitation that I felt it warrants its own post. If you are planning on using VMware FT in your environment, be sure not to configure any virtual machines to use VMXNET3 or PVSCSI if they might need to be protected with VMware FT. In this case, you’ll have to choose from either maximum performance or maximum protection—you don’t get both.

UPDATE: Rich Brambley shared links to two resources that describe the incompatibility between VMware FT and PVSCSI and VMXNET3:

VMware Communities: Unable to configure FT with error “Unsupported virtual machine configuration for Fault Tolerance. Device ‘Network adapter 1′ is not supported”
VMware Fault Tolerance Requirements and Limitations

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Another Reason Not to Use PVSCSI or VMXNET3

• vSphere Virtual Machine Upgrade Process
• Enabling Enhanced VMXNet
• Get Used to vSphere
• The Return of Virtualization Short Takes
• Hyper9 VMM Released

I’ve discussed this topic before, but I felt like it was a topic that needed to be revisited again. Storage admins need to know how their choices in storage technologies may or may not impact virtualization efforts, and this particular choice—leveraging pointer-based snapshots or deduplication—is particularly important.

FlexClones Versus Deduplication with VMware Infrastructure

A number of times over the last few months, I’ve run into situations where NetApp’s FlexClone technology was being heavily pitched to customers interested in deploying, or expanding their deployment of, VMware Infrastructure.

In case you aren’t familiar with the use of NetApp FlexClones in conjunction with VMware Infrastructure, have a look at these earlier articles of mine:

How to Provision VMs Using NetApp FlexClones
NetApp FlexClones with VMware, Part 1
NetApp FlexClones with VMware, Part 2
LUN Clones vs. FlexClones

Now, after you’ve read all those articles (you did read them, didn’t you?), it should be fairly clear that using FlexClones can be very advantageous. However, those advantages come with some tradeoffs as well, most notably in the complete and total lack of integration with VMware Infrastructure itself.

This lack of integration means that users can’t use VirtualCenter templates, because the cloning is taking place at the storage array instead of within VMware Infrastructure. This also means that customers can’t apply customization specifications during the cloning process, so users will need to create their own Sysprep answer files and manually Sysprep the VMs before invoking the FlexClone process. Users are required to create scripts and tools to do simple things like using the VM name for the guest OS name during cloning. (Author’s note: many of these issues have been addressed by NetApp’s Rapid Cloning Utility (RCU), which provides some integration into VirtualCenter.)

Deduplication, on the other hand, works seamlessly with VMware Infrastructure. This is primarily because the details of the deduplication are completely hidden; it all occurs “inside the box.” Nothing needs to be configured within VirtualCenter; no VMs need to be modified. The NetApp storage system handles the details of the deduplication process itself, and VMware Infrastructure just consumes the storage.

Looking at these two technologies in that light, one might ask: why use FlexClones at all? If deduplication works seamlessly with VMware Infrastructure and FlexClones don’t, then why bother? To be honest, there are some instances where FlexClones make sense—even with the lack of integration. Consider some of the examples listed below.

• In instances where a user needs to deploy lots of VMs in a very rapid fashion, FlexClones are much better. If time-to-deployment is the #1 driving factor, then FlexClones are the way to go. This could be particularly applicable and useful in VDI situations, as long as the broker doesn’t mandate handling provisioning itself (like VDM does).
• In environments where provisioning and re-provisioning occurs on a frequent, regular basis, then FlexClones make sense. Even though large numbers of VMs aren’t being provisioned, the time saved on frequent re-provisioning via FlexClones will not be insignificant.
• In situtations where there isn’t sufficient storage for the VMs before they are deduplicated, FlexClones may be a better option. Deduplication is post-process, meaning that storage will be needed for the full datasets until deduplication runs. In situations where that isn’t an option, then FlexClones can provide the same end benefit.

Personally, I’m of the opinion that unless an organization meets one of these criteria, then that organization should look to deduplication instead of FlexClones. Of course, that’s just my personal opinion, and I’m open to hear what others have to say about the matter. NetApp gurus, feel free to weigh in.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Republished: FlexClones or Deduplication?

• FlexClones Versus Deduplication with VMware Infrastructure
• NetApp FlexClones with VMware, Part 1
• 2031: Enhancements to NetApp Cloning Technology
• Storage Short Take #3
• Using NetApp Deduplication with Block Storage

1. First, all comments should be courteous. There’s no reason to personally attack another reader or author—simply state your position, why that is your position, the facts you feel support your position, etc. Leave the personal attacks somewhere else.
2. Second, all commenters should provide full disclosure. This helps avoid even the appearance of wrongdoing. Where a vendor’s products helps to address readers’ needs, I don’t mind a vendor mentioning their products. That vendor just needs to be sure to provide full disclosure. If you have a business relationship with an organization, disclose that. Be transparent and provide full disclosure.

Recently, I’ve had one commenter leave a series of comments on the site that blatantly and bluntly promote his employer’s products. Unfortunately, this commenter has failed to provide full disclosure. For that reason, I’ve been simply deleting this commenter’s comments. And I’m going to continue to delete this commenter’s blatant, outright comment spam as long as he/she refuses to provide full disclosure. Other readers deserve the right to know why a commenter is pushing a particular product or feature!

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

A Comment Policy Reminder

• Train Signal, Welcome!
• Question to my Readers
• Storage Short Take #1
• Blogging Frequency May be Down
• The Site’s First Sponsor

In this article, I’m going to tackle what will probably be a sensitive topic for some readers: VMware over NFS. All across the Internet, I run into article after article after article that sings the praises of NFS for VMware. Consider some of the following examples:

• VMware over NFS - Why?
• Why VMware over NetApp NFS
• VMware & NFS

That first link looks to be mostly a reprint of this blog post by Nick Triantos. Now, Nick is a solid storage engineer; there is no question in my mind that he knows Fibre Channel, iSCSI, and NFS inside out. Nick is certainly someone who is more than qualified to speak to the validity of using NFS for VMware storage. But…

I am going to have to disagree with some of the statements that are being propagated about NFS for VMware storage. Is NFS for VMware environments a valid choice? Yes, absolutely. However, there are some myths about NFS for VMware storage that need to be addressed.

1. Myth #1: All VMDKs are thin provisioned by default with NFS, and that saves significant amounts of storage space. That’s true—to a certain point. What I pointed out back in March of 2008, though, was that these VMDKs are only thin provisioned at the beginning. What does that mean? Perform a Storage VMotion operation to move those VMDKs from one NFS datastore to a different NFS datastore, and the VMDK will inflate to become a thick provisioned file. Clone another VM from the VM with the thin provisioned disks, and you’ll find that the cloned VM has thick VMDKs. That’s right—the only way to get those thin provisioned VMDKs is to create all your VMs from scratch. Is that what you really want to do? (Note: VMware vSphere now supports thin provisioned VMDKs on all storage platforms, and corrects the issues with thin provisioned VMDKs inflating due to a Storage VMotion or cloning operation, so this point is somewhat dated.)
2. Myth #2: NFS uses Ethernet as the transport, so I can just add more network connections to scale the bandwidth. Well, not exactly. Yes, it is possible to add Ethernet links and get more bandwidth. However, you’ll have to deal with a whole list of issues: link aggregation/802.3ad, physical switch redundancy (which is further complicated when you want to use link aggregation/802.3ad), multiple IP addresses on the NFS server(s), multiple VMkernel ports on the VMware ESX servers, and multiple IP subnets. Let’s just say that scaling NFS bandwidth with VMware ESX isn’t as straightforward as it may seem. This article I wrote back in July of 2008 may help shed some light on the particulars that are involved when it comes to ESX and NIC utilization.
3. Myth #3: Performance over NFS is better than Fibre Channel or iSCSI. Based on this technical report by NetApp—no doubt one of the biggest proponents of NFS for VMware storage—NFS performance trails Fibre Channel, although by less than 10%. So, performance is comparable in almost all cases, and the difference is small enough not to be noticeable. The numbers do not, however, indicate that NFS is better than Fibre Channel. You can read my views on this storage protocol comparison at my site. By the way, also check the comments; you’ll see that the results in the technical report were independently verified by VMware as well. Based on this information, someone could certainly say that NFS performance is perfectly reasonable, but one could not say that NFS performance is better than Fibre Channel.

Now, one might look at this article and say, “Scott, you hate NFS!” No, actually, I like using NFS for VMware Infrastructure implementations, and here’s why:

• Provisioning is a breeze. It’s dead simple to add NFS datastores.
• You can easily (depending upon the storage platform) increase or decrease the size of NFS datastores. Try decreasing the size of a VMFS datastore and see what happens!
• You don’t need to deal with the complexity of a Fibre Channel fabric, switches, WWNs, zones, ISLs, and all that. Now, there is some complexity involved (see Myth #2 above), but it’s generally easier than Fibre Channel. Unless you’re a Fibre Channel expert, of course…

So there are some tangible benefits to using NFS for VMware Infrastructure. But let’s be real about this, and not try to gloss over technical details. While NFS has some real advantages, it also has some real disadvantages, and organizations choosing a storage protocol need to understand both sides of the coin.

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Republished: Dispelling Some VMware over NFS Myths

• Only Thin Provisioned in the Beginning
• Proving VMware Over NFS
• Articles in Progress
• Storage Protocol Performance Whitepaper from NetApp
• Keeping Thin VMDKs Using NetApp SnapRestore

I haven’t hid the fact that I’m not really a fan of FCoE (see here or here), but I was starting to warm to the technology and thought that I was beginning to see some benefits to deploying FCoE. Namely, the fact that FCoE is inherently very compatible with “traditional” FCP, allowing organizations to leverage their existing FCP installation while transitioning to FCoE. Some hands-on time I’d recently spent with a Cisco Nexus 5000 switch showed me just how closely aligned the two technologies are and how (relatively) easy it was to extend an FC fabric using FCoE. OK, I think I get this.

Then, a few days ago, I read this article on FCoE divergence. Given that The Register can sometimes be quite sensationalist (and that’s putting it mildly), I contacted a colleague of mine whose input and knowledge I trust. He informed me that FCoE was currently limited in that FCoE is not multi-hop enabled—meaning, you can’t connect FCoE initiators on one switch to FCoE targets on another switch. (Apparently, this shortcoming is due to be corrected shortly.)

Whoa! That’s a limitation of which I was not aware. And with that limitation in mind, knowing that FCoE will—for the time being at least—be limited to convergence at the edge, I have to ask: why deploy FCoE at all? What real and specific benefits does an organization seek to gain by deploying FCoE as opposed to just deploying FC? Is the edge convergence really that worthwhile and valuable?

This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.

Thinking Out Loud: Why Deploy FCoE?

• Is Unified Fabric an Inevitability?
• A Collection of Viewpoints on Cisco UCS
• FCoE versus MR-IOV…huh?
• Continuing the FCoE Discussion
• Blades Won’t Die, But They Will Change