You are on page 1of 20

A lot can be written about storage.

This posting will give a global overview of


storage integration by both vendors. I left out some of the features for a
future post.
The most important resource for virtual machine is storage and storage
performance in particular. Because of the nature of server virtualization
(virtual servers with different roles) the demand for storage resources is
almost impossible to predict. By far the most issues in virtual infrastructures
are storage related. Smaller environments with around 100 virtual servers
for less might likely not run into storage related performance issues very
often but enterprises are very likely to.
Infamous are issues with so called noisy neighbors; virtual machines which
all of a sudden demand lots of IOPS and will bring other VMs to a hold.
Personally I have seen this happen a couple of times. As an administrator
you want to have control over Storage IO-consumption.
SAN Support
Both vSphere and Windows Server 2012 Hyper-V support block level storage
(iSCSI and Fiber Channel).
For file level storage Hyper-V supports Windows shares over SMB. vSphere
supports NFS. I would say both solutions are equal on this.
Cheap shared storage/DIY storage
Storage arrays offers a lot of features but are not cheap. Especially when
FiberChannel is used this can be costly. Think about the FC HBAs in each
host, switches etc.
Microsoft offers SMB3 as an alternative and cheap to implement
protocol for FC . Using a cluster of Windows Server 2012 hosts and locally
attached storage accessed over SMB3 a relative cheap shared storage
solution can be created. Several design options are available.
VMware offers vSphere Storage Appliance (VSA) software which can be used
to create redundant storage out of cheap local harddisks. The software runs
on a VM running on the ESXi host. The VSA is now available for free when a
vSphere license is purchased. More info on VSA 5.1 here.
Vendors like StarWind also offer solutions to deliver SAN-alike features out of
regular locally attached storage.

Hyper-V is a winner on this aspect. Two Windows Server 2012 Standard


edition licenses are way cheaper (less tha $ 2000,- ) than VSA software.
Offload to storage
Some disk related processing is more efficient when done by the storage
layer. Examples are cloning a VM or moving the virtual disk to another
location. Both vSphere (VAAI) and Hyper-V (ODX) integrate with the firmware
of the storage to command the storage to perform datacopy actions.
Without VAAI/ODX data needs to be copied from the storage layer over the
network to the hypervisor and back to the storage layer. This takes times and
uses resources on the host.
At this moment Hyper-V ODX cannot be used to provision a new VM based on
a template. VMware VAAI is able to do that.
ODX support has been announced by vendors like EMC and Dell. All major
storage vendors support VAAI which has been available for some years now.
VMware is a winner here.
Storage IO Control/ Quality of Service
As mentioned before: you do not want a noisy neighbor to disturb
other much more business critical applications. VMware offers several
methods to guarantee one or more VMs a certain level of storage
performance.
First there is Storage DRS. This feature allows virtual disk files to be moved
to another storage location if the original storage location does
not deliver the requested performance. SDRS will also move virtual disk files
when available free storage space reaches a limit.
When a move of storage is not an option vSphere Storage IO Control can be
used. Basically this is a kind of Quality of Service. Without congestion on the
storage layer each VM can consume as much storage as it wants. When
latency reaches a certain critical level, VMs which are more important get
more resources. A bit like cars getting access on a dedicated lane of a
motorway in rush hours.
Windows Server 2012 Hyper-V does not offer any control to the storage layer
for individual VMs. On a converged network when muliple types of networks
(iSCSI storage, Live Migration, Cluster heartbeat, CSV redirection and VM
network) are using the same physical wire QoS can be used. However this is
set per type of network. Not per individual VM. When storage is accesses
over FC there is not control possible.

