If you would like to read the other parts in this article series please go to:
- Storage planning for Hyper-V Hosts (Part 1)
- Storage planning for Hyper-V Hosts (Part 3)
- Storage planning for Hyper-V Hosts (Part 4)
- Storage planning for Hyper-V Hosts (Part 5)
- Storage planning for Hyper-V Hosts (Part 6)
Introduction
Many large enterprises use storage area networks (SANs) for some or all of their storage needs. SANs are devices that provide block-level storage for servers over own dedicated network. A number of different network architectures are used by SANs including:
- Fibre Channel (FC) which transfers data between the SAN and servers using the Fibre Channel protocol together with proprietary cabling and connectors.
- Fibre Channel over Ethernet (FCoE) which encapsulates FC packets in Ethernet frames so the data can be transported over a standard Ethernet networking infrastructure.
- iSCSI which enables SCSI commands to be transported over IP networks.
If a business already has a SAN deployed in their environment, it only makes sense to use it as the main storage device for all your servers if this is possible. And it has been possible since Windows 2000 Server because Microsoft has designed this and later versions of Windows Server to be able to boot the operating system directly from SAN instead of having to use a local disk inside or attached to the server.
In the boot from SAN approach, the operating system resides on the SAN, not on a disk inside or directly attached to the server. A host bus adapter (HBA) inside the server is configured so the server can find the correct OS image to boot from on the attached SAN. In other words, the HBA on a server is configured to use a specific logical unit number (LUN) on the SAN.
Advantages of boot from SAN
Booting your Windows servers directly from your SAN has other advantages besides eliminating the need to purchase disk drives for each server in your environment. For example, you can now use diskless blade servers that can fit into racks in your datacenter. Blade servers generally take up less space and use less electrical power than tower servers. Blade servers may either be less or more expensive than comparable towers however, depending on the vendor you procure from.
Boot from SAN also makes it easier to ensure business continuity in the event of a disaster. By simply replicating the storage from the SAN in your datacenter to another SAN at a remote site, you can ensure you will be able to recover your business operations quickly should something befall your primary site.
Boot from SAN also makes it easier to manage the operating system images for your servers. That’s because all of your system volumes are located in one place instead of being distributed across multiple systems all over your site. This also means you can deploy new OS images more rapidly, which can enable your business to scale up more quickly to stay aligned with the marketplace.
Boot from SAN can also boost the availability and performance of your servers by using redundant HBAs, switches, cabling and controller ports on the SAN. Windows Server 2008 R23 and later includes support for Multipath I/O (MPIO), which allows redundant physical path components to be used to create multiple logical paths between the server and the SAN.
Booting Hyper-V hosts from a SAN
You can definitely configure Hyper-V hosts to boot from SAN instead of from local storage. In fact, there are no special requirements for implementing boot from SAN with Windows Servers running the Hyper-V role as opposed to servers that don’t have this role installed. Nevertheless, the servers in your datacenter may or may not support booting from SAN, so don’t jump on the bandwagon just yet. To determine whether a particular server system can successfully boot a particular Windows Server operating system from SAN, you need to do two things:
- Check whether the server system is certified for that particular Windows Server operating system. You can determine this by searching the Windows Server Catalog for your system. See http://windowsservercatalog.com.
- Contact the vendor or OEM you acquired the system from and ask whether their system supports booting from SAN.
If the system is certified in the Windows Server Catalog and the vendor has confirmed that it supports boot from SAN, you can then proceed with configuring your system to boot from your SAN. How do you do this? It depends on the systems and the SAN involved, and in general you’ll need to talk with both your system vendor and SAN vendor to find out what specific steps you need to configure your system, the HBA you’ve installed in your system, and your SAN infrastructure.
For an example walkthrough using a Fibre Channel SAN, an older Emulex HBA, and an older operating system (Windows Server 2008 R2) you can see the whitepaper titled “Windows Boot from SAN – An Executive Overview and Detailed Technical Instructions for the System Administrator” which is available from the Microsoft Download Center.
This whitepaper was originally written for Windows Server 2003 and was later updated for Windows Server 2008 R2. Why hasn’t it been updated for Windows Server 2012 R2? Probably because implementing boot from SAN is basically a per-vendor procedure.
One key thing to remember however when configuring boot from SAN is to have only one storage path configured during the operating system provisioning stage. Then once the OS has been deployed on the blade server you can use MPIO to configure a secondary storage path for redundancy purposes.
Booting virtual machines from a SAN
OK so you can store the root partition of a Hyper-V host on a LUN of a SAN to boot the host directly from your SAN. What about virtual machines running on your Hyper-V host? Can you boot a virtual machine from a SAN?
Yes and no, but mostly no. First, you can’t boot a virtual machine directly from an operating system on a LUN because the virtual Fibre Channel adapter included in Windows Server 2012 and later doesn’t include the necessary boot code to make this happen. Virtual Fibre Channel is a feature introduced in Windows Server 2012 that enables virtual machines to directly access Fibre Channel storage. Virtual Fibre Channel works with FC HBAs and FCoE converged network adapters. It’s a great feature, but it doesn’t support booting the virtual machine from the SAN.
However, there are two ways you can boot a virtual machine from a SAN:
- By booting it from a virtual hard disk (VHD) file stored on the SAN.
- By booting it from a passthru disk which in this case would be a LUN on the SAN.
These approaches are not recommended however because they involve creating and managing as many LUNs as you have virtual machines. So if you have dozens of virtual machines running on your Hyper-V host, you’ll need to manage dozens of LUNs on your SAN. That’s just not a good idea because SANs are intended to simplify storage management by centralizing your storage, they’re not intended to make storage more complicated in your environment.
A much better approach would be to put the boot volumes of your virtual machines on the shared volume of a host cluster and only place the data volumes of select virtual machines on your SAN and use virtual FC to allow them to access the data volumes.
Revisiting boot from SAN
So boot from SAN should generally only be used for booting your Hyper-V hosts from your SAN and not for booting the virtual machines running on these hosts. And boot from SAN can bring some definite advantages to your business as we described previously in this article.
But is booting Hyper-V hosts from a SAN really a good idea?
Maybe. The important question to ask yourself is why you want to boot your Hyper-V hosts from your SAN. Is it driven by company politics? By pure cost considerations? By a need for greater performance or availability?
Just because you already have a SAN deployed doesn’t mean you need to use it. In fact, if your SAN only has HDDs and no SSDs then you can make your existing Hyper-V hosts blazing fast by replacing the HDD on which their OS volume resides with SSDs. And since enterprise-class SSDs have been rapidly falling in cost while dramatically increasing in capacity, you can make such a replacement cheaply.
On the other hand, it may be better and almost as cheap to upgrade some of the HDDs in your SAN to SSDs and then use the SSDs for the LUNs your Hyper-V hosts will boot from. That way you can still centrally manage your storage while also gaining the performance benefit that using SSDs can bring.
Another boot from SAN consideration (and this is discussed briefly in the whitepaper referred to earlier) is that implementing boot from SAN can involve some tough choices. One of the toughest of these is where to put the pagefile of the servers that will be booting from SAN. In general, you can get best performance by placing the pagefile on a local disk instead of a LUN on your SAN. This means your blades will need at least disk (HDD or SSD) in them, and depending on the vendor this can drive up the cost considerably.
Also think about what might happen when your SAN vendor decides to release updated firmware for your SAN. You may need to take down all of your servers while you are updating your SAN firmware, and if something goes wrong with the firmware update you might not be able to start any of your servers.
On the other hand, there are some specific use cases where boot from SAN can be a godsend for companies. For example, let’s say one of your server systems suddenly dies. By applying the SAN profile of your dead server to a system held in reserve for such occurrences, the reserve system can immediately assume the identity and workload of the failed server, resulting in minimal interruption for your business. Of course, failover clustering can provide similar availability benefits, but there may be scenarios where the SAN approach is easier or more cost effective for you than the clustering approach.
Or let’s say you’ve been using a server system that boots from SAN for some specific purpose, and now you want to use that system for a different purpose. By simply changing the boot LUN the system is configured to boot from, the identity of the server changes and the system can be repurposed.
Then there’s the matter of monitoring storage utilization for your servers. Boot from SAN allows you to use the vendor’s software to do this. If you use local (direct attached) storage instead for your Hyper-V hosts, you’ll need to monitor storage across a wide variety of systems in your datacenter and for that you’ll need another monitoring solution like Microsoft Operations Manager, IBM Tivoli, HP OpenView, and so on. Such solutions cost money, but if you already have one of them you can use it without incurring further cost.
Conclusion
Whether to implement boot from SAN for your Hyper-V hosts is not a simple question. A lot of different things must be considered before you make a decision concerning this, and hopefully this article has provided you with some ways you can get your planning process started.
If you would like to read the other parts in this article series please go to:
