Windows Server 2012 (Windows Server “8″) – Virtual Fibre Channel

By Chris Evans	Article Rating:
October 5, 2012 11:51 AM EDT	Reads:	1,747

Related
Print
Email
Feedback
Add This
Blog This

This is one of a series of posts discussing the new features in Windows Server 2012, now shipping and previously in public beta as Windows Server 8. You can find references to other related posts at the end of this article. This post reviews the new Hyper-V 3.0 feature, Virtual Fibre Channel.

Background

Virtual Fibre Channel (VFC) enables a Hyper-V guest to access the physical storage HBAs (host bus adaptors) installed in the Hyper-V server. Normally, storage adaptors would be reserved for the use of the Hyper-V guest itself however this new feature acts as a passthrough, enabling any Hyper-V 3.0 guest (at the right O/S level) to access the HBAs and so connect directly to fibre channel storage devices.

VFC is implemented through the use of NPIV, or N_Port ID virtualisation. This a fibre channel standard that permits a single HBA to act as multiple nodes within a SAN environment. Normally, a single HBA connects to the SAN and presents a physical ID known as a World Wide Port Name or WWPN. This deals with the physical connectivity of the fabric. At the same time, the connecting server or storage device presents a node name ID or WWNN (World Wide Node Name). A WWNN can be unique per adaptor as is the case with most host-based HBAs or can be a single node representing an entire device such as a storage array. NPIV allows a single physical adaptor to present multiple node names to the fabric and so effectively “virtualise” the physical device. Each new node also has to have virtual WWPNs in order to adhere with fibre channel standards.

The benefits of being able to use NPIV to virtualise an HBA is that each guest in a Hyper-V environment can be assigned its own WWNN and so have a direct connection to the SAN. It may not be immediately obvious how this helps when virtual server infrastructure is supposed to abstract the physical layer but there are a number of distinct advantages in zoning storage devices in this way:

Zoning can be done to the individual guest and is therefore more secure (albeit that it still goes through the hypervisor)
Tape drives can be supported, so backup software can write directly to devices
Storage that requires failover, snapshots and other SCSI based functionality can be directly supported, especially where non-standard SCSI commands are used

Implementation

VFC is configured in Hyper-V Manager using the new Virtual SAN Manager option (see the screenshots). Only HBAs and firmware that support NPIV can be used for VFC. This means newer HBAs only, for example Emulex HBAs at speeds of 4Gb/s and above. Obviously the SAN fabric needs to support NPIV too. An HBA can only be attributed to one virtual SAN, however a virtual SAN can contain multiple HBAs. Once the virtual SAN is created, a virtual HBA can be assigned to a guest using the Add Hardware section under Settings. Fibre channel IDs can be set as any 16-digit hexadecimal number, although it’s not advisable to use values that are already reserved out for vendors. Microsoft defaults to some standard values, which can be auto-generated to new values through the “Create Addresses” button. As yet I’ve not worked out why there are two sets of addresses as only the first appears to be visible on the fabric.

As soon as a guest is started, the fabric login process begins, even if no guest O/S has been installed. As you can see from screenshot 4, the additional node indicates the source Hyper-V server (in this case PH03) but doesn’t pass through the guest name, indicating it only as “Hyper-V VM Port”. It would be a nice update to be able to see the VM name there.

CIO, CTO & Developer Resources

Using VFC within the Hyper-V guest requires two things; a supported O/S – one of Windows Server 2008, Windows 2008 R2 or Windows 2012 – plus the installation of the latest Integration Services update that comes with Windows Server 2012. This means that the virtual fibre channel adaptor is not emulated as a native device and so can’t be used with other operating systems like Linux (more on this later). The fifth screenshot shows the emulated HBA controller and tape drive I presented to the host. One question that seems to have been discussed on a number of blogs is the support for tape drives. I can confirm tape drives do work, but can’t see any documentation from Microsoft to say whether they are officially supported.

Performance

I chose a tape drive as this is a good way of demonstrating performance. Deploying Backup Exec 2012 onto my Windows 2008 R2 guest, writing to an LTO2 drive, I achieved around 12MB/s, better than I’ve managed with an emulated drive through vSphere 5.0. This is well under the spec of the drive itself (max 40MB/s) but is certainly usable in small environments. More testing is needed here I think, as there appeared to be little overhead on the Hyper-V server to manage the data passthrough.

The Architects View

Virtual Fibre Channel is a great feature for providing native SAN device support. However there are few restrictions on use, most notably on the need to have latest hardware and be using Microsoft platforms. I haven’t yet seen any best practices for using VFC; for example should HBAs be placed in a single virtual SAN or should multiple ones be configured for failover; these are questions that need to be answered. VFC could be massively improved on two fronts; firstly drivers could be provided for other platforms, especially Linux installations. Second, if vendors were able to write code using the virtual device, then virtual SAN appliances (VSA) could use fibre channel rather than be reliant on iSCSI as they are today.

One final comment; Microsoft are doing a poor job of providing detail on these new storage features. There is precious little to find, other than high-level blog information and as mentioned previously, no best practice documentation that I can locate. I’d be happy to be pointed in the direction of anything useful and I will link it from this post.