While SMB might not need Storage Control very often, Enterprise will need it
sooner or later. There are workarounds when a noisy neighbor has been
identified. It can be moved manualy for instance to another storage location.
In a large enviroment this is not what you want as an admin. It will take time
to identify the VM, space to move it etc.
VMware is a winner in the enterprise market. Mind SDRS and SIOC are
available only in the most expensive edition of vSphere.
Virtual disks size
VMware uses VMDK as the native virtual disk format. It is limited to a
maximum size of 2 TB.
Hyper-V uses VHD and VHDX. The latter supports a maximum of 64 TB. It is
self healing which mean it can overcome corruption caused for example by a
sudden shutdown of the VM.
Hyper-V is a clear winner here.
4K disk support
Hyper-V VHDX format supports 4K disks. vSphere 5 does not support 4K
disks. If you want to know more read this posting by Aidan Finn
Virtual disk replication
For disaster recovery purposes replication of the virtual disk can be a very
usefull feature. It allows to recover a virtual machines very quickly without a
lot of manual effort, time and recovery from backup media.
Windows Server 2012 Hyper-V offers a feature named Hyper-V replica. This
free feature can be used to replicated Hyper-V virtual machines to another
location.
VMware vSphere does not offer a free replication feature. To replicate virtual
machines either storage replication needs to be purchased or additional
software like Veeam Backup & Replication, VMware Site Recovery Manager,
Zerto Virtual Replication or VirtualSharp ReliableDR.
Mind Hyper-V Replica cannot be compared to VMware Site Recovery Manager
as Microsoft likes to do. While Hyper-V Replica might be a suiteable solution
for SMB, for enterprise it is probably not. Hyper-V Replica does not offer a
runbook, automated testing and other enterprise features. Hyper-V is limited
to asynchronous replication while VMware SRM support synchronous
replication executed by the storage layer.

For DR in an SMB enviroment Hyper-V is a winner. For Enterprise


environments vSphere is a winner.
Storage automation
To create new LUNs from System Center Virtual Machine Manager 2012 the
SMI-S protocol is used. This is a standard way of communicating with storage
arrays. Many vendors support SMI-S. CSV volumes can be created without
manual interaction of the storage admin.
vSphere 5 does not offer an integrated way to automatically provision new
LUNs from vCenter Server. A storage admin needs to create the LUN and
make it accessible. Then the vSphere admin can create a datastore on it.
Hyper-V is a winner in storage automation.
Management of storage array
Most vendors offering storage solutions compatible with VMware offer
integration with vCenter Server. This makes it possible to manage the
storage array from the same console as management of hosts, virtual
machines.Tasks like configuration of datastores, configuration of replication
can be done from a single vCenter console.
SCVMM 2012 does not offer management of storage. Generic tasks can be
performed from the Fabric toolbar in SCVMM 2012. For more advantaged
management the IT-admin needs to switch to the management console of
the storage vendor.
VMware is a winner in storage management integration.
Storage caching
Virtual Desktop Infrastructures (VDI) demand a lot of the storage layer.
Especially in the mornings when employees start their virtual workstations
and log on (bootstorms), lots of IOPS are requested from the storage. This
might lead to performance issues. To overcome this several solutions are
available. Use faster and dedicated to VDI storage arrays mosty based on
Flash SSD disks. Another solution is to cleverly cache part of the most
requested storage blocks into the physical memory of the hypervisor.
Windows Server 2012 Hyper-V offers a feature named CSV cache. When
enabled it delivers a performance increase of 20 x for VDI bootstorms.

vSphere currently does not have a caching feature. When VMware View
is used caching can be enabled.
More on these features
There is no clear winner here.

01.04

A WS2012 Hyper-V Converged Fabric Design With Host And Guest iSCSI Connections
Category: Hyper-V / Tag: Hyper-V, Networking, Storage, Virtualisation, Windows
Server 2012 / Add Comment

A friend recently asked me a question. He had recently deployed a Windows


Server 2012 cluster with converged fabrics. He had limited amounts of NICs
that he could install and limited number of switch ports that he could use.
His Hyper-V host cluster is using a 10 GbE connected iSCSI SAN. He also
wants to run guest clusters that are also connected to this storage. In the
past, I would have said: you need another pair of NICs on the iSCSI SAN and
use a virtual network on each to connect the virtual machines. But now we
have options!
Heres what I have come up with:

