Client - Name Project - Name: Citrix® Xenserver™ 5 Design

<Client Logo>
Client_Name
Project_Name
Citrix® XenServer™ 5 Design
[Insert Date, 2008]
Prepared by:
Project_Lead
[Title]
PartnerABC
[Name]
[Title]
PartnerABC
Revision History
Revision Change Description Updated By Date
-i-
How to use the Citrix XenServer 5 Design Template
This is just a template and should be modified as you see fit. That
includes adding and/or removing sections and subsections to fit
the needs of the client and project.
All text written in orange should be removed. Orange is used to provide

the writer with tips and tricks and is information only.
All text written in blue should be replaced with applicable verbiage. Blue is
used to provide sample verbiage and should not be used as is.
Before you are finished, please double check:

• Properties of document (in particular, check custom tab)
o Note: As stated on the cover page, several variable fields such
as client and project are automatically entered based on the
Properties entry. To automatically update all variable fields,
click EditSelect All and F9.
• Confirm that all reviewer changes and comments in Track Changes
have been addressed
• Update fields and page numbers in Table of Contents
• Review all headers and footers
o To update the footers with variable fields, highlight the footer
text and press F9. Please note that there are two sets of footers
in the document: one for the Table of Contents section and one
for the main body of the document.
• Review overall formatting
• Remove all orange and blue text
- ii -
Deliverable Signoff
The signatures below indicate Client_Name’s and PartnerABC’s agreement to the contents of the Citrix®
XenServer™ 5 Design.
Client_Name PartnerABC
Name: Name:
Signature: Signature:
Title: Title:
Date: Date:
- iii -
Table of Contents
1.Executive Summary......................................................................................................1
1.1Project Overview..............................................................................................................................1
1.2Deliverable Overview........................................................................................................................1
1.3Deliverable References....................................................................................................................3
1.4PartnerABC Resources....................................................................................................................3
1.5Next Steps........................................................................................................................................3
2.Architectural Design.....................................................................................................4
2.1Overview..........................................................................................................................................4
2.2Design Summary..............................................................................................................................4
2.3Design Concerns..............................................................................................................................4
XENSERVER...............................................................................................5
3.Host Configuration.......................................................................................................6
3.1Description.......................................................................................................................................6
3.2Key Decisions...................................................................................................................................6
3.3Design..............................................................................................................................................7
3.4XenServer Host Parameters.............................................................................................................7
4.Resource Pools ............................................................................................................8
4.1Description.......................................................................................................................................8
4.2Key Decisions...................................................................................................................................8
4.3Design..............................................................................................................................................9
4.4Resource Pool Design......................................................................................................................9
5.XenMotion & High Availability...................................................................................11
5.1Description.....................................................................................................................................11
5.2Key Decisions.................................................................................................................................11
5.3Design............................................................................................................................................12
5.4XenMotion Configuration................................................................................................................12
5.5High Availability Configuration........................................................................................................12
6.Storage Infrastructure................................................................................................14
6.1Description.....................................................................................................................................14
6.2Terminology....................................................................................................................................14
6.3Key Decisions.................................................................................................................................16
6.4Design............................................................................................................................................17
6.5Boot Storage Configuration............................................................................................................17
6.6Virtual Disk Storage Configuration .................................................................................................18
6.7ISO Library Configuration...............................................................................................................20
7.Network Infrastructure...............................................................................................21
7.1Description.....................................................................................................................................21
7.2Terminology....................................................................................................................................21
7.3Key Decisions.................................................................................................................................22
7.4Design............................................................................................................................................22
7.5Physical NIC Configuration.............................................................................................................23
7.6Management Interface Configuration.............................................................................................23
7.7Host Networks................................................................................................................................23
7.8XenServer IP Address Table..........................................................................................................24
7.9Network Communications...............................................................................................................24
8.Server Hardware Environment..................................................................................25
8.1Description ....................................................................................................................................25
8.2Key Decisions.................................................................................................................................25
8.3Design ...........................................................................................................................................26
- iv -
8.4Server Hardware Configuration .....................................................................................................26
8.5Aggregated Capacity......................................................................................................................27
SYSTEMS MANAGEMENT.......................................................................28
9.Systems Management................................................................................................29
9.1Description.....................................................................................................................................29
9.2Key Decisions.................................................................................................................................29
9.3Design............................................................................................................................................29
10.XenCenter Configuration.........................................................................................30
10.1Description...................................................................................................................................30
10.2Key Decisions...............................................................................................................................30
10.3Design..........................................................................................................................................31
10.4XenCenter Hardware Requirements.............................................................................................31
10.5XenCenter Configuration..............................................................................................................32
10.6Email Notification Settings............................................................................................................32
10.7XenServer System Alert Configuration.........................................................................................32
10.8Custom Fields, Searching and Tagging........................................................................................33
10.9Software Updates.........................................................................................................................33
11.Backup and Recovery..............................................................................................34
11.1Description...................................................................................................................................34
11.2Key Decisions...............................................................................................................................34
11.3XenServer Host Backup ..............................................................................................................35
11.4Virtual Machine Metadata Backup ...............................................................................................35
11.5Virtual Machine Backup................................................................................................................36
11.6Virtual Machine Snapshots...........................................................................................................36
11.7Disaster Recovery........................................................................................................................37
VIRTUAL MACHINES................................................................................38
12.Virtual Machine Design............................................................................................39
12.1Description...................................................................................................................................39
12.2Key Decisions...............................................................................................................................39
12.3Design..........................................................................................................................................40
12.4Virtual Machine Configuration......................................................................................................41
12.5Virtual Machine Templates...........................................................................................................41
12.6Virtual Machine HA Configuration.................................................................................................42
12.7Workload Migration Process.........................................................................................................42
13.Workload Matrix........................................................................................................45
13.1Description...................................................................................................................................45
13.2Key Decisions...............................................................................................................................45
13.3Citrix Server Virtualization Assessment (SVA).............................................................................45
13.4Desktop Workload........................................................................................................................46
SECURITY.................................................................................................47
14.Security......................................................................................................................48
14.1Description...................................................................................................................................48
14.2Key Decisions...............................................................................................................................48
14.3Design..........................................................................................................................................49
-v-
APPENDICES............................................................................................50
15.Appendix A: XenServer Networking Explained.....................................................51
15.1Internal Networks..........................................................................................................................51
15.2External Networks........................................................................................................................51
15.3Bonded Interfaces........................................................................................................................52
15.4VLAN’s.........................................................................................................................................52
15.5Virtual Network Combinations......................................................................................................53
- vi -
1. Executive Summary
1.1 Project Overview
Client_Name . . .
Currently,
The business drivers for this effort revolve around . . .
1.2 Deliverable Overview

This Architectural Design document is the result of collaboration with . . .
Based on those collaborative discussions, the architecture described within this document
represents the design decisions made in conjunction with PartnerABC during the course of this
engagement.
This Architectural Design is organized as follows:
Citrix XenServer 5.0 Design

Section Topics Covered
Executive Overview This section provides an overview of the project, including critical
and Architectural design considerations. It details the fundamental architecture of the
Design new XenServer design. High-level decisions are summarized as
related to the overall architecture of the solution.
XenServer
Host Configuration This section defines the general configuration and installation
parameters for the XenServer deployment. The XenServer host
consists of a Xen-enabled Linux operating system, a management
agent, VM templates, and a local storage repository reserved for
VMs.
Resource Pools This section defines the planned architecture of the XenServer
Resource Pool. Within this section Resource Pools, number of
XenServer hosts, number of pools, networking, shared storage,
XenMotion and High Availability (HA) options are defined.
XenMotion and High This section defines how the Resource Pool and respective
Availability XenServer hosts will be configured to accommodate XenMotion and
High Availability (HA) features to provide availability and protection to
the guest virtual machines. It includes information regarding
XenMotion requirements, as well as HA protection levels.
Storage Infrastructure This section defines the planned architecture for the storage
infrastructure for individual XenServer hosts and the shared storage
required for hosts configured in Resource Pools. Within this section,
storage hardware, the underlying disk sub-system, RAID types,
dynamic multipathing, ISO library settings, virtual disk images (VDI)
types and virtual machine storage are defined.
Network This section defines the physical network interface cards (NICs),
Infrastructure virtual switches and associated virtual machine networks, VLAN
information, and NIC bonding configuration used on XenServer hosts
and virtual machines to enable networking.
Citrix XenServer 5.0 Design
Server Hardware This section defines the underlying server hardware platform for the
Environment XenServer host. Within this section, hardware configuration such as
CPU, memory, NICs, disk, host bus adapters (HBAs) and the
aggregate server capacity within the XenServer Resource Pool are
defined.
Systems Management
Systems This section discusses design decisions related to managing the
Management XenServer environment. The selection of appropriate management
tools, delegation of tasks based upon user and group assignment and
security of available management tools are all discussed.
XenCenter This section defines the configuration settings for the XenCenter
Configuration management console, client requirements, software updates,
searching and tagging, email notifications, alerts and monitoring
requirements.
Backup and This section describes the backup and recovery requirements for the
Recovery XenServer environment including XenServer host backup, Resource
Pool requirements, and snapshotting and guest virtual machine
metadata. Backup and recovery procedures and technologies
implemented are also defined to ensure the XenServer environment
is protected.
Virtual Machines
Virtual Machine The Virtual Machine section defines the guest virtual machines which
Design will be hosted in the XenServer infrastructure. Within this section,
characteristics of the virtual machines, including virtual hardware
configuration, template configuration, home server settings, high
availability protection levels and P2V methodology are discussed.
Workload Matrix This section details the planned desktop and server workloads that
will be hosted as guest virtual machine on the XenServer
infrastructure. Information gathered as a result of the Citrix Server
Virtualization Assessment, if it was conducted, will also be discussed.
Security
Security This section discusses the security related aspects of the XenServer
design. Physical server security, along with encryption and enclave
networking are analyzed.
Section Approach
Each design topic is organized into three subsections:
• Overview. This subsection provides an overview of the key concepts within the Key
Decisions and Design Sections.
• Key Decisions. This subsection provides a decision matrix for Client_Name based on line
items. Client_Name can use the decision matrices as quick reference guides to identify
settings and configuration decisions to be implemented in the environment.
• Design. This subsection provides justification and additional information related to the Key
Decisions and discusses their relevance to Client_Name’s virtual desktop environment.
-2-
1.3 Deliverable References
The deliverable provides guidelines for the implementation. However, it does not provide step-by-
step instructions on how to install the components discussed. Therefore, PartnerABC recommends
that administrators involved in the implementation review the following documents, articles, and
guides prior to building and implementing the production environment. All of these documents are
available from the Document Center or online Citrix Knowledge Base.
• Citrix XenServer Administrators guide
• Citrix XenServer Installation Guide
• Citrix XenServer Virtual Machine Installation Guide
The following icons will be used throughout the document in order to highlight important
information:
Symbol Description
This icon indicates that a decision is required based on the environment specific
information.
This icon indicates important notes that need to be considered as part of the
further planning process.
1.4 PartnerABC Resources

The following PartnerABC associates contributed to this project:
PartnerABC
Project_Lead Staff Consultant
Title Title
Address Address
Tel: Tel:
Mobile: Mobile:
Email.email@email.com Email.email@email.com
1.5 Next Steps

Based on the Statement of Work dated xx xx, 2008, this document represents the architectural
design for the Citrix XenServer environment. Following this, . . .
-3-
2. Architectural Design
This section provides a high-level description of the proposed implementation based on requirements and
risks identified as part of the Server Virtualization Assessment, as well as the information gathered during
the course of the design discussions.
2.1 Overview
The architecture for the Citrix XenServer environment that has been designed . . .
This design takes into account . . .
The following diagram depicts the planned environment for . . .
[Include Visio diagram detailing the XenServer architecture]
2.2 Design Summary

In summation, this design is based on the following components designated as follows:
XenServer
XenCenter
Virtual Machines
2.3 Design Concerns

During the preceding assessment, as well as the development of this design, the PartnerABC team
found the following items to be risks or unknown factors associated with this project and therefore
represent concerns that may impact success:
• [Item1]
• [Item2]
• [Item3]
-4-
XenServer
-5-
3. Host Configuration
This section defines the general configuration and installation parameters for the XenServer deployment.
The XenServer host consists of a Xen-enabled Linux operating system, a management agent, VM
templates, and a local storage repository reserved for VMs.
3.1 Description
• Citrix XenServer. XenServer is the platform virtualization solution which enables the
creation of virtual x86 guest computers running on Xen, the open-source paravirtualizing
hypervisor with near-native performance.
• VM Support. Windows Virtual Machines (VMs) can be created only on XenServer hosts
equipped with 64-bit Intel VT-enabled or AMD-V CPUs. Linux VMs do not require
XenServer hosts that are equipped with Intel VT-enabled or AMD-V CPUs.
3.2 Key Decisions

Decision Point Design Decision Justification
XenServer 4.1
Version 5.0
XenServer Enterprise
Edition Platinum
OEM
Hotfix Level List hotfixes here
Type of New
Deployment Upgrade
Deployment CD
Scenario HTTP….etc
Deployment
Location
Naming Server naming
Convention convention
Server Overview of server
Hardware specs…
Specifications
Storage Type of storage
Configuration used locally, SAN,
iSCSI, NFS…etc
Networking Management
Configuration Virtual machine
networking
NIC Bonding
Number of
XenServer
Hosts
-6-
3.3 Design
The configuration settings of XenServer are detailed below. These settings…..
Within this section, you should explain any details that require additional verbiage; it is not
necessary to simply restate any items that are contained within the Design Decisions table unless it
is a lead-in to a more detailed explanation.
Where possible, include screen shots, diagrams, tables, or graphical depictions to explain the
design. A picture is worth 1,000 words (and reads a lot easier)! There are some tables included for
your convenience, but these should be modified, appended, or deleted as necessary.
Remember that blue text is sample text only!
3.4 XenServer Host Parameters

This section details the XenServer deployment parameters required during the server installation
process.
Configuration Option Value
Keyboard Mapping Qwerty, US
Installation type New Install
Upgrade
Pre-installed (OEM)
Hardware Virtualization Assist Enabled
Disabled
Installation Source CD
HTTP or FTP
NFS
USB (OEM)
Linux Pack enabled Yes or No
Root Password
Primary Disk /dev/hda
Size in GB
Management Interface eth1
MAC Address
NIC Type/Model
Networking Configuration Static
DHCP
IP Address details
Hostname Configuration
DNS Configuration
Time Zone Australia | Sydney
System Time Configuration Using NTP
Manual Time Entry
NTP Server/s NTP Server 1
NTP Server 2
NTP Server 3
-7-
4. Resource Pools
This section defines the planned architecture of the XenServer Resource Pool. Within this section
Resource Pools, number of XenServer hosts, number of pools, networking, shared storage, XenMotion
and High Availability (HA) options are defined.
4.1 Description
A resource pool comprises multiple XenServer host installations, bound together into a single
managed entity which can host VMs. Features which provide guest availability and resiliency such
as XenMotion and HA are only available through a XenServer Resource Pool. A resource pool is
an aggregate of one or more homogeneous XenServer hosts, up to a maximum of 16. The
definition of homogeneous is:
• each CPU is from the same vendor (in particular AMD-V and Intel VT CPUs cannot be
mixed)
• each CPU is the same model (except for stepping)
• each CPU has the same feature flags
• all hosts are running the same version of XenServer software
In addition to being homogeneous, an individual XenServer host can only join a resource pool if:
• an Enterprise license is installed on the host
• it has a static IP address (either manually assigned or via DHCP);
• it is not a member of an existing resource pool
• its clock is synchronized to the same time source as the pool master (for example, via
NTP)
• it has no shared storage configured
• there are no running or suspended VMs on the XenServer host which is joining
• there are no active operations on the VMs in progress, such as one shutting down
• the management NIC of the XenServer host which is joining is not part of a NIC bond
4.2 Key Decisions

Number of
Resource Pools
Number of
XenServers per
Resource Pool
Decision for Administration
separate pools point, number of
guests…etc
Resource Pool
Locations
Dedicated Pool
Master
-8-
Number of
Guest Virtual
Machines
Resource Pool
Storage
4.3 Design
The configuration settings of XenServer Resource Pools are detailed below. These settings…..
Multiple Resource Pools are required because…..
4.4 Resource Pool Design

The following section defines the settings for Resource Pool 1.
Pool Name XEN Pool 1
Pool Description
Location Sydney
Number of XenServer Hosts 16 (Maximum number of hosts)
Assigned Pool Master Server Yes
XEN01
Pool Slave/Member Servers XEN02
XEN03
….
Number of guest VMs hosted 100
Guest OS types
Assigned Storage Repositories
Assigned Pool Networks
XenMotion Enabled Yes
HA Enabled Yes
The following section defines the settings for Resource Pool 2.

Pool Name XEN Pool 2
Pool Description
Location Sydney
Number of XenServer Hosts 16 (Maximum number of hosts)
Assigned Pool Master Server Yes
XEN01
Pool Slave/Member Servers XEN02
XEN03
….
Number of guest VMs hosted 11
-9-
Guest OS types Windows XP
Windows 2003 Server
Assigned Storage Repositories
Assigned Pool Networks
XenMotion Enabled Yes
HA Enabled Yes
- 10 -
5. XenMotion & High Availability
This section defines how the Resource Pool and respective XenServer hosts will be configured to
accommodate XenMotion and High Availability (HA) features to provide availability and protection to the
guest virtual machines. It includes information regarding XenMotion requirements, as well as HA
protection levels.
5.1 Description
• XenMotion. XenMotion is the live migration of guest VMs across different XenServer hosts
without any noticeable downtime. A Resource Pool combined with shared storage enables
VMs to be dynamically migrated on any host.
• High Availability (HA). XenServer adds automated high availability (HA) with resource-
based placement of VMs in the event of host server failures. HA includes dynamic fail-over
planning based on available resources to help ensure that VMs are restarted on the
appropriate physical server.
• HA Heartbeat. XenServer HA utilizes a storage and network heartbeat mechanism to
check and absolutely guarantee that a host is unreachable.
5.2 Key Decisions

XenMotion All XenServer
Enabled Pools will be
Resource XenMotion
Pool/s enabled
HA Enabled HA enabled pools
Resource include Pool1 and
Pool/s Pool2 only
HA Network Management
Heartbeat interface will be
bonded for
redundancy
HA Storage An FC based SR
Heartbeat will provide as
storage SR
HA Protection Servers will be
Levels protected with
differing priorities
while desktops will
be set to Best
Effort level only
Unprotected The remaining
VMs VMs will be
unprotected,
including the
following…..
- 11 -
HA Capacity The planned HA
capacity will
provide up to 2
XenServer host
failures as per the
server hardware
design
5.3 Design
XenMotion has been configured……
HA has been configured….
5.4 XenMotion Configuration

Using XenMotion Live Relocation, you can move a running virtual machine from one server to
another server in the same Resource Pool with no service interruption. A VM can only be migrated
if it is using shared storage resources within the pool.
The following table defines the Resource Pool and the respective XenServer hosts configured with
XenMotion.
XenServer Host Resource Pool XenMotion
XEN01 Pool1 Enabled
XEN02 Pool1 Enabled
XEN03 Pool1 Enabled
XEN10 Pool2 Enabled
XEN20 Pool2 Enabled
XEN30 Stand-alone Host Not Configured
XEN40 Stand-alone Host Not Configured
5.5 High Availability Configuration

With the XenServer HA feature enabled, XenServer continually monitors the health of the host
servers in the pool. The HA mechanism automatically moves protected VMs to a healthy host if the
current XenServer host fails. Additionally, if the host that fails is the master, HA selects another
host to take over the master role automatically.
The following table illustrates the HA configuration settings available on…..
For more detail on each VMs HA restart priority, refer to Section 11. Virtual Machine HA
Configuration.
Resource Pool Name
Resource Pool Master Server
Resource Pool Member Servers
- 12 -
HA Enabled Yes
No
Heartbeat Storage Repository
Heartbeat SR Type Shared storage limited to iSCSI
LUN or FC LUN
Heartbeat SR Size 400MB
(Minimum size is 356MB)
HA Protection Levels Protected
Priority 1: Server 1 to 3
Priority 2: VM 11 to VM20.etc
Priority 3:
Priority Level: 1, 2 and 3

Best-effort
Do not restart
- 13 -
6. Storage Infrastructure
This section defines the planned architecture for the storage infrastructure for individual XenServer hosts
and the shared storage required for hosts configured in Resource Pools. Within this section, storage
hardware, the underlying disk sub-system, RAID types, dynamic multipathing, ISO library settings, virtual
disk images (VDI) types and virtual machine storage are defined.
6.1 Description
• Storage Repository (SR). Storage Repositories are storage targets containing
homogeneous virtual disks. A XenServer host defines a container called a Storage
Repository to describe a particular storage target, in which Virtual Disk Images (VDIs) are
stored.
• Virtual Disk Images (VDIs). A VDI is an on-disk representation of a virtual disk provided to
a VM and is the fundamental unit of virtualized storage in XenServer.
• Shared Storage. A shared SR is required for Resource Pool creation and XenMotion
functionality. Shared SR includes the following storage types: iSCSI, Fibre Channel and
NFS storage.
• ISO Library. CD and DVD image files represented as ISO files can be stored on CIFS or
NFS based storage repositories. The ISO files can them be mounted o the guest virtual
machines and used during the operating installation.
6.2 Terminology
Citrix XenServer uses specific terminology to define various aspects of the storage architecture, the
following table explains this terminology, which is used throughout the remainder of the document.
XenServer Explanation Description
Acronym
SR Storage Repository A container where VDIs are stored. The SR types
supported are IDE, SAS, SCSI, SATA on Local disks,
and FC, NFS and iSCSI on shared storage. A XenServer
host can have access to multiple SR types.
PBD Physical Block The interface between the Storage Repository and the
Device physical host. A PBD is basically a connector that
attaches an SR to a XenServer host. PBDs store device
configuration information used to connect to a storage
system. For example, for NFS it contains the IP address
of FQDN of the NFS server and the export path that gets
mounted by the XenServer host.
VBD Virtual Block The interface between the VDI and the virtual machines.
Device VBDs map VDIs to VMs. They also provide for QoS for a
given VDI.
- 14 -
Acronym
VDI Virtual Disk A VDI is a disk abstraction where the contents of virtual
disks are stored. There are 4 VDI types: VHD, Logical
Volume Manager, NetApp and EqualLogic Managed
LUNs. The difference between Logical Volume Manager
and NetApp/EqualLogic Managed LUNs is that LUNs are
put under Linux LVM control whereas NetApp and
EqualLogic Managed LUNs are not.
The four VDI Types can be defined as follows:

• VHD: This format can be used with local disk on
top of an ext3 file system or over NFS. VDIs stored
on VHDs by default are thin provisioned.
• LVM: This format can be used with local disk or
shared storage. When a LUN is put under LVM
control, its split into multiple Logical Volumes each of
which will store a VDI.
• NetApp: Managed NetApp LUNs are accessible
via the NetApp SR driver type, and are hosted on a
Network Appliance device running a version of
ONTAP 7.0 or greater. LUNs are allocated and
mapped dynamically to the host via the XenServer
host management framework.
• EqualLogic: EqualLogic storage is accessible
via the EqualLogic SR driver type, and are hosted on
an EqualLogic storage array. LUNs are allocated
and mapped dynamically to the host via the
XenServer host management framework.
Via the XenCenter GUI, each VM can be configured with
up to 8 Virtual Disks including the CDROM. This can be
extended to 24 via the command line.
VHD Virtual Hard Disk The VHD format is a Microsoft open format for virtual disk
storage. In XenServer terms, a VHD file can only be used
on ext3 or NFS storage.
VHD files are sparse and extended in 2Mb chunks.
VHD files can also be chained.
The following diagram shows a graphical overview of storage repositories and related objects.
- 15 -
6.3 Key Decisions
XenServer Boot Local
Storage Boot from SAN
Local Storage IDE
SCSI
SATA
SAS
USB
Local Storage RAID-1 across 2 x
Configuration 72GB disks @
15,000 rpm
Virtual Machine Local
Storage Shared
Shared Storage
Configuration
VDI Type VHD
LVM
NetApp
EqualLogic
SAN Storage EMC CX300
Details
HBA Type Hardware
Software
Dynamic Enabled across
Multipathing QLogic HBAs
Heartbeat SR iSCSI LUN
FC LUN
Virtual Machine
Metadata
- 16 -
ISO Library CIFS share on
Settings Windows 2003
server FNP01
Virtual Disk Enabled for….
QoS
Data Enabled
Deduplicaton
Thin Enabled
Provisioning
6.4 Design
The XenServer OS will be installed on….
The shared storage configured for the XenServer Resource Pools will leverage…..
The Storage Repository…..
The virtual machines disk images…..
Server virtual machines will reside on SR X which is backed on RAID-10 FC LUNs……
Desktop virtual machines will reside on SRY which is backed on RAID-5 FC LUNs….
[Insert Visio diagram detailing the overall storage configuration, logical and/or physical connections]
6.5 Boot Storage Configuration

The following section defines the storage configuration of the XenServer boot volume which will be
used for the Xen OS binary installation.
[Insert Visio diagram detailing the Boot Storage configuration]
Boot Volume Storage Type IDE
SCSI
SATA
SAS
Boot from SAN
USB
Number of Disks 2
Disk Size 72GB
Disk Speed 15,000 RPM
RAID Configuration RAID-1 (Mirror)
Crash Dump SR Local
Shared Storage
Suspend SR Local
Shared Storage
- 17 -
6.6 Virtual Disk Storage Configuration
The guest virtual machine disk files represented as VDIs will be stored using ….
[Insert Visio diagram detailing the SR and VDI configuration]
Storage Repository Type Local Storage
Storage Repository Size
Storage Repository Name
VDI Type EXT
VHD
Local Storage Configuration 5 x 72GB 15,000 rpm SCSI
disks, RAID-5

Storage Repository Type NFS
Hosts Attached
Storage Repository Name
NFS Path
Advanced Options
NFS Storage Vendor
NFS Storage Model

Storage Repository Type iSCSI
Hosts Attached
SR Name
Target Host
iSCSI Port 3260
CHAP Enabled Yes/No
CHAP User
CHAP Secret
Target IQN
Dynamic Multipathing Enabled
Disabled
Number of Paths
iSCSI Storage Vendor
iSCSI Storage Model

Storage Repository Type NetApp
Hosts Attached
- 18 -
SR Name
NetApp Filer IP Address
Username
Password
CHAP Enabled Yes/No
CHAP User
CHAP Secret
Number of FlexVols in SR 8 (default)
Aggregate
FAS Thin Provisioning Enabled
Disabled
FAS Deduplicaton Enabled
Disabled
Disabled
Number of Paths
FAS Model NetApp FAS3020c
Ontap Version 7.2.2
FAS Storage Capacity

Storage Repository Type Hardware HBA
Hosts Attached
SR Name
HBA Type FC
iSCSI
HBA Vendor
HBA Model
Password
CHAP Enabled Yes/No
CHAP User
CHAP Secret
Number of FlexVols
FAS Thin Provisioning Enabled
Disabled
FAS Deduplicaton Enabled
Disabled
Disabled
Number of Paths

Storage Repository Type Dell EqualLogic
- 19 -
Hosts Attached
SR Name
Dell EqualLogic Filer IP Address
Username
Password
CHAP Enabled Yes/No
CHAP User
CHAP Secret
Storage Pool Name
Thin Provisioning Enabled
Disabled
Disabled
Number of Paths
Dell Storage Model
Dell Storage Capacity
6.7 ISO Library Configuration

The following section details the storage repository configuration of the ISO library.
Storage Repository Type CIFS
Name
Share Name
CIFS Authentication
User name
Password
Advanced Options
Available ISO files

Name
NFS Path
Advanced Options
Available ISO files
- 20 -
7. Network Infrastructure
This section defines the physical network interface cards (NICs), virtual switches and associated virtual
machine networks, VLAN information, and NIC bonding configuration used on XenServer hosts and
virtual machines to enable networking.
7.1 Description
• Physical Interface (PIF). A PIF represents a physical network interface on a XenServer
host. PIF objects have a name and description, a globally unique UUID, the parameters of
the NIC that they represent, and the network and server they are connected to.
• Virtual Interface (VIF). A VIF represents a virtual interface on a Virtual Machine. VIF
objects have a name and description, a globally unique UUID, and the network and VM
they are connected to.
• Host Network. A host network is a virtual Ethernet switch on a XenServer host. Network
objects have a name and description, a globally unique UUID, and the collection of VIFs
and PIFs connected to them. Host networks can include the network switch allocated for
management or guest virtual machine traffic.
• NIC bonds. NIC bonds can improve XenServer host resiliency by using two PIFs as if they
were one. If one NIC within the bond fails the host's network traffic will automatically be
routed over the second NIC. NIC bonds work in an active/active mode, with traffic balanced
between the bonded NICs.
7.2 Terminology
Citrix XenServer uses specific terminology to define various aspects of the network architecture.
The following table explains this terminology, which is used throughout the remainder of the
document.
Acronym
PIF Physical Interface A PIF represents a physical network interface on a
XenServer host. PIF objects have a name and
description, a globally unique UUID, the parameters of
the NIC that they represent, and the network and server
they are connected to.
VIF Virtual Interface A VIF represents a virtual interface on a Virtual
Machine. VIF objects have a name and description, a
globally unique UUID, and the network and VM they are
connected to.
Network The term network is used to describe a virtual Ethernet
switch (vSwitch) on a XenServer host. Network objects
have a name and description, a globally unique UUID,
and the collection of VIFs and PIFs connected to them.
Further details are described in Appendix A: XenServer Networking Explained.
- 21 -
7.3 Key Decisions
Number of XS supports up to
Physical NICS 6 physical NICs or
per Host 6 pairs of bonds
NIC Broadcom
Configuration 1Gbit Full-Duplex
NIC Bonding Active/Active
Configuration Bonds
External Production
Networks DMZ
Test/Dev
Internal NA
Networks
VLAN Production
Configuration (VLAN1)
…..etc
Management Bonded
Interface Management NIC
Configuration for redundancy
Storage NA
Network
Interface
Promiscuous Enabled on DMZ
Mode network
Virtual Switch Enabled for….
QoS
Physical Switch Dual Cisco 24-port
Details managed switch
with hardcoded
speeds
IP Address Refer to IP
Settings address table….
DNS
Configuration
DMZ
Configuration
7.4 Design
Each of the XenServer hosts will be configured with ….
The Management Interface used for XenCenter and XenMotion traffic will be …..
A dedicated Storage Interface will be used for …….
The Virtual Machine network include…..
NIC bonding will be configured to provide network redundancy ……
VLAN tagging at the virtual switch is used ….
- 22 -
[Insert Visio diagram detailing XenServer physical and logical network connections]
7.5 Physical NIC Configuration

This section defines the physical network interfaces and the associated host networks configured
on each of the XenServer hosts.
Physical Host NIC Speed/ Vendor Device
NIC Network Bonding Duplex
NIC0 mgmt_ No 1Gigabit/Full- Intel 8254 Gigabit Adapter
xenmotion Duplex
NIC1 iscsi No 1Gigabit/Full- Intel 8254 Gigabit Adapter
Duplex
NIC2 prod_lan Yes 1Gigabit/Full- Intel 8254 Gigabit Adapter
Duplex
NIC3 prod_lan Yes 1Gigabit/Full- Intel 8254 Gigabit Adapter
Duplex
[Insert Visio diagram detailing physical network connections and actual physical ports on the
XenServer server hardware]
7.6 Management Interface Configuration

This section defines the Management Interface settings and configuration types used for each
XenServer host. Dedicated storage network interfaces used for NFS or iSCSI storage repositories
are also defined below.
Type Host NICs IP DNS Settings VLAN Comments
Network Address
Management mgmt_ NIC 0 10.0.0.1 10.0.0.10 VLAN1 Used for XenCenter
Interface xenmotion 10.0.0.11 and XenMotion traffic
Storage iscsi NIC4 192.168.2.1 NA VLAN10 Used for iSCSI
interface storage traffic
7.7 Host Networks

This section details the host networks configured on the XenServer hosts and Resource Pool to
allow the guest virtual machine network connectivity.
Host Network NIC VLAN Auto Comments
Network Type Connected
Management External NIC 0 1 No Used for
XenCenter and
XenMotion traffic
Production Bonded NIC 2 NA Yes Used for
External NIC 3
DMZ External NIC 4 99 No
- 23 -
7.8 XenServer IP Address Table
This section details the IP address settings for each f the XenServer hosts configured for the
Resource Pools.
Resource Hostname IP Subnet Mask Gateway DNS1 Location
Pool Address DNS2
Pool 1 XEN01 10.0.0.1 255.255.255.0 10.0.0.254 10.0.0.10 Sydney
Pool 2 XEN99 Melbourne
7.9 Network Communications

This section details the commutation traffic between the different components of the XenServer
architecture.
[Insert Visio diagram detailing network communications and associated ports]
The following table describes the TCP port configurations for the Citrix XenServer environment.
Purpose Default port Port Number to be
number Used
SSH – XenCenter to XenServer TCP 22 Default
HTTPS – XenCenter to XenServer TCP 443 Default
RDP – XenCenter to VM (Windows) TCP 3389 Default
VNC – XenCenter to VM (Linux) TCP 5900 Default
- 24 -
8. Server Hardware Environment
This section defines the underlying server hardware platform for the XenServer host. Within this section,
hardware configuration such as CPU, memory, NICs, disk, host bus adapters (HBAs) and the aggregate
server capacity within the XenServer Resource Pool are defined.
8.1 Description
The XenServer host is a 64-bit x86 server-class machine devoted to hosting multiple VMs. This
machine runs a stripped-down Linux operating system with a Xen-enabled kernel which controls
the interaction between the virtualized devices seen by VMs and the physical hardware. The
following are the system requirements for the XenServer host:
• CPU. One or more 64-bit x86 CPUs at 1.5 GHz minimum; 2 GHz or a faster multi-core
CPU is recommended. Windows VMs can be created only on XenServer hosts equipped
with Intel VT-enabled or AMD-V CPUs
• Memory. A minimum of 1GB memory; 2 GB or more is recommended
• Storage. Locally attached storage including IDE, PATA, SATA or SCSI, with at least 16GB
of disk space; 60GB of disk space is recommended.
• Network. At least two 100 Mbit/seconds or faster network interface card (NIC) for
redundancy; however a Gigabit NIC is recommended for faster P2V migrations and
export/import data transfers and for live relocation of VMs.
8.2 Key Decisions

Server Dell
Hardware HP
Vendor IBM
Server Model ProLiant 380
Server
Number of 2 sockets
CPUs
Number of Quad-Core Intel at
Cores 2GHz
Total Server 64GB
Memory
Number of NICs 8 x Gbit NICs
Local Storage 2 x 72GB SCSI
disks RAID-1
Host Bus QLogic xxx
Adapters
Shared Storage EMC CX300 SAN
with FC SCSI
disks at RAID-10
shared LUN
presented to
XenServer hosts
Redundant Yes, two PSUs
Power Supply cabled to separate
Nits power rails
- 25 -
Aggregated 16 x XenServer
Capacity Hosts thereby a
total of ….
Server Build Manual installation
Process from CD
8.3 Design
The server hardware platform that will be used for the XenServer……
CPU…..
The physical memory configured ….
Shared storage will be configured using ….
Redundant components will be configured to provide….
[Insert Visio diagrams displaying the front and back views of the server hardware platform detailing
the disks, NIC ports, FC cabling to FC switches…etc – more detail the better or use multiple
diagrams to depict different hardware components]
8.4 Server Hardware Configuration

The following section details the hardware specifics of the XenServer hosts for the solution.
Hardware Value
Hardware Vendor
Server Model
Hardware Virtualization Support Yes, enabled
CPU
Number of CPU Sockets
Number of Cores per Socket
Total number of CPUs
CPU Vendor
CPU Model
CPU Speed
Memory
Allocated RAM
Server RAM Capacity
Type of RAM
Network
Number of NICs
NIC Speed
Total number of network interfaces
- 26 -
Hardware Value
Onboard/PCI Slot NIC0 - onboard
NIC1 - onboard
NIC2 – PCI slot 1
NIC2 – PCI slot 2
Refer to Visio diagram

Local Storage
Number of Disks
Disk Size
Disk Speed
Disk Type
RAID Card
RAID Type
Shared Storage
Host Bus Adapter (HBA)Type iSCSI
FC
HBA Vendor QLogic
HBA Model
Number of HBAs 2 configured for multipathing
Fibre Channel Switches Brocade Silkworm FC
Refer to Visio diagram for FC
physical connections
Other Devices
CD/DVD-ROM
Number of Power Supply Units (PSU) 2 x Redundant PSUs patched
to separate power rails
8.5 Aggregated Capacity

The below table illustrated the aggregated XenServer capacity available from the configured
Resource Pool compromising of ….hosts.
Resource Pool Number of Total CPU Total Memory Total Storage Total Network
XenServer (MHz) (GB) (TB) (Gbps)
Hosts
Pool 1 10 10GHz 640GB 2TB of SAN
Storage
available
- 27 -
Systems Management
- 28 -
9. Systems Management
The Systems Management section discusses design decisions related to managing the XenServer
environment. The selection of appropriate management tools, delegation of tasks based upon user and
group assignment and security of available management tools are all discussed.
9.1 Description
Designing and implementing a structured systems management solution for Citrix XenServer will
help to maintain the consistency and reliability of the XenServer infrastructure. As each XenServer
host will typically run several concurrent virtual workloads, the impact of an administrative error
which results in a systems outage will be magnified. The design should provide an overview of the
common management tasks which need to be undertaken in a typical XenServer environment,
discuss the most appropriate toolset for each task and make recommendations regarding how
administrative tasks should be delegated.
• Management Tool Selection. Selecting the most appropriate tool for each management
process will ensure that common tasks are carried out in a consistent manner. This should
help to ensure that each administrative task results in a predictable outcome, optimizing
the stability of the XenServer environment.
• Management Tool Access. The use of XenCenter where firewall traversal is necessary
requires specific thought. Port 443 needs to be open to allow general console access while
3389 and 5900 are required for RDP and VNC access to virtual machines.
• Management Tool Security. Selected tools should only be made available to relevant
personnel. The ability to download, launch and connect to servers using unauthorized
copies of support tools should be minimized wherever possible.
• Delegation of Administrative Processes. The design will need to focus on the proposed
management and support structure for the XenServer environment in order to recommend
an effective administrative model. Ensuring that each administrative tier is available only to
authorized personnel will ensure that unauthorized changes, intentional or otherwise,
which could affect the stability of both physical and virtual hosts and the associated cost of
resulting systems outage, can be avoided.
9.2 Key Decisions

Administrative XenCenter
Tools
Administrative Trust based.
Security
9.3 Design
- 29 -
10. XenCenter Configuration
This section defines the configuration settings for the XenCenter management console, client
requirements, software updates, searching and tagging, email notifications, alerts and monitoring
requirements.
10.1 Description
Apart from being the management console for a single stand-alone XenServer host to multiple
Resource Pools, XenCenter also includes some powerful tools for searching, sorting and grouping
your resources.
• Tags. Tags can be added to your managed resources to help you organize them. Tags are
like keywords or labels, and they allow you to rearrange your view of resources within
XenCenter depending on criteria such as purpose or geographic location.
• Custom Fields. Custom fields can be added to any of the resources within XenCenter
which can then be used in building search queries.
• Searching. The built-in Search box within XenCenter enables the administrator to search
and locate resources quickly.
• Monitoring server performance. Performance data from the XenServer hosts and
individual guest virtual machines such as CPU, memory and network I/O usage is
monitored by XenCenter.
• System Alerts. Alerts may be generated to keep you informed of system events including
performance alerts, HA (high availability) status alerts and software update alerts. Email
notification is sent to the administrator when a preconfigured system event is triggered.
10.2 Key Decisions

XenCenter 5.0.0
Version
Build Number Build 10918
Software NA
Patches Applied
Configured Pool1
Pools Pool2
Management Server01
Computer
Management Same datacenter
Computer as XenServers
Location
Authorized Users Limited to Domain
of Management Administrators
Computer Group
Proxy Server proxy.domian.com
Settings Port 8080
Log Destination Local
Remote
Email Alerts and Default alerts
Monitoring configured
- 30 -
SMTP Server mail1.domain.com
Custom Fields NA
Automatic Enabled
Software
Updates
10.3 Design
XenCenter will be installed on ….
Access to the XenCenter management computer located at the datacentre s limited to …..
XenCenter will be configured with ……
Default XenCenter alerts and event notifications will be delivered via SMTP using….
[Insert Visio diagram detailing the location of the XenServer hosts, XenCenter with respect to data
center locations and connections]
10.4 XenCenter Hardware Requirements

