1. Planning virtual machine deployment
Depending on the scenario being envisioned, deploying a virtual
machine can mean different things, for example:
-
Creating a new virtual machine, and installing a guest
operating system and applications on it. -
Importing an existing virtual machine that already has a
guest operating system and applications installed on it. -
Performing a physical-to-virtual (P2V) conversion of a
physical server to migrate the server’s operating system and
applications into a virtual machine. -
Performing a virtual-to-virtual (V2V) conversion by
converting a VMware virtual machine to a Hyper-V virtual
machine.
The first two types of virtual-machine deployments can be
performed using the in-box management tools of the Hyper-V role of
Windows Server 2012—specifically, the Hyper-V Manager and the Hyper-V
module for Windows PowerShell. Deploying new virtual machines by
performing P2V or V2V conversions requires additional tools, such as
System Center Virtual Machine Manager or third-party utilities.
The following issues should be considered when creating new
virtual machines on a Hyper-V host:
Note that these issues apply mainly to the creation of new
virtual machines. Importing existing virtual machines entails a
different set of conditions that are described separately later in
this section.
Location of configuration files
Although the default location where virtual machine
configuration files is configured at the host level, you also have
the option of overriding this default when you create a new virtual
machine. You might do this, for example, if you are creating a
virtual machine for high availability—that is, a clustered virtual
machine on a failover cluster of Hyper-V hosts that uses CSV shared
storage. In such a scenario, you need to specify the CSV under the
ClusterStorage folder in Failover Cluster Manager as the location
where the virtual machine will be stored. Another scenario where you
might override the default configuration file storage location is
when you are creating a virtual machine that will be stored on a SMB
3.0 file share on a Scale-Out File Server. In this case, you would
specify the client access point that is configured in the failover
cluster for the Scale-Out File Server as the location where the
virtual machine will be stored.
The memory that each new virtual machine will need is an
important consideration when planning the creation of new virtual
machines. Physical host systems have a fixed amount of physical
memory, and this memory must be shared in an appropriate way between
the different virtual machines that run on the host. (The host
itself also requires some physical memory in order to function with
optimum performance.) Planning the amount of physical memory to be
allocated to a new virtual machine you will create involves two
considerations:
-
Deciding upon the amount of startup memory to be assigned
to the virtual machine. The guest operating installed in a
virtual machine must have access to sufficient memory;
otherwise, the virtual machine might not be able to start. The
recommended startup memory varies with the guest operating
system involved and also on whether Dynamic Memory is enabled on
the host. Some recommended values for startup memory
include -
Deciding whether to enable Dynamic Memory on the virtual
machine. Dynamic Memory manages physical memory on the host as a
shared resource that can be automatically reallocated among
running virtual machines based on changes in memory demand and
values you can specify.
Some workloads can require additional processor resources in
order to perform optimally. Hyper-V allows you to assign one or more
virtual processors to each virtual machine running on the host, up
to the maximum number of logical processors supported by the guest
operating system installed in the virtual machine. You can also use
Hyper-V to keep a reserve of the processor resources available to a
virtual machine, specify a limit to the amount of processor
resources the virtual machine can use, and configure how Hyper-V
allocates processor resources when multiple running virtual machines
on a host compete for the host’s processor resources.
Virtual networking involves creating virtual network adapters
in virtual machines and assigning these adapters to virtual switches
on the host. The following considerations apply when planning
virtual networking for virtual machines:
-
Each virtual machine can have up to 12 virtual network
adapters installed in it. Of these 12 virtual network adapters,
up to 8 can be the network adapter type and
up to the 4 can be the legacy network
adapter type. These two types of virtual network
adapters are discussed in more detail later in this
lesson. -
Each virtual network adapter can be configured with either
a static MAC address or a dynamic MAC address that is
automatically assigned from the configured MAC address range on
the host. -
Each virtual network can be assigned a unique VLAN channel
to segment or isolate network traffic. -
Up to 512 virtual machines can be assigned to each virtual
switch on the host.
Note
Hyper-V and wireless networking
Virtual switches on a Hyper-V host cannot be connected to a
wireless network adapter on the host system.
When you create a new virtual machine, you have three options
concerning the virtual hard disks associated with the new virtual
machines:
-
You can create a new virtual hard disk when you create the
new virtual machine. -
You can assign an existing virtual hard disk to the new
virtual machine you are creating. -
You can create a new virtual machine with no virtual hard
disk and then assign a virtual hard disk to it
afterwards.
Another planning consideration concerning virtual hard disks
is the type of storage controller used for the disk. Virtual
machines include both IDE and SCSI controllers, and you can add
virtual hard disks to either type of controller.
Another planning consideration is the type of virtual disk to
use—namely, one of the following types:
-
Fixed-size This type of
virtual hard disk has its image file pre-allocated on the
physical storage device for the maximum size requested when the
disk is created. For example, a 250-GB, fixed-size virtual hard
disk will occupy 250 GBs of space on the host’s storage
device. -
Dynamically expanding This
type of virtual hard disk uses only as much physical storage
space as it needs to store the actual data that the disk
currently contains. The size of the virtual disk’s image file
then grows as additional data is written to it. For example, the
image file for a dynamic virtual hard disk of a newly created
virtual machine that has no operating system installed on it has
a size of only 4 MBs even though its maximum size is configured
with the default value of 127 GBs. Once Windows Server 2012 has
been installed as the guest operating system, however, the size
of the virtual disk’s image file will grow to more than 8 GBs.
-
Differencing This type of
virtual hard disk allows you to make changes to a parent virtual
hard disk without modifying the parent disk. For example, the
parent disk could have a clean install of Windows Server 2012 as
its guest operating system while the differencing disk contains
changes to the parent. The changes can then be reverted if
needed by merging the differencing disk with the parent. Hyper-V
snapshots use such differencing disk technology.
Note
Pass-through
disks
Another type of disk that a Hyper-V virtual machine can use
is the pass-through disk, which is not really a virtual disk at
all. Instead, with pass-through disks the virtual machine is
directly attached to a physical disk on the host’s storage system,
and the physical disk on the host is dedicated to for use by the
virtual machine alone. With the performance improvements that have
been made to both fixed-size and dynamically expanding virtual
hard disks in recent versions of Hyper-V, and given the added
flexibility that virtual hard disks can provide, pass-through
disks no longer offer any performance benefits beyond those
provided by virtual hard disks and should not be used
anymore.
Some additional planning considerations relating to virtual
hard disks include
-
Whether to use virtual hard disks that use the VHD disk
format used by previous versions of Hyper-V or the newer VHDX
format introduced in Windows Server 2012. Although the older VHD
format supported virtual hard disks up to 2040 GBs in size, the
newer VHDX format now supports virtual hard disks up to 64 TBs
in size. VHDX also includes other enhancements, such as improved
alignment to make the format work well on large-format disks,
larger block sizes for dynamic and differencing disks, support
for trim, support for 4-KB logical sector virtual disks,
improved safeguards against data corruption when power
interruptions occur, and other features.
-
If the storage capacity provided by a single virtual hard
disk is not sufficient for the needs of the virtual machine’s
workload, additional virtual disks can be created and attached
to the virtual machine using the IDE controller, SCSI
controller, or both controllers. -
The maximum supported storage for a single virtual machine
is 512 TBs for all types. -
If your Hyper-V hosts are using a SAN for their storage,
you can improve storage performance by taking advantage of the
new Offloaded Data Transfer (ODX) functionality included in
Windows Server 2012. ODX can help minimize latency, maximize
array throughput, and reduce processing and network resource
usage on Hyper-V hosts by transparently offloading file-transfer
operations from the host to the SAN. -
If your virtual machines need to be able to access storage
on a Fibre Channel SAN, they can take advantage of the new
virtual Fibre Channel feature of Windows Server 2012 Hyper-V.
This feature provides Fibre Channel ports within the guest
operating system so that you can directly connect virtual
machines to SAN storage. The benefits of virtual Fibre Channel
include being able to virtualize workloads that require direct
SAN connectivity and being able to cluster guest operating
systems over Fibre Channel. Implementing virtual Fibre Channel
requires that the host bus adapter (HBA) on the host have an
updated driver that supports virtual Fibre Channel and that the
HBA ports be configured with a Fibre Channel topology that
supports N_Port ID Virtualization (NPIV).
Guest operating system deployment
Guest operating systems can be installed in virtual machines
the same way they are installed on physical systems. For example,
you could do the following:
-
Manually install the guest operating system by attaching
an ISO image of the product media to the virtual machine’s
virtual DVD drive, and then walk through the steps of the
installation process. -
Perform a Lite Touch Installation (LTI) deployment of the
guest operating system by booting the virtual machine from a
server that has the Windows Deployment Services role installed
and then stepping through (or automating) the Windows Deployment
Wizard of Microsoft Deployment Toolkit (MDT) 2012 Update 1.
-
Perform a Zero Touch Installation (ZTI) deployment of the
guest operating system by using System Center 2012 Configuration
Manager SP1 to deploy a reference image created using MDT 2012
Update 1.
Although snapshots are not recommended for use in production
environments, they might have value in certain limited scenarios.
For example, you might consider performing a snapshot of a
production virtual machine just before you apply a critical software
update to the guest operating system of the virtual machine. That
way, if something goes wrong after applying the update, you can
quickly revert to the virtual machine to its previous state (that
is, before the update was applied). However, there are certain
scenarios where you should never perform snapshots,
specifically:
-
Don’t perform snapshots on virtualized domain
controllers. -
Don’t perform snapshots on virtualized workloads that run
time-sensitive services. -
Don’t perform snapshots on virtualized workloads that use
data distributed across multiple databases.
Also, don’t try to restore snapshots older than 30 days
because the computer password for the guest operating system might
have expired, which will cause the guest to
dis-join itself from the domain.
Finally, if you do plan on performing snapshots, make sure the
host has sufficient storage for all the snapshot files you might
create. Snapshots can consume a lot of disk space, and you could end
up running out of storage space if you perform too many of
them.
Considerations for importing virtual machines
Although the process of importing an existing virtual machine
onto a Hyper-V host has been simplified in Windows Server 2012,
there are still a number of issues that should be considered before
you perform the import. The following improvements have been made to
the virtual machine import process in Windows Server 2012:
-
The import process has been updated so that configuration
problems that might prevent the import from being successful are
detected and resolved. For example, if you are importing the
virtual machine onto a target host that has a different set of
virtual switches than those on the source host, the Import
Virtual Machine Wizard, which can be launched from Hyper-V
Manager, now prompts you to choose a virtual switch to connect
to the virtual network adapter on the virtual machine. -
Virtual machines can now be directly imported from the
virtual machine’s configuration file without first exporting the
virtual machine. This can be done by manually copying the
virtual machine files instead of exporting them. In fact, when
you export a virtual machine in Windows Server 2012, now all
that happens is that a copy of the virtual machine’s files is
created. -
Hyper-V now includes Windows PowerShell cmdlets that can
be used to export and import virtual machines.
The following issues might be important to consider when
planning the import of virtual machines onto your hosts:
-
When you import a virtual machine, you have the choice of
either of the following approaches:
-
Registering the virtual machine in-place, and
assigning the GUID of the existing virtual machine to the
new virtual machine (the default). You can choose this
option if the virtual machine’s files are already in the
location where they need to be in order to run on the target
host, and you just want to begin running the virtual machine
from where it is located. -
Restoring the virtual machine, and assigning the GUID
of the existing virtual machine to the new virtual machine.
You can use this option if the virtual machine’s files are
stored on a file share or removable storage device and you
want to move them to the default storage location on the
target host. -
Copying the virtual machine, and generating a new GUID
for the new virtual machine. You can use this option if you
want to use the existing virtual machine as a template that
you will be importing multiple times to create new virtual
machines—for example, for test or development work.
-
If you are migrating the virtual machines from a host
running an earlier version of Windows Server 2012, you can use
the Compare-VM cmdlet to generate a compatibility report that
lists any incompatibilities that the virtual machine might have
with the target host. You can then use this report to take steps
to resolve such issues so that when you use the Import-VM cmdlet
later, the import process will go smoothly. -
If you are importing virtual machines from a nonclustered
host to a clustered host, there might be additional
considerations, such as whether you need to import the virtual
machines to the shared storage used by the failover
cluster.
|