iSCSI storage typically has these two requirements:

Two NICs to connect to the SAN switches, each on a different subnet.

Each NIC is on a different subnet

In the diagram focus on the iSCSI piece. Thats the NIC team on the left.
The Physical NICs and Switches
As usual with an iSCSI SAN, there are two dedicated switches for the storage
connections. Thats a normal (not always) support requirement by SAN
manufacturers. This is why we dont have complete convergence to a single
NIC team, like you see in most examples.
The host will have 2 iSCSI NICs (10 GbE). The connected switch ports are
trunked, and both of the SAN VLANs (subnets) are available via the trunk.
The NIC Team and Virtual Switch
A NIC team is created. The team is configured with Hyper-V Port load
distribution (load balancing), meaning that a single virtual NIC cannot exceed
the bandwidth of a single physical NIC in the team. I prefer LACP (teaming
mode) teams because they are dynamic (and require minimal physical switch
configuration). This type of switch dependent mode requires switch
stacking. If thats not your configuration then you should use Switch
Independent (requires no switch configuration) instead of LACP.
The resulting team interface will appear in Network Connections (Control
Panel). Use this interface to connect a new external virtual switch that will
be dedicated to iSCSI traffic. Dont create the virtual switch until you decide
how you will implement QoS.
The Management OS (Host)
The host does not have 2 NICs dedicated to its own iSCSI needs. Instead, it
will share the bandwidth of the NIC team with guests (VMs) running on the
host. That sharing will be controlled using Quality of Service (QoS) minimum
bandwidth rules (later in the post).
The host will need two NICs of some kind, each one on a different iSCSI
subnet. To do this:
1. Create 2 management OS virtual NICs
2. Connect them to the iSCSI virtual switch

3. Bind each management OS virtual NIC to a different iSCSI SAN VLAN ID


4. Apply the appropriate IPv4/v6 configurations to the iSCSI virtual NICs in the
management OS Control Panel
5. Configure iSCSI/MPIO/DSM as usual in the management OS, using the virtual
NICs

Do not configure/use the physical iSCSI NICs! Your iSCSI traffic will source in
the management OS virtual NICs, flow through the virtual switch, then the
team, and then the physical NICs, and then back again.
The Virtual Machines
Create a pair of virtual NICs in each virtual machine that requires iSCSI
connected storage.
Note: Remember that you lose virtualisation features with this type of
storage, such as snapshots (yuk anyway!), VSS backup from the host (a very
big loss), and Hyper-V Replica. Consider using virtual storage that you can
replicate using Hyper-V Replica.
The process for the virtual NICs in the guest OS of the virtual machine will be
identical to the management OS process. Connect each iSCSI virtual NIC in
the VM to the iSCSI virtual switch (see the diagram). Configure a VLAN ID for
each virtual NIC, connecting 1 to each iSCSI VLAN (subnet) this is done in
Hyper-V Manager and is controlled by the virtualisation administrators. In
the guest OS:

Configure the IP stack of the virtual NICs, appropriate to their VLANs

Configure iSCSI/MPIO/DSM as required by the SAN manufacturer

Now you can present LUNs to the VMs.


Quality of Service (QoS)
QoS will preserve minimum amounts of bandwidth on the iSCSI NICs for
connections. Youre using a virtual switch so you will implement QoS in the
virtual switch. Guarantee a certain amount for each of the management OS
(host) virtual NICs. This has to be enough for all the storage requirements of
the host (the virtual machines running on that host). You can choose one of
two approaches for the VMs:

Create an explicit policy for each virtual NIC in each virtual machine more
engineering and maintenance required

Create a single default bucket policy on the virtual switch that applies to all
connected virtual NICs that dont have an explicit QoS policy