The XenCenter application for managing the XenServer host and Resource Pools can be installed
and run on desktops, laptops or servers which satisfy the following requirements:
• Operating system. Windows XP, Windows Server 2003, or Windows Vista
• Software. .Microsoft NET Framework version 2.0 or above
• CPU. Minimum of 750MHz; 1GHz or faster is recommended
• Memory. Minimum of 1GB; 2GB or more is recommended
• Storage. Minimum of 100MB
• Network. 100Mb NIC or faster
Configuration Value
Computer Name (FQDN) ManagementPC.domain.com
Hardware Type HP Desktop
Function Dedicated management
terminal
IP Address Details 192.168.2.100
255.255.255.0
192.168.2.254
Management Network A separate VLAN for
management traffic exists on
VLAN1
CPU Single Intel
Memory 2GB
NIC 1 x Gigabit NIC
Operating System Windows XP Pro
Software Installed .NET Framework Version 3.5
- 31 -
10.5 XenCenter Configuration
The following section defines the configuration parameters for the XenCenter client.
Configuration Value
XenCenter Version
Build Number
Management Computer
Authorized Users/Groups
Proxy Server Connection Don’t use proxy server
Use proxy settings from IE
Use specific proxy server
Graphic Console Type Windows VMs – VNC or RDP
Linux – vncterm (text) or VNC
Connection Timeout 20 seconds (Default)
Performance Graphs Area
Line
Log Destination Local
Remote
SSH Enabled
Console Auto-Logout Timeout 5 minutes (default)
10.6 Email Notification Settings

Email notifications will be sent when system alerts are generated from the servers and the VMs
configured within the resource pools or hosted on the stand-alone XenServer. The following
settings defined the email notification parameters for XenCenter.
Configuration Value
Email alert notification enabled Yes/No
Email Address xenalert@domain.com
SMTP Server Mail.domain.com
SMTP Port 25 (Default)
Performance Graphs Area
Line
10.7 XenServer System Alert Configuration

XenServer and XenCenter provide access to alerts that are generated when noteworthy events
happen. XenCenter provides various mechanisms of grouping and maintaining metadata about
managed VMs, hosts, storage repositories, and other actions. The following settings defined the
system alert configuration settings for XenCenter.
Configuration Value Monitored
XenServers
Alert Repeat Interval 60 minutes (default) XEN01
CPU Usage Alerts
- 32 -
Configuration Value Monitored
XenServers
CPU Threshold 50% (default)
Sustained Usage 1 minute (default)
Network Usage Alerts
Network Threshold 100 Bytes/second (default)
Sustained Usage 1 minute (default)
10.8 Custom Fields, Searching and Tagging

XenCenter supports the creation of tags and custom fields, which allows for organization and quick
searching of VMs, storage, network and other objects. XenCenter supports the creation of
customized searches. Searches can be exported and imported, and the results of a search can be
displayed in the navigation pane. The following section defines the customer fields and searches
that will be implemented on XenCenter.
Add list of custom fields here…
10.9 Software Updates

XenCenter is configured by default to periodically check for XenServer updates. The automatic
update searches out and allows you to download new versions and patches for XenServer and
XenCenter. Updates to the XenServer product family, including critical updates, hotfixes, and
security updates can be downloaded automatically and quickly deployed to specific pools or
servers.
Configuration Value
Check for new versions of XenServer Enabled
Check for XenServer updates Enabled
Check for new XenCenter versions Enabled
- 33 -
11. Backup and Recovery
This section describes the backup and recovery requirements for the XenServer environment including
XenServer host backup, Resource Pool requirements, snapshotting, and guest virtual machine metadata.
Backup and recovery procedures and technologies implemented are also defined to ensure the
XenServer environment is protected.
11.1 Description
• XenServer Host Backup. The XenServer host configuration data specific to the host is
required for a stand-alone server recovery process.
• Resource Pool Backup. A backup of pool meta-data using command line tools is
possible; however this is a manual process. Individual storage repositories can be restored
to new pools if portable SR’s are used, this process can be automated.
• Exporting/Importing Virtual Machines. A complete copy of a virtual machine including
disk images can be stored in a single file for backup or for migration purposes, with a .xva
file extension
• Portable Storage Repository. A Portable SR is a Local, NFS, FC or ISCSI based storage
repository which contains all of the information necessary to recreate all the guest virtual
machines with Virtual Disk Image (VDIs) in the XenServer environment.
• Virtual Machine Backup. Although Virtual Machine virtual disk (VDI) data and
configuration meta-data can be backed up as part of a XenServer backup process, the
application data on each guest also needs to be backed up. Traditional backup practices
can be followed for each virtual workload but the impact of backing up multiple workloads
on a single standalone host needs to be quantified.
11.2 Key Decisions

Backup Symantec
Software NetBackup
version….
Backup Media Backup to Disk
Used then to Tape
Frequency Monthly
XenServer Host
Backup
Frequency of Weekly
Pool Data
Backup
Frequency of Weekly
VM Backups
Frequency of File data is backed
Data Backups up using Agent
based backups
using tape media
File Server for FNP01.domain
VM Export
File Share for \\FNP01\VMExport
VM Exports
- 34 -
SAN Replication FC backed LUNS
are replicated
using EMC SRM
VM Cloning or Crash consistent
Snapshotting backups of VMs
using SAN level
cloning is
performed
Frequency of Every 3 months
Data
Restorations
Disaster No DR plan at this
Recovery Plan stage
Hardware HP 24/7 Support
Support Agreement
11.3 XenServer Host Backup

The section below details the configuration details of the XenServer backup and associated
schedule.
Configuration Value
Backup Server
Backup File path
Backup Frequency
11.4 Virtual Machine Metadata Backup

XenServer hosts use a per-host database to store metadata about VMs and associated resources
such as storage and networking. When combined with storage repositories, this database forms
the complete view of all VMs available across the pool. When a metadata backup is first taken, a
special backup VDI is created on a SR. This VDI has an ext3 file-system which stores the following
versioned backups:
• A full pool-database backup.
• Individual VM metadata backups, partitioned by the SRs in which the VM has disks.
• SR-level metadata which can be used to recreate the SR description when the storage is
reattached.
Configuration Value
Backup Schedule Daily
Weekly
Monthly
Never
Backup Storage Repository Location Local Storage
Shared Storage
- 35 -
Configuration Value
Portable Storage Repository Local
NFS
iSCSI
FC
VDI_Backup_SR
Portable Storage Repository Type iSCSI LUN at 100GB replicated
to DR site
Protected Virtual Machines All VMs
11.5 Virtual Machine Backup

The section below defines the backup configuration for Virtual Machines and the file data residing
within the guest operating systems.
Configuration Value
File Data Backup Type Synthetic full agent based
backup using Symantec
NetBackup Client
Full Virtual Machine Backup Crash-consistent VM snapshot
using…
Virtual Machine Snapshots NetApp FAS3020 snapshotting

at the array level
Backup Vendor Symantec for file-based
backups
NetApp for VM snapshots
Backup Schedule Weekly
Protected Virtual Machines All VMs are backed up of a
regular basis
11.6 Virtual Machine Snapshots

XenServer 5.0.0 provides a convenient snapshotting mechanism that can take a snapshot of a
VM's storage and metadata at a given time provided the underlying Virtual Disk Image Storage
Repository is based on NFS, NetApp or Dell EqualLogic storage. There are tow type of snapshots
which can be used:
• Regular Snapshots. These snapshots are crash consistent and can be performed on all
types of VMs including Linux
• Quiesced Snapshots. These snapshots take advantage of the Windows Volume Shadow
Service (VSS) for services that support it to allow the application to flush data to disk prior
to taking a snapshot. As a requirement, the Citrix Tools for Virtual Machines need to be
installed on the VM.
- 36 -
Configuration Value
NetApp
EqualLogic
Citrix Tools for VMs Installed on all guest VMs
VM Operating System Types Windows Exchange 2003
Microsoft VSS Supported by guest application
Number of snapshot to maintain 7 daily rotating snapshots with 1
weekly snapshot
11.7 Disaster Recovery

