In this chapter I’ll bring together many of the visualization techniques
presented thus far and use them to analyze more complex and difficult-topredict
activity.
INTRODUCTION
Understanding the interaction between XenVMs and Xen Hosts requires that
administrators understand their workloads. Once they understand their workloads for
every application, they can decide which XenVMs work well together and which
ones will contend for resources.
Once the Xen Hosts are installed, administrators will have to create the XenVMs.
Xen provides different techniques for provisioning XenVMs. Users can create a new
XenVM by installing from media or network shares, they can clone a XenVM, they
can export a XenVM and use it as a template, or they can convert the OS on a physical
host to a "virtualized" XenVM.
WORKLOAD PLANNING AND VIRTUAL MACHINE PLACEMENT
As discussed in previous chapters, the appeal of virtualization includes the ability to
maximize the utilization of IT assets, reduce administrative overhead, and accelerate
provisioning times, among others. At first glance, virtualization is mostly about CPU
and memory utilization, but as most of us that have been implementing virtualization
technologies for years can attest, both network and disk I/O can also have a major
impact in workload combination decisions.
To accomplish an optimal workload mix, thorough research has been done on
current physical server utilization and an understanding of the additional horsepower
impact of newer servers and I/O subsystems.To help with this task, both commercial
and open source products are available that can assist in mapping physical-to-virtual
workloads.
Memory
Memory is one of the most expensive system components, and one that should not
be underestimated. Xen allows administrators to reserve a minimum amount of
memory specific to each virtual machine (VM) upon startup.
Understanding physical server memory utilization is a paramount factor in VM
placement. If a Xen host is oversubscribed, the XenVMs can run into physical
memory contention, creating a potential performance impact and, in some cases,
causing processes and VMs to crash.
CPU
One of the areas where server consolidation has the most impact is CPU utilization.
With CPU processing power doubling every couple of years, it is possible that when
analyzing the physical server CPU speed, coupled with the power of those processors
in comparison with current ones, a huge opportunity for workload consolidation
exists.
Make sure that systems with similar high demands on processor resources will not
cause contention hot spots as XenVMs running on the same Xen Host.
| DESIGNING & PLANNING...
|
Modeling CPU Consolidation
A simple rule of thumb when modeling load on an existing physical server to
a newer processor platform is to multiply the utilization of the processors by
the speed (clock cycles) and number of processors:
Number_of_Processors x Old_Processor_Speed x %_Utilization =
Total_consumed_processor_speed
For example:
4 processors x 1GHz x 40% = 1.6GHz
This last example only illustrates a straightforward number of cycles of
processing used. And although other factors in workload processing consolidation,
such as concurrency and context switching, result in a more complex
equation, from experience this rule of thumb has served well as the foundation
for VM placement and consolidation.
|
Network
The network is probably the most overlooked resource when migrating physical
servers to VMs.With today’s increasing bandwidth at the network infrastructure, it is
easy to overlook the cumulative demands of physical servers on the network.
Understanding that total network usage for all the VMs will now be exceeding
the physical interface(s) of the Xen Host is paramount to successful migration.
| DESIGNING & PLANNING...
|
High Availability, Replication, and Backups
Every IT organization has requirements in terms of system availability and data
protection. Most solutions that meet these requirements have to move data
between systems in the form of a network-based backup, via clustering, or by
logically replicating the data from one system to another.
These solutions can have different demands on networks: steady streams
of low-impact or periodic bursts, or, in the case of network-based backups,
steady, high-impact streams.
High availability High-availability solutions, such as clustering technologies,
often require different networks for different functions.
In most cases, a minimum of two networks are required: a public
network through which clients can communicate with the servers,
and a private network that is used for heartbeats, or messaging,
between cluster nodes. In addition, most clustering solutions best
practices include redundant networks or alternative networks,
which would limit the available networks to other XenVMs.
Replication Replication refers to the transport of data from one application
to another. Different application types, such as RDMBS and
e-mail systems, use proprietary methods to accomplish replication,
but the result is that either a subset or all of the data in the original
has to be transported to the replica. All of this traffic occurs
over the network (whether virtual or physical), and may be synchronous
or asynchronous. In either case, either a steady stream of
data or a periodic burst will occur on the network, and may impact
the performance of all VMs on a specific Xen Host.
Backups Although administrators can back up XenVMs using cloning
or exporting techniques (we won’t discuss the merits and
constraints of those techniques here), it is still highly recommended
that you back up using traditional network-based methods in
which a network server is attached to the media (tapes, disks, virtual
tapes, etc.) and to which clients send copies of files and data.
Backup applications will take advantage of any available bandwidth
to accomplish the backups in as little time as possible. So, cohabiting
XenVMs that have high data volumes and frequent data
changes will impact the performance of those VMs during backup
periods.
Also, be sure to take into consideration how much data needs to be
backed up and how frequently it changes.
|
In addition to the issue of bandwidth, network isolation due to security might
also be required, and taking into account that the XenVM’s virtual network interface
cards (NICs) and the Xen Host’s physical NICs are on the same subnet, and that any
Xen Host can have, at most, three NICs, users might find themselves in situations
that limit where they can place the XenVMs.
INSTALLING MODIFIED GUESTS
Modified guests are guest operating systems that are optimized by replacing the
kernel with a Xen-aware version and providing Xen-optimized disk and network
drivers that "understand" the underlying virtualization layers.
The process of installing modified Linux guests requires an "exploded" network
share of the installation binaries (not the ISOs of the CD-ROMs/DVDs). Although
it is not necessary to have a boot server (the XenVM will boot and then prompt for
the network share), having one allows for fully automated deployments of Linux
XenVMs.
In the following subsection, we will discuss how to install Red Hat ES 4 from a
network share.
Installing Red Hat Enterprise Linux 4
Red Hat ES 4 installation requires the use of a network share.The network share can
be run on the NFS, FTP, or HTTP protocol, depending on the user’s preference
and/or existing solutions. In addition, each protocol has a list of requirements and
dependencies that need to be met, including connectivity, binaries, and security considerations.
To install a Red Hat ES 4 XenVM, follow these steps:
- Log on to the Administrator Console.
- Select the Xen Host on which to deploy the Red Hat ES 4 XenVM.
- Click the Install XenVM button. The Install XenVM tab will appear in
the bottom pane, as shown in Figure 6.1.
The Install XenVM pane consists of the following fields and sections:
- Install From A pull-down menu that allows you to select the operating
system template that will be used for the XenVM.This template does not
contain OS images, but rather produces a default configuration for the components
in this type of XenVM (the number of virtual CPUs, disks and disk
sizes, NIC definitions, etc.).
- Name The unique alphanumeric identifier for the XenVM (this is not the
hostname of the resulting operating system).
- Description A nonmandatory field that allows you to identify the function
or other characteristics of the XenVM.
- Virtual CPUs The number of virtual CPUs that will be presented to the
XenVM.
- Initial Memory The amount of dedicated memory for the XenVM.
- Start on Server Boot A check box that indicates whether to start this
XenVM when the Xen Host boots.
- CPU Weight A drop-down menu that allows you to select the relative
CPU resource allocation for this XenVM.The values in the menu are Low,
Normal, and High.You also can define more granular CPU weight distributions
from the command-line interface (CLI).
- Storage On Host A display of the storage allocation to the Xen Host.
- Virtual Disks Displays the virtual disks to be used for this XenVM.To add
or remove virtual disks click on the plus (+) or delete (X) symbol. A new
virtual disk will appear, or the selected virtual disk will be removed.
- CD-ROM/DVD Allows you to select the media device to present to the
XenVM.
- Network Interfaces Presents you with the default NIC for the XenVM.
Clicking the plus or remove symbol will add NICs or remove the select
NIC from the screen. If more than one network is defined on the Xen
Host, the network column becomes a drop-down menu allowing you to
select the correct network for that interface.
- Once you have filled in all of the mandatory fields, click on the Install
button in the bottom pane.The Red Hat pseudographical install screen will
appear (see Figure 6.2). At this point, you have not indicated where the
install files are located, or a boot server from which to boot.This boot image
is actually provided by the Xen Host, and is selected based on the
Installation Type field shown in Figure 6.2.
- Select the appropriate language and tab to the OK button. Once the OK
button is highlighted, press the Enter key.The screen will change, and the
installer will prompt for the location of the media, as shown in Figure 6.3.
- Select the type of media to be used by using the up/down arrows.Then tab
until the OK button is highlighted and press Return.The new Red Hat ES
4 XenVM will request a network identity from the network (tftpboot/dhcp
servers), as shown in Figure 6.4.
- If no DHCP/TFTPBOOT server can be found, the installer will ask for
network information to be entered manually.
- After you supply the network information and click the OK button, the
installer will prompt you for information on the network share to use:
- If you selected NFS as the media type, the installer will prompt for the
hostname/IP address of the NFS server, and the installation directory, as
shown in Figure 6.5.
- If you chose HTTP, the installer will prompt for the URL of the server,
including the path to the installation files.
- If you selected FTP, the installer will prompt for the hostname/IP
address of the server along with the authentication credentials to be used.
- Once you’ve entered the share information, tab to the OK button and press
Enter. At this stage, the installation will commence, and the installer will
prompt you for all the configuration information. Refer to the Red Hat
Enterprise Linux documentation for complete installation instructions.
INSTALLING UNMODIFIED GUESTS
Support for installing unmodified guests is available only for Red Hat Enterprise
Linux 5, SUSE Linux Enterprise Server 10 SP1, and Windows XP/2003 (Windows
XP and Windows 2003 installations are covered in the section "Installing Windows
Guests," later in this chapter).
One of the characteristics of unmodified hosts is that you can install them
directly from vendor media, as opposed to modified guests, which you can install
only through network methods.
As discussed earlier in this book, unmodified guests refers to operating systems that
can actually run in emulated mode. And although unmodified guests can run permanently,
they use more resources because they use emulation drivers instead of the
Xen-provided drivers.
Installing Red Hat Linux Enterprise 5
You can install Red Hat 5 either from vendor media or via a network share.We will
discuss the process of installing from the original CD-ROMs and then paravirtualizing
the resulting XenVM.
- Log on to the Administrator Console.
- Select the Xen Host on which to deploy the Red Hat 5 XenVM.
- Click on the Install XenVM button. The Install XenVM tab will appear
in the bottom pane, as shown in Figure 6.6.
- Once you have filled in all of the mandatory fields (*), click on the Install
button at the bottom of the Administrator Console window.The History
tab in the lower pane will indicate the progress of the install.
- The Overview tab in the bottom pane will display the characteristics of the
newly created XenVM; however, the XenVM will not be powered on, as
indicated in the upper pane in Figure 6.7.
- Insert Disc1 of the Red Hat Enterprise Linux 5 distribution into the CDROM/
DVD of the Xen Host.
- Boot the XenVM by selecting it from the upper pane and clicking the
Power On button. The new XenVM will go through its boot sequence
from CD-ROM/DVD. Figure 6.8 shows the Red Hat install splash page in
the XenVM’s Graphical Console tab.
- Click inside the lower pane to get TTY control.To continue the install in
graphical mode, press Enter. The boot sequence is displayed on the
Graphical Console tab, as shown in Figure 6.9.
- The installation will prompt for user-defined parameters. Make sure to refer
to the Red Hat documentation for installation details.
- Once the installation is complete, the installer will prompt you to eject the
CD-ROM/DVD from the Xen Host’s bay and click on the Reboot
button. The Graphical Console will display the reboot process.
- When the XenVM has rebooted completely, it is ready for use. At this point,
however, the XenVM has not been paravirtualized, and as such, it is not performing
to capacity. Select the XenSource Linux P2V tools CD from the
CD-ROM/DVD pull-down.This will make the ISO image available for the
XenVM to use, but will not mount it.
- Mount the ISO image with the following command:
# mount –t iso9660 /dev/hdd /cdrom
- Copy the contents of the mounted ISO image to a separate location.This is
required because the Vendor Install media must be in the physical bay when
the paravirtualization script is called. When the copy command is complete,
enter unmount /cdrom:
# cp –ra /cdrom /"$TEMP_AREA"
- Insert the Red Hat Enterprise Linux 5 Disc1 into the Xen Host’s CDROM/
DVD.
- Run the xen-setup tool:
# $TEMP_AREA/xen-setup/xen-setup
- After the xen-setup script completes successfully, reboot the XenVM. After
the reboot, verify that the kernel for the XenVM has been paravirtualized:
# uname –a
INSTALLING WINDOWS GUESTS
Finally,Windows guests are supported in Xen.This is a much-anticipated event, as
Windows operating systems have the lion’s share of installations worldwide.
Much like Linux unmodified guests, you can install Windows guests from vendor
media and they are unmodified upon first installing the XenVM. However, a quick
run around the resulting operating system will show that paravirtualization is absolutely
necessary for any semblance of performance.
It’s important to understand what happens under the covers:
- First, the Xen Host provides the Windows installer with an emulated IDE
and NIC drivers, just to allow the installation to complete.
- After the installation has completed, you will need to install the XenPV
tools for Windows, which replace those drivers with optimized versions.
Windows Guest Installation
In this section we will discuss the steps for installing a Windows guest.
-
Insert the Windows CD-ROM in the Xen Host on which you want to
deploy.
- Log on to the Administrator Console.
- Select the Install XenVM button, after selecting the desired Xen Host.
The Install XenVM tab appears, as in Figure 6.10.
- After entering the appropriate information to identify the XenVM (and
selecting the Server DVD Writer), click the Install button in the lower
pane.The lower pane will be switched to the Graphical Console for the new
XenVM, as shown in Figure 6.11, and the Windows Installer screen will
appear.
- After you work your way through the Windows installation, the OS will be
booted completely. In the lower pane, the Media drop-down menu will
appear. Select the PV Tools for Windows option from the menu (see Figure
6.12).
- The End User License Agreement (EULA) will appear on the screen (see
Figure 6.13).
- Click on the Accept the terms of the License Agreement check box
and then click on the Next button.
- Follow the installation instructions.To finalize, the installer will reboot the
Windows XenVM.At this point, the resulting XenVM is fully paravirtualized
and ready to use.
PHYSICAL-TO-VIRTUAL MIGRATIONS OF EXISTING SYSTEMS
Physical-to-virtual (P2V) migrations consist of copying and modifying the operating
system files of a physical server to either a logical volume on a Xen Host or a network
share. Once the files have been copied, the result is a bootable XenVM.
P2V migrations are now industry-standard, as one of the main advantages of virtualization
is the ability to reduce the physical data center footprint. Xen provides a
P2V tool in the installation media, but third-party vendors have developed extendedfunctionality
products to assist companies with their migrations.
The P2V tool provided by Xen works only on Linux physical hosts, and then
only on those with PAE support.You cannot migrate Windows physical servers with
Xen’s provided P2V tool; however, several third-party vendors support Windows
migrations.
P2V Migration
To migrate a physical server to a XenVM, follow these steps:
- Boot the physical server from the Xen installation media.
- At the Welcome to Xen screen, tab to the OK button and press
Return.
- After the installer has reviewed the server components, two choices will
appear. Select the P2V option, then tab to the OK button and press
Return.
- Click the OK button on the Welcome screen.
- The next screen requires the networking information for the resulting
XenVM.You can choose to either allow the Dynamic Host Configuration
Protocol (DHCP) for all interfaces, or manually configure them. Once completed,
tab to the OK button and press Return.
- After the installer has verified that the physical host is running a supported
version of Linux, tab to the OK button and press Return.
- Enter a name and description for the XenVM.This is not the hostname as
registered in the operating system, but rather the name displayed on the
Administrator Console or through the CLI.
- Enter the desired size of the root disk, or accept the defaults, and then
select OK and press Return.
- Select the target location for the resulting file system.The options are Xen
Host or an NFS server. Once you’ve made your selection, tab to the OK
button and press Return.
- Enter the IP address of the Xen Host, tab to the OK button, and press
Return.
- Enter the root password for the Xen Host, and select OK.
- After the progress bar has completed, select OK. The physical server will
eject the Xen Installation CD-ROM and reboot the server. Make sure to
take out the media before the reboot.
- You can verify that the installation completed by launching the
Administrator Console and selecting the XenVM name given in step 7.
IMPORTING AND EXPORTING EXISTING VIRTUAL MACHINES
Exporting is a mechanism for copying a XenVM.You can then use the copied
XenVM as a template (like a clone) to create similar XenVMs with the characteristics
of the original. In addition, you can import the exported XenVM to a different
Xen Host (a mechanism that you can use to increase XenVM availability, or in disaster
recovery solutions).
The process involves copying the virtual disks (VDIs) of the exported XenVM
along with an XML document describing the configuration, as shown in Figure
6.14. The files are copied from the Xen Host to the Administrator Console.The
Administrator Console will need enough disk space to store the VDI images.
| NOTE : The VDI images will be compressed and are usually smaller than the actual
size of the disk.
|
Exporting XenVMs
Before starting the export process, administrators need to ensure that the
Administrator Console server has enough disk space to store the exported XenVM
files:
- Log on to the Administrator Console.
- Select the XenVM that will be exported.You must shut down the XenVM
in order to export it. If the XenVM is still running, click on the Power Off
button.
- Once you’ve shut down the XenVM, click on the Export button. Figure
6.15 shows the Export tab that appears.
Three fields appear:
- Name
- Description
- Export To The directory on the Administrator Console in which to save
the exported XenVM.
- Click on the Export button to begin the process.The lower pane will
switch to the History tab for the XenVM and a progress bar will appear
showing the status of the export. Export can take a long time, depending on
the number and size of the virtual disks and the network bandwidth available
between the Xen Host and the Administrator Console.
Importing XenVMs
Importing a XenVM consists of moving the exported XenVM’s files to a Xen Host.
The process is the reverse of the export operation; copying the VDI files and XML
file from the Administrator Console to the Xen Host.
To import a previously exported XenVM, follow these steps:
-
Log on to the Administrator Console.
- Click on the Xen Host to which the XenVM will be imported.
- Click on the Import XenVM button, and the Import XenVM tab appears
in the lower pane. Figure 6.16 illustrates the Import XenVM tab.
- In the Import From: field, enter the location of the export XenVM directory,
and then click the Import button. The lower pane will immediately
change to the History tab for the imported XenVM.The import process
may take awhile, as the VDI files are being copied over the network and
then reassembled on the Xen Host.
| DESIGNING & PLANNING...
|
Export/Import XenVM As an Enterprise Tool
The ability to "transport" a XenVM via export/import is one of Xen’s most
powerful yet underrated features. In today’s IT landscape, where business
demands are progressively greater and budgets are lower, having a flexible
tool that can decrease provisioning times, increase overall availability, and
reduce disaster recovery costs is indeed a necessity.
Exporting a XenVM allows administrators the flexibility of moving
XenVMs from one physical Xen Host to another. Downtime for XenVM migrations
due to hardware maintenance and hardware migrations can be reduced.
In addition, administrators can export XenVMs and use them as templates for
creating additional XenVMs on other Xen Hosts, cutting down on provisioning
times.
However, exporting and importing XenVMs can be time-consuming, and
this is something to consider if you are planning to use this mechanism as a
way to migrate XenVMs among Xen Hosts.
In addition to exporting and importing XenVMs, Xen provides an interface
to "migrate" XenVMs from one Xen Host to another. From a high level,
live migrations consist of moving the active memory pages and the NIC defi-
nitions (along with Internet Protocol [IP] address and ARP tables) for a XenVM
between Xen Hosts. In addition, both Xen Hosts involved in the operation
require simultaneous access to the VDI definitions of the XenVM and the same
local area network (LAN).
Currently, the XenSource Administrator Console does not have an interface
for performing live migrations of XenVMs. However, the XM CLI provides
a mechanism to accomplish live migrations:
xm migrate –-live XenVM_NAME XEN_HOST_NAME
This command will move the XenVM named XenVM_NAME to the
Xen_HOST_NAME physical server from its current Xen Host.
Although you can move a XenVM with either mechanism, both have benefits
and constraints:
As discussed earlier, exporting requires that the XenVM be powered off.
In contrast, live migrations move the XenVM between Xen Hosts in "real time"
(depending on the application, the XenVM might need to be quiesced).
However, live migrations require shared storage, which adds a cost to the
infrastructure. Exporting XenVMs doesn’t require such costs, but takes signifi-
cantly longer to accomplish.
You can use exported XenVMs as templates to create additional XenVMs,
whereas live migrations don’t actually copy the XenVMs files; they just move
control of the VDIs to another physical host.
|
SUMMARY
XenVM deployment is at the heart of Xen’s functionality. In most cases, administrators
will start by creating some test XenVMs from either the Administrator Console
or the CLI. As users get more comfortable, additional deployment techniques such as
cloning or exporting/importing are employed. And after the value of Xen has been
tested and proven, users will start using physical-to-logical migrations as an indispensable
tool.
Soon, administrators will discover that not all XenVMs can be placed together, as
they contend for any or all of the resources on the Xen Host. At that stage, exporting
the XenVMs to a different Xen Host allows administrators to balance the workload
more evenly.
At a more developed stage, administrators understand that moving XenVMs from
one Xen Host to another needs to be more streamlined and dynamic. Enter live
migrations, which allow administrators to reduce and even eliminate the downtime
associated with moving the XenVMs to another physical host, but for which the IT
group has to make additional investments in infrastructure.
SOLUTIONS FAST TRACK
Workload Planning and Virtual Machine Placement
-
Understanding physical application requirements is paramount to planning
the workload for a virtual environment.
- You determine workloads by measuring the use of CPU, memory, network,
and disk I/O on either the physical host or the XenVM.
- With today’s enterprise infrastructure components, disk I/O and the
network are usually simpler to consolidate.
- CPU and memory are often the most critical components in workload
balancing, and usually they are the most expensive resources on the physical
servers.
Installing Modified Guests
-
Modified guests refer to operating systems that are "paravirtualized" during
the installation process, such as Red Hat Enterprise Linux 4.x and SUSE
9.x.
- You can install modified guests only from a network share. Supported
protocols for installation network shares are NFS, HTTP, and FTP.
Installing Unmodified Guests
- Unmodified guests are based on operating systems that do not need to be
paravirtualized in order to run as a XenVM.
- Operating systems that support unmodified guests include Red Hat
Enterprise Linux 5, SUSE 10.1, and Windows XP/2003, and they require
the use of processors with virtualization extensions built in, such as the
Intel-VT and AMD-V.
- In contrast to modified guests, you can install unmodified guests from
vendor media, such as CD-ROM or DVD.
- Although you can deploy unmodified guests without being paravirtualized, it
is highly recommended that you modify them once installed, as performance
will improve dramatically.
Installing Windows Guests
- Windows guests are installed as unmodified guests. Administrators then have
to paravirtualize them.
- Windows XP, 2000, and 2003 are supported.
- In order to run Windows XenVMs, the Xen Host has to have a processor
with virtualization extensions. Currently, only physical hosts with the Intel-
VT or the AMD-V processors are supported.
Physical-to-Virtual
Migrations of Existing Physical Servers
- P2V migrations are accomplished by booting the physical servers from the
Xen install CD and copying and modifying the contents of the boot disk to
the Xen Host.
- Although you can convert all operating systems supported in XenVMs from
physical to logical, only Linux operating systems are supported with the Xen
installation media.Windows operating systems require third-party tools to be
converted.
- P2V migrations allow administrators to minimize the impact of converting
physical servers. In addition, P2V migrations also minimize risk by keeping
the original server intact.
Importing and Exporting Existing Virtual Machines
- Exporting an existing VM involves copying the virtual disk definitions from
the Xen Host to the Administrator Console. In addition, an XML definition
file is copied and is used to "reproduce" the identity of the XenVM.
- You can use XenVM exports to move the VM from one physical host to
another.You also can use exports as a way to create templates and simplify
deployments.
- You import a XenVM when the resulting files from an export are moved
from the Administrator Console to a Xen Host.
- Export and imports of XenVMs can take a relatively long time, depending
on the size of the VDIs and the network bandwidth available between the
Xen Host and the Administrator Console.
FREQUENTLY ASKED QUESTIONS
The following Frequently Asked Questions, answered by the authors of this book, are
designed to both measure your understanding of the concepts presented in
this chapter and to assist you with real-life implementation of these concepts. To have
your questions about this chapter answered by the author, browse to www.syngress.
com/solutions and click on the "Ask the Author" form.
Q: What are the pitfalls of migrating a physical server to VMs indiscriminately?
A: Not all workloads perform well together.Take into consideration the resource
requirements of each physical server before deciding which Xen Host to migrate
it to, and even whether migration is a viable option at all.
Q: Why can some Linux operating systems be installed directly from media, whereas
others require a network-based install?
A: Hardware virtualization is a relatively new development in the x86 arena. Older
operating systems are not "virtualization-aware," so they will not run as an
unmodified XenVM. In contrast, the latest batch of Linux from Red Hat and
SUSE "understands" virtualization.
Q: Is export/import a viable technique for implementing workload balancing?
A: It really depends on the availability requirements of the underlying application.
Exports and imports can require long periods of time to complete, as the data
from the XenVM is transported to and from the Administrator Console over the
network. If the application can be down for those periods, export/import may be
a viable technique.
Q: Are live migrations quicker than export/import?
A: Yes, they are; however, live migrations require higher technical and financial commitments.
Live migrations reduce downtime greatly when you’re trying to
achieve workload balancing; however, they require higher-bandwidth network
and shared storage (SAN).These requirements increase the environment’s complexity
and create additional administrative overhead.
|
Windows IT Pro
Register