This virtual switch policy give the host administrator control, regardless of
what a guest OS admin does. Note that you can also apply classification and
tagging policies in the guest OS to be applied by the physical network.
Theres no point applying rules in the OS Packet Scheduler because the only
traffic on these two NICs should be iSCSI.
Note: remember to change the NIC binding order in the host management
OS and guest OSs so the iSCSI NICs are bottom of the order.
Support?
I checked with the Microsoft PMs because this configuration is nothing like
any of the presented or shared designs. This design appears to be OK with
Microsoft.
For those of you that are concerned about NIC teaming and MPIO: In this
design, MPIO has no visibility of the NIC team that resides underneath of the
virtual switch so there is not a support issue.
Please remember:

Use the latest stable drivers and firmwares

Apply any shared hotfixes (not just Automatic Updates via WSUS, etc) if they
are published

Do your own pre-production tests

Do a pilot test

Your SAN manufacturer will have the last say on support for this design

EDIT1:
If you wanted, you could use a single iSCSI virtual NIC in the management
OS and in the guest OS without MPIO. You have the path fault tolerance that
MPIO provides via NIC teaming. Cluster validation would give you a warning

(not a fail), and the SAN manufacturer might get their knickers in a twist over
the lack of dual subnets and MPIO.
And check with your SAN manufacturer for the guidance on the subnets
because not all have the same requirements.

This posting will compare high availability features of both platforms.


Protection against failed hosts
Both Hyper-V VMs (using Windows Failover Clustering) and vSphere (HA)
VMs are proteced against host failures. VMs will automated restart when a
node in a cluster unexpectedly failed.
Protection against network failures
Both vSphere and Windows Server 202 Hyper-V allow and support teaming of
network interfaces to protect against failure of a network interface. In
Windows Server 2008 the drivers of the nic vendor had to be used as
Microsoft did not support teaming.
Protection against storage failures
Both vSphere and Hyper-V can use multiple paths to the storage array. They
both support multipathing. If all paths from a Hyper-V node to the storage
array fails, an alternative route using the network LAN can be used to reach
the storage. This is called Redirected IO. vSphere does not offer such a
feature.
Monitoring of VM health
vSphere HA is able to monitor the status of the guest operating system
running in the VM. If the guest does not respond to a heartbeat signal in
time, vSphere HA will reboot the VM. Using third party solutions which needs
to be purchased the VM can also be restarted if the guest operating system
is running but critical services are stopped.
Windows Server 2012 Failover Cluster Manager allows to monitor services
inside the Windows guest operating system. This feature is named Virtual
Machine Monitoring. To configure this option see this Microsoft blog. No
additional software needed.

Protection against downtime due to host failure


VMs protected using vSphere HA/Failover Clustering will have some
downtime when the host unexpectedly fails. If a vSphere VM needs to be
available even when the host it runs on fails, a VMware feature names Fault
Tolerance can be used. When FT is enabled on a VM, a shadow VM is created
on another vSphere host. It is a copy of the primary VM and all CPU, memory
and disk actions on the primary VM will be copied and replayed on the
shadow VM (lockstep). If the host on which the primary VM fails, the shadow
VM will take over its identity without any downtime! This feature has some
restrictions in CPU and disktype usage.
Mind that a fault in the guest operating system or application will occur in
the shadow as well. Fault Tolerance will not prevent downtime of the
application when a service pack requires a reboot of the VM. A blue screen in
Windows will be copied over to the shadow. Lockstep means two instances
doing the same. If one fails, the other fails as well.
Fault Tolerance could be useful for applications which cannot be clustered or
made redundant but are that critical server downtime should be avoided.
Hyper-V does not offer such a feature.
Guest clustering support
Applications running inside a guest VM using Windows Server can be
protected against failures using Microsoft Clustering.
vSphere is much more restricted in using Microsoft Clustering than Hyper-V.
Windows Server 2012 Hyper-V does not have restrictions on guest clustering.
See the VMware knowledgbase article listing the supported scenarios.
Fibre Channel: Configuration using shared storage for Quorum and/or Data
must be on Fibre Channel (FC) based RDMs (physical mode for cluster across
boxes CAB, virtual mode for cluster in a box CIB). RDMs on storage other
than FC (such as NFS or iSCSI) are not currently supported. Virtual disk based
shared storage is supported with CIB configuration only and must be created
using the EagerZeroedThick option on VMFS datastores.
Native iSCSI (not in the guest OS): VMware does not currently support the
use of ESX host iSCSI, also known as native iSCSI (hardware or software),
initiators with MSCS.
In-guest iSCSI software initiators: VMware fully supports a configuration of
MSCS using in-guest iSCSI initiators, provided that all other configuration
meets the documented, supported MSCS configuration. Using this
configuration in VMware virtual machines is relatively similar to using it in
physical environments.