Provide details of the DR plan if it exists. Elaborate on how the backup and recovery process would
be conducted including but not limited to the following items:
Portable SRs for full VM metadata and pool copy combined with VDI backup
Export and Import of VMs as a DR plan
SAN replication to DR site – how is this replicated, replication schedules, length of replication, RPO
and RTOs, which LUNs are replicated
DR Recovery process – defines the step-by-step recovery scenario
DR testing procedures
- 37 -
Virtual Machines
- 38 -
12. Virtual Machine Design
The Virtual Machine section defines the guest virtual machines which will be hosted in the XenServer
infrastructure. Within this section, characteristics of the virtual machines, including virtual hardware
configuration, template configuration, home server settings, high availability protection levels and P2V
methodology are discussed.
12.1 Description
Guest virtual machine configuration from a CPU, memory, disk and network perspective should be
correctly sized in line with the existing standard operating environment, intended machine usage,
and operating system requirements. Virtual machine templates can facilitate rapid deployment of
new guests by leveraging predefined and optimized settings.
12.2 Key Decisions

Type of VMs Desktop and
Hosted Servers
Total Number of 120 VMs in total
VMs
VM Operating Windows XP Pro
Systems SP2 and SP3
Windows 2003 R2
No Linux VMs
installed
VM Deployment Installed using
Strategy ISO then
converted to a
template
VM Guest Microsoft SysPrep
Operating
System
Initialization
Virtual CPU All VMs will have
Configuration default vCPU
priority settings
Virtual Memory 512MB for
Configuration Desktops
1024MB for
Servers
VM All VMs will have
Optimization general Use
Setting optimization
settings. No
XenApp servers
deployed.
- 39 -
Boot Order All VMs will default
boot from
DVDROM.
The following
desktop VMs will
be streamed with
PVS and will
default boot from
Network….
Virtual NIC
Configuration
Virtual Disk
Image
Configuration
Home Server
Setting
HA Protection
Configuration
Configured Virtual
Machine
Templates
Default NTP Sync all VM time
Server with
DC1.domain.local
Alert Desktop VMs will
Configuration be configured with
CPU….
Network….
Disk…..
Server VMs will be

configured with…..
P2V (Physical-to- Citrix XenConvert

Virtual) PlateSpin
Conversion Tools PowerConvert
Machines The following
identified for P2V servers will be
Migration P2V migrated:
APP01
APP02
12.3 Design
The XenServer infrastructure will support up to…..
All VMs will be based on Windows…..
The default VM configuration is based on …..
- 40 -
HA protection levels for desktops and servers …..
Alerts settings will be……
12.4 Virtual Machine Configuration

The table below illustrates the default virtual machine configuration.
Configuration Item Desktops Servers
Number of vCPUs 1 1
vMemory 512MB 1024MB
Number of vNICs 1 1
Virtual Disk Size 10GB 40GB
DVDROM Empty Empty
Host Network prod_lan prod_lan
NTP Server DC1.domain.local DC1.domain.local
Operating System Windows XP Pro Windows Server 2003
R2
Citrix Tools for Virtual Installed Installed
Machines
Microsoft VSS Driver No Yes
Enabled
12.5 Virtual Machine Templates

A template is a virtual machine encapsulated into a file. Each template contains installation
metadata and the setup information needed to create a new VM with a specific guest operating
system, and with the optimum storage, CPU, memory and virtual network configuration. Templates
make it possible to rapidly deploy new virtual machines in XenCenter. The following section details
the configuration settings of the templates that will be implemented in the XenServer environment.
Hardware Template 1 Template 2 Template n
General
Name GoldXPDesktop
Description Template XP
Operating System XP Pro SP3
Application Installed Office 2003
Function Desktop SOE
XenServer Tools Installed Yes
Virtual Storage
CD/DVD-ROM Disabled
Virtual Disk Name XP1
Virtual Disk Size 10GB
Virtual Network Interfaces
Number of Virtual NICs 1
Host Network prod_lan
IP Settings DHCP
Network Limit NA
- 41 -
Hardware Template 1 Template 2 Template n
Virtual Memory and CPU
Settings
Virtual Memory 512MB
Number of Virtual CPUs 1
Virtual CPU Priority NA
Startup Options
Boot Order Network
DVD-Drive
Hard Disk
Auto-start VM on server boot No
Alerts Configuration
CPU Usage Alerts
Network Usage Alerts
Disk Usage Alerts
Optimization
Optimization Type General Use
Shadow Memory Multiplier NA
High Availability
HA Protection Level Protected
Priority 1, 2 or 3
Best Effort
Do No Restart
Additional Configuration
Customizations
12.6 Virtual Machine HA Configuration

The table below defines the HA protection levels for the guest virtual machines in the XenServer
infrastructure.
Resource HA Protection Level
Pool
Protected: Protected: Protected: Best Effort Do Not Restart
Priority 1 Priority 2 Priority 3
Pool 1 DC1 SQL1 WEB1 XP1 Al other servers
DNS1 WEB1 APP1 XP2
Exchange1 …..etc
Pool 2
Pool 3
12.7 Workload Migration Process

The Workload Conversion is the process by which an existing operating system on a physical or
virtual machine - its file system, configuration is cast into a virtualized instance of the same
operating system and file system, transferred, instantiated, and started as a VM on the XenServer
Host.
- 42 -
There are many methods which can be employed to perform a workload migration; these are
detailed as follows:
• Manual Migration. This migration type would typically be used if there were very few
migrations to be performed, making the purchase or use of an automated migration tool
unnecessary. This option might also be taken for advanced migrations of physical
workloads with complex requirements such as bespoke option cards, peripherals or
extremely complex storage requirements.
Advantages:
o Optimization. Workloads are ‘refreshed’. All unnecessary application data
(temporary files and log files etc) is removed, workload is optimized.
o Rationalization. This can be taken as an opportunity to rationalize and simplify the
workload configuration, such as disk structure and storage requirements.
Disadvantages:
o Speed. A manual process is very time consuming and best suited to small or
complex migrations.
o Consistency. For a large number of migrations, maintaining consistency can be
challenging when migration tasks are managed manually.
o Reliability. Inconsistent or badly managed migrations can cause application
inconsistency and reliability issues following the migration.
• Physical to Virtual (P2V). Physical to Virtual migrations are typically undertaken using
bespoke migration tools which integrate closely with the virtualization platform to deliver
fast and consistent results.
Advantages:
o Speed. Once the parameters for the migration are supplied it proceeds
automatically. Many P2V migrations can be performed in the time it would take to
complete a single manual migration. For large scale migrations, a P2V process is
the only rational option.
o Integration. Most P2V tools integrate closely with the virtualization platform being
used ensuring that virtual workload optimizations, such as the installation of
relevant paravirtualization tools, forms part of the migration process.
o Consistency. As P2V migrations are parameter based, similar servers will always
be built consistently.
Disadvantages:
o Toolset. A P2V tool must be identified, tested and selected. The tool must support
the virtualization platform being used and be capable of handling the majority of
the physical workloads to be migrated. All relevant staff must be trained in the use
of the new toolset.
o Consistency. Unless closely managed, subtle problems can be quickly introduced
into large numbers of newly migrated workload. Application owners must be
involved in the migration process to be sure that such changes are identified
before each workload is released into production.
• Physical to Physical (P2P). Where P2V tools do not exist or do not work for the current
virtualization platform, a Physical to Physical, or P2P migration can be ‘emulated’ to
achieve a similar result. For example, a virtual server is created which is used to emulate
- 43 -
the destination physical server, the migration is then performed as though both source and
destination hosts are physical.
Advantages:
o Speed/Consistency/Repeatability. Most of the advantages are similar to a P2V
migration.
Disadvantages:
o Integration. As the destination host is perceived to be a physical server, none of
the optimizations are performed which would normally be done on a destination
host which is a virtual machine.
The key to a successful migration strategy is in understanding in fine detail the physical estate
which needs to be migrated, as detailed above. Once the requirements of the workloads are
understood it is easier to identify the best toolset and process to use migrating each environment.
If a third party toolset is to be used, time should be invested in analyzing and understanding that it
meets a large percentage of the migration requirements of the physical infrastructure.
[Describe the P2V process and how each of the VMs targeted for P2V will be migrated using the
P2V tool specified ….]
- 44 -
13. Workload Matrix
This section details the planned desktop and server workloads that will be hosted as guest virtual
machine on the XenServer infrastructure. Information gathered as a result of the Citrix Server
Virtualization Assessment, if it was conducted, will also be discussed.
13.1 Description
Individual server capacity and aggregated Resource Pool capacity with respect to virtual machine
utilisation should be considered as part of the hosting infrastructure design to ensure the
environment and servers are not overcommitted. This is critical in maintaining an acceptable level
of end user experience and virtual machine performance. In any cases, additional server resource
should be deployed as best practice to provide as buffer for unexpected utilisation peaks or server
failures.
13.2 Key Decisions

