In this article, you will learn how to design an
operating system virtualization strategy. This includes learning how to
assess which existing server deployments make good candidates for
virtualization, learning how to plan the migration of servers from
traditional hardware-based installations to virtual hosts, and learning
the most effective locations in an existing network infrastructure to
deploy servers that host virtual machines (VMs). This lesson not only
explains Hyper-V but also examines Virtual Server 2005 R2 and System
Center Virtual Machine Manager 2007. To effectively design an operating
system virtualization strategy, you need to understand how these
separate components can be integrated to meet your organization’s needs.
Every year the hardware
that vendors make available becomes more powerful. Increasingly
powerful hardware changes the way that enterprise administrators plan
the deployment of server resources. Whereas, in the past, server
utilization patterns and performance meant that only a single server
role or application could be deployed on computer hardware, today’s
server hardware can cope with a much higher workload. This means that
fewer servers are required to do the same amount of work. Virtualization
allows you to fully utilize the increased computing power made
available by modern hardware without worrying about the conflicts that
might occur if you cohosted important applications and server roles on a
single instance of Windows Server 2008. Virtualization provides the
following benefits over traditional installations:
More efficient use of hardware resources
Services such as Dynamic Host Configuration Protocol (DHCP) and Domain
Name System (DNS), although vital to network infrastructure, are
unlikely to push the limits of your server’s processor and RAM. Although
it is possible to co-locate the DNS and DHCP roles on the one Windows
Server 2008 computer, the strategy of separating network roles onto
separate partitions allows you to relocate those partitions to other
host computers if the circumstances and usage of those roles change.
Improved availability
Consolidating these services onto a single hardware platform can reduce
costs and maintenance expenses. Although moving from many platforms to
one might look like it would lead to a single point of failure,
implementing redundancy technologies (clustering and hot-swappable
hardware such as processors, RAM, power supplies, and
hard disk drives) provides a greater level of reliability for lower
cost. Consider the following situation: four Windows Server 2008
computers are each running a separate application provided to users on
your network. If a hardware component fails on one of those servers, the
application that the server provides to users of the network is
unavailable until the component is replaced. Building one server with
redundant components is cheaper than building four servers with
redundant components. If a component fails, the built-in redundancy
allows all server roles to remain available.
Servers need to be only intermittently available
Some servers need to be available only intermittently. For example, the
best practice with a root CA is to use subordinate CAs to issue
certificates and to keep the root CA offline. With virtualization, you
could keep the entire virtualized root CA server on a removable USB hard
disk drive in a safe, only turning it on when necessary and thereby
ensuring the security of your certificate infrastructure. Virtualization
frees up existing hardware that is rarely used—or makes it unnecessary
to buy it.
Role sandboxing
Sandboxing is a term used to describe the partitioning of server
resources so that an application or service does not influence other
components on the server. Without sandboxing, a failing server
application or role has the capacity to bring down an entire server.
Just as Web application pools in Internet Information Services (IIS)
sandbox Web applications so that the failure of one application will not
bring all of them down, running server applications and roles in their
own separate virtualized environment ensures that one errant process
does not bring down everything else.
Greater capacity
Adding significant hardware capacity to a single server is cheaper than
adding incremental hardware upgrades to many servers. You can increase
capacity by adding processors and RAM to the host server and then
allocating those resources to a virtual server as the need arises.
Greater portability
After a server has been virtualized, moving it to another host if the
original host’s resources become overwhelmed is relatively simple. For
example, suppose that the disks on a Windows Server 2008 Enterprise
computer hosting 10 virtualized servers are reaching their input/output
(I/O) capacity. Moving some of the virtualized servers to another host
is simpler than migrating or upgrading a server. Tools such as System
Center Virtual Machine Manager, make the
process even simpler.
Easier backup and restore
Tools such as volume shadow copy allow you to back up an entire
server’s image while the server is still operational. If a host computer
fails, the images can be rapidly restored on another host computer.
Rather than backing up individual files and folders, you can back up the
entire virtualized computer in one operation. System Center Virtual
Machine Manager (SCVMM) 2007 allows you to move VMs back and forth to
the Storage Area Network (SAN) and even migrate VMs between host
computers. SCVMM 2007 is covered in more detail later in the lesson.
Virtual Server 2005 R2
Virtual
Server 2005 R2 SP1 is a product that you can download and install for
free from Microsoft’s Web site. Virtual Server 2005 R2 SP1 allows you to
host and manage VM instances on a 32-bit version of Windows Server
2008. You can also install Virtual Server 2005 R2 SP1 on the 32-bit and
64-bit versions of Windows Server 2003 SP1/R2. It is also possible to
install Virtual Server 2005 R2 SP1 on Windows Small Business Server 2003
and Windows XP Professional, though you should never use Windows XP
Professional as a virtual host for virtualized servers that are used in a
production environment. Virtual Server 2005 R2 SP1 cannot be installed
on a Windows Server 2008 computer that has been installed using the
Server Core option.
When planning an
operating system virtualization strategy, you should consider Virtual
Server 2005 R2 SP1 when the computer that you plan to use as a virtual
host has a 32-bit, as opposed to a 64-bit, processor. This is because
Hyper-V, which is covered later in this lesson, is a Windows Server 2008
feature that is available only on 64-bit versions of Windows Server
2008. For example, say that your organization has a computer with
Windows Server 2003 Enterprise installed. The computer has eight
processors and 64 GB of RAM, but the processors on the computer are
32-bit rather than 64-bit. Computers with large amounts of RAM make
excellent VM hosts, but because the processors on the computer have a
32-bit rather than a 64-bit architecture, it is impossible to install
the 64-bit version of Windows Server 2008 on this computer and
impossible to use Hyper-V as a VM host. From the planning perspective,
you can still install Windows Server 2008 on this computer and use it as
a VM host; it is just that the host platform will be Virtual Server
2005 R2 SP1 rather than Hyper-V.
Alternatively,
you could have a similarly powerful computer that has the 64-bit version
of Windows Server 2003 R2 installed. Your organization might not be
ready to upgrade the operating system of this computer to Windows Server
2008, but you might want to use the computer as a VM host. Because
Hyper-V can be deployed only on Windows Server 2008 x64, you will need
to include Virtual Server 2005 R2 SP1 in your operating system
virtualization plans until you can upgrade the computer operating system
to Windows Server 2008 x64.
Although you can use Virtual
Server 2005 R2 SP1 as a key component in an operating system
virtualization strategy, you must remember the following limitations
when planning virtual host deployment:
Virtual
Server 2005 R2 SP1 cannot host x64 bit VMs—even if the platform that
Virtual Server 2005 R2 SP1 is installed on is a 64-bit operating system.
Virtual Server 2005 R2 SP1 does not support symmetric multiprocessing (SMP) in the VM environment.
Virtual Server 2005 R2 SP1 supports a maximum of four virtual network adapters.
Virtual Server 2005 R2 SP1 supports a maximum of 64 concurrent VMs.
Hyper-V
Hyper-V is a Windows
Server 2008 feature that allows you to run virtualized computers under
x64 versions of Windows Server 2008. Hyper-V is a hypervisor-based
technology. A hypervisor is a software layer between the hardware and
the operating system that allows multiple operating systems to run on a
host computer at the same time. Hyper-V has many similarities to Virtual
Server 2005 R2 in terms of functionality, although, unlike Virtual
Server 2005 R2, Hyper-V is built directly into the operating system as a
role and does not sit above the operating system as an application.
Apart from being a feature included with the operating system, Hyper-V
has the following differences from Virtual Server 2005 R2 SP1:
Hyper-V allows you to run 64-bit VM guests. Hyper-V can concurrently host 32-bit and 64-bit VM guests.
Hyper-V supports SMP in the VM environment.
Hyper-V can host as many concurrent VMs as the hardware supports.
Hyper-V
can be configured as a part of a failover cluster, so that a VM fails
over across the network to a server running Hyper-V in a recovery site.
Hyper-V
can be used on a Windows Server 2008 computer installed using the
Server Core option. You can manage Hyper-V on a Server Core computer
using the WMI interface or a remote session using the Hyper-V manager
console.
Hyper-V guests can have a maximum of four virtual SCSI controllers per VM.
Hyper-V guests can have a maximum of eight virtual network adapters per VM.
The
Enterprise and Datacenter editions of Windows Server 2008 include
licenses to run virtualized instances of the operating system using
Hyper-V.
Creating Virtual Machines
Creating a VM on a
Hyper-V host is relatively simple and involves running the New Virtual
Machine Wizard from the Virtualization Management console. To create the
virtual machine, perform the following steps:
1. | Specify
a name and location for the VM. Placing a VM on a RAID-5 volume—or,
even better, a RAID 0+1 or RAID 1+0 volume—ensures redundancy. You
should avoid placing VMs on the same volume as the host operating
system. The name of the VM does not need to be simply the computer’s
name but can include other information about the VM’s functionality.
|
2. | Specify
memory allocation. The maximum amount of memory depends on the amount
of RAM installed on the host computer. Remember that each active VM must
be allocated RAM and that the total amount of allocated RAM for all
active VMs and the host operating system cannot exceed the amount
installed on the host computer.
|
3. | Specify
networking settings. Specify which of the network cards installed on
the host will be used by the VM. Where you expect high network
throughput, you might add an extra network card and allocate it solely
to a hosted VM.
|
4. | Specify
a virtual hard disk. VMs use flat files to store hard disk data.
Hyper-V mounts these files, and they appear to the VM as a normal hard
disk drive that can even be formatted and partitioned. When creating a
virtual hard disk, you should specify enough space for the operating
system to grow, but do not allocate all available space if you intend to
add other VMs later.
|
5. | Specify
operating system installation settings. In the final stage of setting
up a VM, you specify how you will install the operating system: from an
image file, such as an .ISO file; from optical media, such as a DVD-ROM;
or from a network-based installation server, such as Windows Deployment
Services (WDS).
|
From this point you can turn on the VM and then begin the installation process using the method that you selected in step 5.
Managing Virtualized Servers
You manage Hyper-V through the Hyper-V Manager console, shown in Figure 1.
You can use this console to manage virtual networks, edit and inspect
disks, take snapshots, revert to snapshots, and delete snapshots, as
well as to edit the settings for individual VMs. You can also mount
virtual hard disks as volumes on the host server should the need arise.
Snapshots
Snapshots
are similar to a point-in-time backup of a virtualized machine. The
great benefit of snapshots is that they allow you to roll back to an
earlier instance of an operating system far more quickly than any other
technology would. For example, assume that your organization hosts its
intranet Web server as a VM under Hyper-V. A snapshot of the intranet
Web server is taken every day. Because of an unforeseen problem with the
custom content management system, the most recent set of updates to the
intranet site have wiped the server completely. In the past, as an
administrator, you would have to go to your backup tapes and restore the
files. With Hyper-V, you can just roll back to the previous snapshot
and everything will be in the state it was when the snapshot was taken.
Licensing
All operating
systems that run in a virtualized environment need to be licensed.
Products such as Windows Server 2008 Enterprise and Windows Server 2008
Datacenter allow a certain number of virtual instances to be run without
incurring extra license costs because the licenses for these editions
include the virtualized component. The applications that run on the
virtualized servers also need licenses. As with all licensing queries,
in more complicated situations you should check with your Microsoft
representative if you are unsure whether you are in compliance.
Modifying Hardware Settings
You can edit VM
settings. This allows you to add resources like virtual hard disks and
more RAM and to configure other settings, such as the Snapshot File
Location. Figure 2
shows the Integration Services for a specific VM. Integration Services
allow information and data to be directly exchanged between host and VM.
To function, these services must be installed on the guest operating
system. This task is performed after the guest operating system is set
up. You can edit some settings, such as the optical drive settings,
while the VM is running. Other settings, such as assigning and removing
processors from a VM, require you to turn off the VM.
Not only can you assign
processors to VMs, but you can also limit the amount of processor usage
by a particular VM. You do this with the Virtual Processor settings
shown in Figure 3.
This way you can stop one VM that has relatively high processing needs
from monopolizing the host server’s hardware. You can also use the
Virtual Processor settings to assign a relative weight to a hosted VM.
Rather than specifying a percentage of system resources to which the VM
is entitled, you can use ratios to weight VM access to system resources.
The benefit of using relative weight is that you do not have to
recalculate percentages each time you add or remove VMs from a host. You
simply add the new host, assign a relative weight, and let Hyper-V work
out the specific percentage of system resources that the VM is entitled
to.