FCoE: FCoE is not supported at this time.

Lets start this series with an overview of the ability to move virtual machines
from one host to another. VMware names this feature vMotion, Microsoft
names it Live Migration.
Microsoft claims that Windows Server 2012 Hyper-V offers an unlimted
number of concurrent Live Migrations. VMware vSphere can handle a
maximum 8 concurrent vMotions on a 10 Gbps network.
vMotion/Live migration can be used for several use cases:
1. planned maintenance of a host. The host needs to be shutdown to add
extra hardware or to install service packs or other software updates on the
hypervisor which requires a reboot.
2. load balancing: when a host cannot deliver the resources a virtual
machine needs. One or more virtual machines will be moved to another host.
3. critical hardware error: when a host is likely to fail in the very near future
due to for example failure of a coolingfan and the admin wants to evacuate
the virtual machines on that host as soon as possible.
Having the possibility to have an unlimited number of concurrent Live
Migrations is only beneficial in use case number 3: a host is about the fail
and you want your VMs to be evacutated as soon as possible. In the other
cases it does not matter much if migration takes an hour or so longer.
Wait a moment: does Unlimited also mean that virtual machines are moved
faster than when a limited number of migrations is used?
NO! There is a reason why there is a limit even on 10 Gbps network
connections. Live migration/vMotion mean the content of the internal
memory of the to be moved VMs needs to be copied over to another host
and kept in sync before the actual move. This can consume quite a bit of
bandwidth depending on the internal memory usage of the VM. If an
unlimited number of VMs are concurrently migrated to another host to might
lead to congestions and much longer migration time, timeouts or even
failures.
See the opinions of other bloggers like Chris Wahl in his posting titled From
The Bad Ideas Department: Unlimited VM Migrations
Aidan Finn , which blogs exclusively about Microsoft Hyper-V did some
benchmarking to find the sweet spot of the number of concurrent Live

Migrations of Windows Server 2012 Hyper-V. In his blog he writes he found


out that 20 concurrent Live Migrations took the least amount of time to
complete using VMs with 512 MB internal memory.
So more or unlimited number of concurrent Live Migrations does not mean it
is faster than a limit on the number of concurrent migrations.
Eric Gray, a VMware employee with a personal blog, responds to the
Unlimited Live migration claim in his blog titled Hyper-V 3 Offers Unlimited
Live Migrations Kind of
Conclusion
I believe the Unlimited number of Live Migrations is a marketing term. In real
life using real workloads under the same conditions the number of
concurrent Live Migration delivering the shortest migration time for Windows
Server 2012 Hyper-V will most likely be the same as for vSpheres vMotion
feature
A Converged Networks Design For Hyper-V On SMB 3.0 Storage With RDMA (SMB
Direct)
Category: Hyper-V / Tag: Failover Clustering, HyperV, Storage, Virtualisation, Windows Server 2012 / Add Comment