Expected VM 120 VMs
capacity
Number of 80 desktop VMs
Guest Desktop
VMs
Number of 40 server VMs
Guest Server
VMs
Citrix SVA No
Conducted
Expected Host 60% CPU and
Utilisation Memory utilisation
Acceptable Up to 2 XenServer
Number of Host host failures can
Failures be sustained
XenServer Scale-out.
Scalability Additional hosts
Model will be added to
the pool to
increase VM
density.
13.3 Citrix Server Virtualization Assessment (SVA)

The SVA results indicate the following ……
Based on the SVA results, a total of X XenServers will be required to support y number of VMs
The infrastructure is capable of sustaining two XenServer failures…..
- 45 -
13.4 Desktop Workload
The following table is the expected virtual desktop and virtual server workload that will be hosted
on the XenServer Resource Pool consisting of XenServers based on SERVER HARDWARE
MODEL servers.
Resource XenServer Resource Type of # Guest Guest VMs Comments
Pool Host Pool Role Guest VMs
Name VMs
- 46 -
Security
- 47 -
14. Security
This section discusses the security related aspects of the XenServer design. Physical server security,
along with encryption and enclave networking are analyzed.
14.1 Description
Corporate security policy should already provide guidelines which dictate how each tier of the
XenServer architecture is secured. The design process should follow these corporate guidelines
and make recommendations regarding how the XenServer design can meet these security
requirements.
The following topics are considered during the design process:
• Physical Server Security. Citrix XenServers should be deployed in a secure location
where only controlled access is permitted. As each XenServer will typically host several
virtual workloads, compromise of a single system can result in outage for many business
systems.
• Hypervisor Security. The XenServer hypervisor is not generally prone to attack. If the
servers are deployed on internal networks, there is very little likelihood of compromise at
this level.
• Dom0 Password. Dom0 is the first VM created on every XenServer and enables
management of all other VM’s. Dom0 passwords should be secured at the highest level, as
the root account and password, or equivalent root level accounts, must be used for both
console and XenServer access
• XenCenter. XenCenter is used to manage most aspects of a XenServer deployment.
Restricting access to the Dom0 password will reduce the risk of unauthorized personnel
from running and connecting via the XenCenter console. By default XenCenter uses SSL
to encrypt all communications with each resource pool.
• Virtual Machine Security. Security of virtual workloads can be implemented using
traditional methods such as leveraging the security features of Active Directory and using
standard anti-virus, anti-spyware and firewall software.
• Storage Security. Security for storage should be given serious thought as compromise of
a storage repository could result in the corruption or deletion of its contents and the
subsequent failure of all virtual workloads which share the SR.
14.2 Key Decisions

Physical Server All servers will be
Security located in a
secure data centre
with restricted
access.
Resource Pool Root password for
(Dom0) all servers will be
passwords given only to
support personnel
with specific
requirements.
- 48 -
Storage Security CompanyABC will
use FC-SAN
shared storage
and will use
standard zoning
and masking to
provide basic
security.
Virtual Machine All virtual
Security workloads are
Windows servers
which are AD
domain members.
XenCenter No restrictions will
be placed on
access to
XenCenter
14.3 Design
- 49 -
Appendices
- 50 -
15. Appendix A: XenServer Networking Explained
This section details the XenServer Networking and provides insights into each network type that can be
used in a XenServer implementation.
15.1 Internal Networks

The simplest network configuration is an internal network. No PIF is required as there is no logical
connection to a physical network adapter and therefore no external connectivity. This network is
only available to a single XenServer host and cannot be assigned to other pooled hosts. VM’s
which are connected to internal only networks cannot be migrated between pooled hosts. VM’s on
a common XenServer can share this type of network in order to isolate specific traffic.
15.2 External Networks

The creation of an external network which uses a physical adapter will create the necessary PIF’s
required. In this example, two VM’s each with their own VIF are attached to the same virtual switch
which in turn is logically connected to the PIF, and therefore the physical network adapter:
Here multiple physical network interfaces are present, more complex virtual networking is possible.
In this example, two physical network cards are available. One VM makes use of a single virtual
network, whilst the other is logically connected to two separate network segments.
- 51 -
15.3 Bonded Interfaces
The next example shows the introduction of a network bond. Two physical network cards which are
connected to the same network segment are used to create a bond for resilience and additional
throughput. In the example, two VM’s are connected to the same network segment via this bond.
15.4 VLAN’s
Finally, VLAN’s are introduced which subsume the network bond. Separate vSwitches are created
for each VLAN and in the following example; three VM’s are logically connected to separate
VLAN’s via the same physical network card.
- 52 -
15.5 Virtual Network Combinations
Many combinations of the above examples are possible in order to achieve a configuration which
meets with the requirements of the design.
This example shows a XenServer with 3 NIC’s, eth0 and eth1 are bonded for resilience and this
bonded network is used by 5 virtual machines, three of them attach to different VLAN’s which
leverage the bond for resilience and a further two attach directly to the bond itself.
A third NIC, seen by XenServer as eth2 provides a non-resilient network which is used by a fifth,
single virtual machine.
- 53 -

Client - Name Project - Name: Citrix® Xenserver™ 5 Design

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Client - Name Project - Name: Citrix® Xenserver™ 5 Design

Uploaded by

Copyright:

Available Formats

<Client Logo>

[Insert Date, 2008]

All text written in orange should be removed. Orange is used to provide

Before you are finished, please double check:

1.2 Deliverable Overview

Citrix XenServer 5.0 Design

1.4 PartnerABC Resources

1.5 Next Steps

2.2 Design Summary

2.3 Design Concerns

3.2 Key Decisions

3.4 XenServer Host Parameters

4.2 Key Decisions

4.4 Resource Pool Design

The following section defines the settings for Resource Pool 2.

5.2 Key Decisions

HA has been configured….

5.4 XenMotion Configuration

5.5 High Availability Configuration

Priority Level: 1, 2 and 3

The four VDI Types can be defined as follows:

VHD files are sparse and extended in 2Mb chunks.

VHD files can also be chained.

6.5 Boot Storage Configuration

Configuration Option Value

Configuration Option Value

Configuration Option Value

Configuration Option Value

Configuration Option Value

6.7 ISO Library Configuration

Configuration Option Value

7.5 Physical NIC Configuration

7.6 Management Interface Configuration

7.7 Host Networks

7.9 Network Communications

[Insert Visio diagram detailing network communications and associated ports]

8.2 Key Decisions

8.4 Server Hardware Configuration

Refer to Visio diagram

8.5 Aggregated Capacity

9.2 Key Decisions

10.2 Key Decisions

10.4 XenCenter Hardware Requirements

10.6 Email Notification Settings

10.7 XenServer System Alert Configuration

10.8 Custom Fields, Searching and Tagging

Add list of custom fields here…

10.9 Software Updates

11.2 Key Decisions

11.3 XenServer Host Backup

11.4 Virtual Machine Metadata Backup

11.5 Virtual Machine Backup

Virtual Machine Snapshots NetApp FAS3020 snapshotting

11.6 Virtual Machine Snapshots

11.7 Disaster Recovery

12.2 Key Decisions

Server VMs will be

P2V (Physical-to- Citrix XenConvert

12.4 Virtual Machine Configuration

12.5 Virtual Machine Templates

12.6 Virtual Machine HA Configuration

12.7 Workload Migration Process