Working with Virtual Server
I first configured a couple of VMs on one of
the server’s local disks and made sure they
were completely configured and operational
before adding the SAN volumes to the
server. Then, I migrated the existing VMs
to the new SAN volume, using the method
that follows.
First, to make the job of moving any VM
easier, I recommend performing a clean
shutdown of the VM. You can use the Virtual
Server Administration Web site, which Figure
2 shows, to perform clean shutdowns of the
systems you want to move. Now, assuming
you’re moving all your VMs to another volume,
you’ll want to change the MYVIRTUALSYSTEMS
environment variable to the new
path where your VM files will reside. (See the
Microsoft article “The My Virtual Machines
folder and virtual machine performance
issues” in the Learning Path for further information.)
VMs are essentially made up of two
files—a VHD file (the virtual hard disk) and
a VMC file (an XML description of the VM’s
configuration parameters). If you configure
multiple drives within your VM, or if you’re
using undo disks or differencing disks, more
than one VHD file will exist.
When you’re moving VMs from one
location to another on the same host, and
you want to keep the VMC and VHD file
together, it’s easiest to remove the VM from
Virtual Server Manager, then re-add it by entering the path to the location to which
you copied the VHD and VMC files. This
applies when the drive letter, folder name
or filename, or another element of the path
changes. After you add the system, you need
to configure the new path to the VHD files by
choosing the Configure option and selecting
your newly moved system. In the configuration
window, select the Hard disks item and
modify the Fully qualified path to file value
to reflect your new VHD location. You might
also want to add or remove search paths as
appropriate from the Virtual Server Manager’s
Server Properties menu.
Now that you’ve moved your VM’s VHD
and VMC files to a volume located on a SAN,
you can use a similar process to move VMs
to another host, without needing to copy the
data. For example, suppose you’re replacing
an old server that hosts a number of VMs.
You can provision the new hardware, install
the necessary software (including Virtual
Server), and prepare it to connect to the
iSCSI SAN. When the new server is ready
to go into production, cleanly shut down
the VMs, dismount the SAN volume from
the old server, and mount it on the new
server as discuss in the “Configuring SAN
Volumes for Windows Virtual Server” sidebar.
With proper planning and preparation,
your VMs shouldn’t be offline for more than
10 or 15 minutes. You can use similar techniques
for disaster recoverability, but more
comprehensive approaches are available
through third-party backup vendors.
Also, Windows Server 2008’s new Hyper-V
technology promises advanced, centralized
VM management capabilities.
Working with ESX Server
As I did with Windows Server, I started
by configuring a couple of VMs on a
local disk on the ESX Server system.
I performed these steps through the
VMware Infrastructure Client, which Figure 3 shows. After configuring some
SAN targets and formatting them with
Virtual Machine File System (VMFS,
as I discuss in the “Configuring SAN
Volumes for VMware ESX Server” Webexclusive
sidebar), I manually moved
a VM to the new volumes by using the
manual method proposed by VMware
in its Knowledge Base article “Manual
Migration Procedure for Moving a Virtual Machine on ESX Server” (see the Learning
Path).
I found a utility called FastSCP from
Veeam Software that simplifies this manual
process with a GUI interface. Like
the Windows virtualization scenario,
the VMware process of getting the virtual
files onto a SAN volume gives you
more portable and flexible management
and recoverability, but to gain the best
leverage of an iSCSI SAN in a VMware
environment, you need to purchase
VMware’s VMotion add-on. VMotion lets
you migrate an entire VM to a new host
without needing to move the associated
virtual disk files from their location on
shared storage. VMotion automates this
entire process and can perform it on hot
or cold VMs. Whether or not you’re able
to take advantage of VMware’s advanced
add-on functionality, just getting your
VMs onto SAN-based storage will give you
the level of data protection afforded by the
SAN hardware and features that your SAN
vendor offers.
SAN Data Protection
In addition to the shared-storage and portability
advantages that a SAN brings to virtualized
environments, the advanced availability
and data-protection features that most vendors
offer can yield numerous benefits. Vendors
take varying approaches to licensing
features on their platforms. Some offer a la
carte options that you can pay for as you need
them, whereas others, such as Dell, sell their
products with every feature enabled.
You can use snapshot technology, which
quickly creates a copy of a volume’s contents
at a specific point in time, for instant
or scheduled backups. Because snapshot
operations happen quickly and because
snapshots can be mounted as separate
volumes, they can be useful in testing and
migration operations. Some platforms also
feature integration with Microsoft’s Volume
Shadow Copy Service (VSS) framework,
which enables snapshot backups that ultimately
offload the backup process from
application servers.
Replication is another technology that
offers simplified data protection in a SAN
environment. You can use replication to
create point-in-time copies of one SAN array
or group and move them to another array or group in a physically separate location.
Because iSCSI runs on Ethernet, the distance
between these replica partners can be virtually
unlimited, offering a strong measure of
protection against natural disasters or other
catastrophes. Depending on the situation,
you can make either replica partner the primary
storage entity and you can synchronize
any changes once both sites are back online.
Some vendors have highly customized variations
of this technology that perform realtime
striping of data across physical units in
geographically separate locations.
Finally, MPIO—which lets a server use
more than one read/write path to an iSCSI
storage device—is a technology that provides
fault tolerance against single points
of failure in switch or NIC hardware or
cabling. Multipathing can also provide loadbalancing
of SAN traffic, resulting in performance
improvements in high-utilization
iSCSI implementations.
More iSCSI SAN/Virtualization Benefits
SANs and virtual environments complement
each other in quite a few ways; in fact,
I won’t be able to do them justice in one
article. However, two notable capabilities to
consider are booting from SAN and iSCSI
VM clustering.
Booting from SAN. Booting servers
directly from a SAN is an alternative to provisioning
physical servers that have a local
disk with an OS installed, offering numerous benefits related to reliability, disaster recoverability,
simplified backup, and manageability.
Booting from an iSCSI SAN is most
easily accomplished with a dedicated HBA,
but you can find solutions to configure boot
from SAN for standard NICs.
Clustering. Virtual Server guest clustering
is a technology in which VM nodes
communicate with their shared storage via
iSCSI to accommodate failover from one
VM to another. This relatively low-cost clustering
scenario provides high-availability
implementations for VMs and offers a better
means for applying patches and conducting
other hardware or software maintenance.
One-Two Punch for the Future
Of course, not every SMB IT organization
has the budget to deploy a new iSCSI SAN
and virtualization infrastructure. The key
is to recognize the potential of each technology
and the advantages of having both.
Then, plan your roadmap to get the most
out of incremental investments in these
technologies—with an eye toward the ultimate
goal of full-scale deployment of both.