When you are done reading this post, then see the update that I added for
SMB Live Migration on Windows Server 2012 R2 Hyper-V.
Unless youve been hiding under a rock for the last 18 months, you might
know that Windows Server 2012 (WS2012) Hyper-V (and IIS and SQL Server)
supports storing content (such as virtual machines) on SMB 3.0 (WS2012) file
servers (and scale-out file server active/active clusters). The performance of
this stuff goes from matching/slightly beating iSCSI on 1 GbE, to crushing
fiber channel on 10 GbE or faster.
Big pieces of this design are SMB Multichannel (think simple, configuration
free & dynamic MPIO for SMB traffic) and SMB Direct (RDMA low latency
and CPU impact with non-TCP SMB 3.0 traffic). How does one network this
design? RDMA is the driving force in the design. Ive talked to a lot of
people about this topic over the last year. They normally over think the
design, looking for solutions to problems that dont exist. In my core market,
I dont expect lots of RDMA and Infiniband NICs to appear. But I thought Id
post how I might do a network design. iWarp was in my head for this
because Im hoping I can pitch the idea for my lab at the office.

On the left we have 1 or more Hyper-V hosts. There are up to 64 nodes in a


cluster, and potentially lots of clusters connecting to a single SOFS not
necessarily 64 nodes in each!
On the right, we have between 2 and 8 file servers that make up a Scale-Out
File Server (SOFS) cluster with SAS attached (SAN or JBOD/Storage Spaces)
or Fiber Channel storage. More NICs would be required for iSCSI storage for
the SOFS, probably using physical NICs with MPIO.
There are 3 networks in the design:

The Server/VM networks. They might be flat, but in this kind of design Id
expect to see some VLANs. Hyper-V Network Virtualization might be used for
the VM Networks.

Storage Network 1. This is one isolated and non-routed subnet, primarily for
storage traffic. It will also be used for Live Migration and Cluster traffic. Its
10 GbE or faster and its already isolated so it makes sense to me to use it.

Storage Network 2. This is a second isolated and non-routed subnet. It


serves the same function as Storage Network 2.

Why 2 storage networks, ideally on 2 different switches? Two reasons:

SMB Multichannel: It requires each multichannel NIC to be on a different


subnet when connecting to a clustered file server, which includes the SOFS
role.

Reliable cluster communications: I have 2 networks for my cluster


communications traffic, servicing my cluster design need for a reliable
heartbeat.

The NICs used for the SMB/cluster traffic are NOT teamed. Teaming does not
work with RDMA. Each physical rNIC has its own IP address for the relevant
(isolated and non-routed) storage subnet. These NICs do not go through the
virtual switch so the easy per-vNIC QoS approach Ive mostly talked about is
not applicable. Note that RDMA is not TCP. This means that when an SMB
connection streams data, the OS packet scheduler cannot see it. That rules
out OS Packet Scheduler QoS rules. Instead, you will need rNICs that support
Datacenter Bridging (DCB) and your switches must also support DCB. You
basically create QoS rules on a per-protocol-basis and push them down to the
NICs to allow the hardware (which sees all traffic) to apply QoS and SLAs.
This also has a side effect of less CPU utilization.
Note: SMB traffic is restricted to the rNICs by using the constraint option.
In the host(s), the management traffic does not go through the rNICs they
are isolated and non-routed. Instead, the Management OS traffic
(monitoring, configuration, remote desktop, domain membership, etc) all
goes through the virtual switch using a virtual NIC. Virtual NIC QoS rules are
applied by the virtual switch.
In the SOFS cluster nodes, management traffic will go through a traditional
(WS2012) NIC team. You probably should apply per-protocol QoS rules on
the management OS NIC for things like remote management, RDP,
monitoring, etc. OS Packet Scheduler rules will do because youre not using
RDMA on these NICs and this is the cheapest option. Using DCB rules here
can be done but it requires end-to-end (NIC, switch, switch, etc, NIC) DCB
support to work.
What about backup traffic? I can see a number of options. Remember: with
SMB 3.0 traffic, the agent on the hosts causes VSS to create a coordinated
VSS snapshot, and the backup server retrieves backup traffic from a
permission controlled (Backup Operators) hidden share on the file server or
SOFS (yes, your backup server will need to understand this).
1. Dual/Triple Homed Backup Server: The backup server will be connected to the
server/VM networks. It will also be connected to one or both of the storage
networks, depending on how much network resilience you need for backup,
and what your backup product can do. A QoS (DCB) rule(s) will be needed for
the backup protocol(s).

2. A dedicated backup NIC (team): A single (or teamed) physical NIC (team) will
be used for backup traffic on the host and SOFS nodes. No QoS rules are
required for backup traffic because it is alone on the subnet.
3. Create a backup traffic VLAN, trunk it through to a second vNIC (bound to the
VLAN) in the hosts via the virtual switch. Apply QoS on this vNIC. In the case
of the SOFS nodes, create a new team interface and bind it to the backup
VLAN. Apply OS Packet Scheduler rules on the SOFS nodes for management
and backup protocols.

With this design you get all the connectivity, isolation, and network path fault
tolerance that you might have needed with 8 NICs plus fiber channel/SAS
HBAs, but with superior storage performance. QoS is applied using DCB to
guarantee minimum levels of service for the protocols over the rNICs.
In reality, its actually a simple design. I think people over think it, looking
for a NIC team or protocol connection process for the rNICs. None of that is
actually needed. You have 2 isolated networks, and SMB Multichannel
figures it out for itself (it makes MPIO look silly, in my opinion).
The networking chapter of Windows Server 2012 Hyper-V Installation And
Configuration Guide goes from the basics through to the advanced steps of
understanding these concepts and implementing them

Yes, You Can Run A Hyper-V Cluster On Your JBOD Storage Spaces
Category: Hyper-V / Tag: Failover Clustering, HyperV, Storage, Virtualisation, Windows Server 2012, Windows Server 2012 R2 / Add
Comment

What is the requirement of a cluster? Shared storage. Whats supported in


WS2012/R2?

SAS SAN

iSCSI SAN

Fiber Channel SAN

FCoE

PCI RAID (like Dell VRTX)

Storage Spaces

Whats the difference between a cluster and a Hyper-V cluster? Youve


enabled Hyper-V on the nodes. Here are 2 nodes, each connected to a
JBOD. Storage Spaces is configured on the JBOD to create cluster shared
volumes. All that remains now is to enable Hyper-V on node 1 and node 2,
and now you have a valid Hyper-V cluster that stores VMs on the CSVs

Its completely supported, and a perfect Hyper-V cluster solution for the
small/medium business, with the JBOD costing a fraction (search engine here
and here) of the equivalent capacity SAN.
Stupid questions that you should not ask:

What file shares do I use to store my VMs on? Where do you see file shares
in the above text? You store the VMs directly on the CSVs like in a Hyper-V
cluster with a SAN, instead of storing file shares on the CSVs like in a SOFS
cluster.

Can I run other roles on the hosts? No. You never should do that and I
include Exchange Server and SQL Server for the 2 people that I now hope
have resigned from working in IT who asked that recently.

The required networks if you use 10 GbE are shown above. Go look at
converged networks for all possible designs; its the same clustered 2012/R2
Hyper-V networking as always.

Configuring Quorum on Storage Spaces For A 2 Node WS2012 (and WS2012 R2)
Cluster
Category: Hyper-V / Tag: Failover Clustering, HyperV, Storage, Virtualisation, Windows Server 2012, Windows Server 2012 R2 / Add
Comment

In this post Im going to talk about building a 2 node Windows Server


2012/R2 failover cluster and what type of witness configuration to choose to
achieve cluster quorum when the clusters storage is a JBOD with Storage
Spaces.
Ive been messing about in the lab with a WS2012 R2 cluster, in particular, a
Scale-Out File Server (SOFS) running on a failover cluster with Storage
Spaces on a JBOD. What Im discussing applies equally to:

A Hyper-V cluster that uses a SAS attached JBOD with Storage Spaces as the
cluster storage

A SOFS based on a JBOD with Storage Spaces

Consider the build process of this 2 node cluster:

You attach a JBOD with raw disks to each cluster member

You build the cluster

You prepare Storage Spaces in the cluster and create your virtual disks

Hmm, no witness was created to break the vote and get an uneven result. In
fact, what happens is that the cluster will rig the vote to ensure that there is
an uneven result. If youve got 2 just nodes in the cluster with no witness
then one has a quorum vote and the other doesnt. Imagine Node1 has a
vote and Node2 does not have a vote. Now Node1 goes offline for whatever
reason. Node2 does not have a vote and cannot achieve quorum; you dont
have a cluster until Node1 comes back online.
There are 2 simple solutions to this:

1) Create A File Share Witness

Create a file share on another highly available file server uh thatll be an


issue for small/medium business because all the virtual machines (including
the file server) were going to be stored on the JBOD/Storage Spaces. You can
configure the file share as a witness for the cluster.
2) (More realistically) Create a Storage Spaces Virtual Disk As A Witness Disk

Create a small virtual disk (2-way or 3-way mirror for JBOD fault tolerance)
and use that disk for quorum as the witness disk. A 1 GB disk will do; the
smallest my Storage Spaces implementation would do was 5 GB but thats
such a small amount anyway. This solution is pretty what youd do in a
single site cluster with traditional block storage.
We could go crazy talking about quorum options in cluster engineering. Ive
given you 2 simple options, with the virtual disk as a witness being the
simplest. Now each node has a vote for quorum with a witness to break the
vote, and the cluster can survive either node failing.

Lets start this series with an overview of the ability to move virtual machines
from one host to another. VMware names this feature vMotion, Microsoft
names it Live Migration.
Microsoft claims that Windows Server 2012 Hyper-V offers an unlimted
number of concurrent Live Migrations. VMware vSphere can handle a
maximum 8 concurrent vMotions on a 10 Gbps network.
vMotion/Live migration can be used for several use cases:
1. planned maintenance of a host. The host needs to be shutdown to add
extra hardware or to install service packs or other software updates on the
hypervisor which requires a reboot.
2. load balancing: when a host cannot deliver the resources a virtual
machine needs. One or more virtual machines will be moved to another host.
3. critical hardware error: when a host is likely to fail in the very near future
due to for example failure of a coolingfan and the admin wants to evacuate
the virtual machines on that host as soon as possible.
Having the possibility to have an unlimited number of concurrent Live
Migrations is only beneficial in use case number 3: a host is about the fail
and you want your VMs to be evacutated as soon as possible. In the other
cases it does not matter much if migration takes an hour or so longer.

Wait a moment: does Unlimited also mean that virtual machines are moved
faster than when a limited number of migrations is used?
NO! There is a reason why there is a limit even on 10 Gbps network
connections. Live migration/vMotion mean the content of the internal
memory of the to be moved VMs needs to be copied over to another host
and kept in sync before the actual move. This can consume quite a bit of
bandwidth depending on the internal memory usage of the VM. If an
unlimited number of VMs are concurrently migrated to another host to might
lead to congestions and much longer migration time, timeouts or even
failures.
See the opinions of other bloggers like Chris Wahl in his posting titled From
The Bad Ideas Department: Unlimited VM Migrations
Aidan Finn , which blogs exclusively about Microsoft Hyper-V did some
benchmarking to find the sweet spot of the number of concurrent Live
Migrations of Windows Server 2012 Hyper-V. In his blog he writes he found
out that 20 concurrent Live Migrations took the least amount of time to
complete using VMs with 512 MB internal memory.
So more or unlimited number of concurrent Live Migrations does not mean it
is faster than a limit on the number of concurrent migrations.
Eric Gray, a VMware employee with a personal blog, responds to the
Unlimited Live migration claim in his blog titled Hyper-V 3 Offers Unlimited
Live Migrations Kind of
Conclusion
I believe the Unlimited number of Live Migrations is a marketing term. In real
life using real workloads under the same conditions the number of
concurrent Live Migration delivering the shortest migration time for Windows
Server 2012 Hyper-V will most likely be the same as for vSpheres vMotion
feature.