Virtu ualizat tion aand thhe PI S

V
N
Syste
Version
November 2

em
1.2
2010

OSIsoft, Inc.
777 Davis St., Suite 250
San Leandro, CA 94577 USA
(01) 510-297-5800 (main phone)
(01) 510-357-8136 (fax)
(01) 510-297-5828 (support phone)
http://techsupport.osisoft.com
techsupport@osisoft.com
Houston, TX
J ohnson City, TN
Longview, TX
Mayfield Heights, OH
Philadelphia, PA
Phoenix, AZ
Savannah, GA
Seattle, WA
Yardley, PA


OSIsoft Australia
Perth, Australia
Auckland, New Zealand
OSI Software GmbH
Altenstadt, Germany
OSI Software Asia Pte Ltd.
Singapore
OSIsoft Canada ULC
Montreal, Canada
Calgary, Canada
OSIsoft, Inc. Representative Office
Shanghai, Peoples Republic of China
OSIsoft Japan KK
Tokyo, J apan
OSIsoft Mexico S. De R.L. De C.V.
Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda.
Sao Paulo, Brazil

Sales Outlets/Distributors

Middle East/North Africa
Republic of South Africa
Russia/Central Asia
South America/Caribbean
Southeast Asia
South Korea Taiwan
www.osisoft.com
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any formor by any means,
mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, Inc.

OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, Sigmafine, Analysis Framework, IT Monitor,
MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Manual Logger, PI ProfileView, ProTRAQ,
RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, Inc. All other trademarks or trade
names used herein are the property of their respective owners.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013
Published: 4.10.2009



Contents
Virtualizing PI .............................................................................................................................. 4
Best Practices ............................................................................................................................. 6
Not Recommended ................................................................................................................................. 6
Virtualization on a PI Server ............................................................................................................ 6
Recommended Architectures ................................................................................................................. 7
PI System on a Single Virtualization Host........................................................................................ 7
PI System on Multiple Virtualization Hosts ...................................................................................... 8
Processor ................................................................................................................................................ 9
Disk .................................................................................................................................................... 9
Memory ................................................................................................................................................. 10
Networking ............................................................................................................................................ 10
Configuration and Fault Tolerance ....................................................................................................... 11
Figure 1 .......................................................................................................................................... 12
Product Specific Recommendations ...................................................................................... 13
References ................................................................................................................................. 17

Best Practices
1
Virtualizing PI
OSIsoft supports the virtualization of the PI System on the enterprise class virtualization platforms of
Microsoft Hyper-V and VMWare ESX Server. A PI System that is sized using the PI Server Installation
and Upgrade Guide and Hardware and System Sizing Recommendations Spreadsheet will operate
within a virtualized platform when using the recommended configurations. The recommended
virtualization configurations are:
PI Server and additional PI System components running on a single virtualization host.

NOTE: A single virtualization host is a single point of failure; if the host is non-functional or
problematic, data may not be available or buffered, resulting in lost data


PI Server and additional PI System components running across multiple virtualization hosts

Virtualization and the PI System
2
In addition to the recommended architectures, there are five core principles that should be adhered to
when implementing the PI System on a virtualized platform.
Principle 1 A Virtual Machine is just another brand of machine
The sizing of the PI System on a virtual or physical implementation must adhere to the sizing
requirements for CPU, memory, disk, and network.

Principle 2 Enterprise solutions must use enterprise class virtualization and hardware
When virtualizing the PI System, only the use of enterprise class virtualization products and enterprise
class server and SAN hardware should be used. Enterprise class virtualization products include Microsoft
Hyper-V and VMWare ESX. Other virtualization products may be used for test and development
environments, but not for production.

Principle 3 Do not mix virtual and physical implementations on the same host.
PI System components should not be installed on the host system that is running a virtualization platform.
For the implementation, applications should only be run within the virtual machines and not on the host
as applications running on the host system may use resources that are needed by the virtual machines.

Principle 4 Ensure qualified support of the virtual environment
IT/Server support personnel should be properly trained in maintaining and managing virtualization
platforms. OSIsoft supports the PI System, not the platform upon which it is installed.

Principle 5 Testing of the PI System on a physical and virtual platform using custom configuration
should be completed
There are varying degrees of performance deltas between a physical and virtual implementation. These
variances depend upon the type of applications installed, configurations of the application, and the
workload. Prior to a virtualized implementation, a test to determine the delta between a virtualized and
physical implementation using the custom configuration should be completed to understand the
performance deltas. Microsoft provides best practices for running MS SQL Server 2008 on a Hyper-V
environment and these fundamentals for testing may be applied to test practices for PI Systems.









Best Practices
3
Best Practices
There are several factors that must be considered when building a PI system on a physical or virtual
environment. The hardware, whether physical or virtual, that is required for the system is dependent on
many variables. The accumulation of these variables determines the processor, disk, memory, and
network configuration necessary for a well performing PI system. In addition to the hardware
requirements, a highly available system adds another layer of complexity in determining a virtualization
strategy. All of these factors are used to determine the total system architecture.
The following information provides a guide to determining an appropriate approach for virtualization of a
PI System. It should be noted that all PI System components are capable of being virtualized; however,
each component should be individually considered for virtualization as it delivers a specific function to
the whole PI System.
All OSIsoft products should be sized in accordance with the recommendations in the installation
documents prior to determining a virtualization strategy. A PI Server has some particular
recommendations regarding sizing which can be found in the PI Server Installation and Upgrade Guide
document. This document can be found at the following URL:
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/documentation/streamfiles.
aspx?file_id=1c0ec4c0-d9fb-4a8c-80f1-d21da2d0d5b0.
All of the recommendations included in the document apply to individual, physical PI Servers and those
that are being virtualized.
Additional information for sizing may be found in the Hardware and System Sizing Recommendations
Spreadsheet located at the following URL:
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/downloadcenter.aspx?down
load_file=8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7
System performance is key when designing a PI System and the resultant sizing of the system may then
be placed on a virtualization platform. There are three (3) general approaches to virtualization of the PI
System, of which one (1) is not recommended and two (2) are recommended.
Not Recommended
Virtualization on a PI Server
The first approach is to install the PI Server on a physical server and then install the virtualization
software within the same operating system. The additional PI System components (e.g. interfaces, ACE
server, etc.) are subsequently installed as guests within the virtualization host running on the PI Server.
This implementation method for virtualization is not recommended because:
The design puts unnecessary processor and memory strains on the single physical server
o Inability to configure the PI Server resources (CPU and memory); resources constrained
or split only by what has been allocated to the virtualization guests
o Inability to manage the local and virtualized resources independently
A single point of failure; if the PI Server experiences issues, the operating system supporting the
PI Server cannot be rebooted without shutting down the virtualized PI System components that
are running as virtualization guests

Virtualization and the PI System
4
The performance and single point of failure issues outweigh the benefits received by virtualizing the
additional PI System components on the PI Server; this configuration is NOT RECOMMENDED.

Recommended Architectures
The recommended architectures achieve scalability, reliability, and efficiency through virtualization.
PI System on a Single Virtualization Host
The second design is to use a single virtualization host with PI Server and PI System components running
within their own virtualization guests.
Pros:
Reduced hardware cost to a single server
Each PI component within their own virtualization guest isolates processes from each other
Cons:
Single hardware point of failure
Best Practices
5

PI System on Multiple Virtualization Hosts
The final approach is to use multiple virtualization hosts and load the PI System components across the
hosts. The performance of the PI Server will be least likely impacted by loading no additional or only
low resource consuming PI System components on the virtualization host that is hosting the PI Server
virtualization guest.
Pros:
PI Server may be isolated from any virtualization guests; performance of PI Server is not directly
impacted
Reduced hardware costs to two servers
Increased fault tolerance through multiple virtualization hosts (additional software or licensing
may be required for automatic fault tolerance)
Cons:
Additional hardware required for additional virtualization hosts
Virtualization and the PI System
6

Processor
The processor requirements for a virtualized system will need to be the same as or greater than a physical
system when using a virtualized system. During the configuration of the guest machine, the system
hardware settings are stored in the hypervisor configuration. The configuration for the virtualization host
will determine the quantity of processors as well as the total allowable percent of utilization that the guest
may use. In the case where the processor(s) may be shared across multiple virtualization guests, the total
configured processors allocated to the PI System guest will need to meet or exceed the physical hardware
requirements to ensure that the necessary processing capability is available to the PI system.
For example, in a physical system with 200,000 points there is a requirement for a minimum of two (2)
processors running at 2.93 GHz. If the system is virtualized and there are four (4) processors running at
2.93 GHz on the virtualization host, an allocation of 50% utilization across all four processors for the PI
System virtualized guest will be approximately equal to the physical configuration requirements.
As an alternative to a percent processing capacity allocation, a processor may be isolated to a specific
guest. With this configuration, the need to allocate a part of a processor resource capacity is no longer
required. As with a percentage of processing capacity, the same or equivalent process capability required
of the physical implementations must be allocated in the entire processor allocation method. The
downside to allocating an entire processor in the configuration, is that, in the event the resource
requirement for the PI System guest is low, the processor resources may not be allocated or shared to
other virtualized guest systems and an over allocated, underutilized host system may result.
Disk
The disk requirements for the virtualized PI System have the same sizing requirements as a physical PI
system. The keys to building an efficient PI System in a virtual environment depends on the virtual
technology being implemented; however, there are some universal principles that will help in determining
the disk requirements.
First, the type of disk to be implemented for the guest must be decided upon. Both platforms support
fixed and dynamic disk configurations. A fixed disk is a predefined and pre-allocated physical partition
that is created on the connected volume for the virtual machine. A dynamic disk is predefined, but the
total partition size is not pre-allocated on the volume. As the data requirements grow for the partition, the
partition will grow up to the maximum pre-allocated size. In general, fixed disks perform better than
Best Practices
7
dynamic disks due to the additional overhead required for dynamic disks to be able to expand as
necessary. Therefore, it is better to select a fixed disk over a dynamic disk.
Second, an important factor to consider is the logical disk layout. The same logical disk layout would be
applied as if it were a physical server. Therefore, if the configuration required a C, D and E
partition, these would also be necessary in the virtual machine.
Next, a decision must be made if those partitions can be part of one virtual disk or multiple virtual disks.
Generally, performance is better if disk I/O is divided into multiple virtual disks and then distributing
those disks among several arrays. However, PI is not a disk intensive application and as such, can be
maintained with success on a single array with a few virtual disks. Normally, it is recommended to
separate the operating system, archive disk and snapshot, and event queues onto 3 separate virtual disks.
The use of multiple partitions is for performance considerations, although many PI Systems run perfectly
with fewer partitions. In addition, an important reason to use multiple virtual disks is to support the
ability to grow each disk individually according to the need and to provide a minimum level of fault
tolerance to each of the systems dependant on the disk.
Finally regarding disk requirements, most organizations will be using a Storage Area Network (SAN) for
supporting the virtual environment. With the virtualization guests systems files residing on the SAN,
there should be SAN switching redundancy, fast and reliable I/O, and an easy disk method for accessing
the files for backup purposes.
Memory
The PI Server is a memory intensive application with frequently accessed data structures being kept in
memory. Memory utilization is directly related to point count with the overall rate as well as the number
of points affecting the amount of memory required. The memory recommendations for a PI Server are
found in the document PI Server Installation Guide which can be found at the following URL:
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/documentation/streamfiles.
aspx?file_id=1c0ec4c0-d9fb-4a8c-80f1-d21da2d0d5b0
Regardless of which component of the PI System is considered, virtualization adds an additional memory
requirement to maintain the virtual machine components. This varies depending on which virtualization
host platform the organization is using. In any case, consider adding additional memory to the virtual
machine for virtual machine management overhead; how much to add will depend on the virtualization
host platform that the organization will deploy; however, a good starting point is to add a minimum of
10% more virtual memory to the guest machine than the organization would have for a physical machine
to account for virtual machine overhead.
Additional information for sizing may be found in the Hardware and System Sizing Recommendations
Spreadsheet located at the following URL:
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/downloadcenter.aspx?down
load_file=8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7
Networking
The networking configuration in a virtual environment is often forgotten. However, getting data in and
out of the virtualization host and guest hosting the virtual application is as important as the memory and
disk environment. Simply stated, the single network adapter environment generally wont be sufficient
for a production virtualization host system. In production virtual environments running the PI System, it
is required that special attention be given to the networking infrastructure and communications design.
In a production virtualization host system, a good rule to follow is to dedicate an adapter to the console,
another adapter to the storage and backup network, and multiple adapters to the guest systems. This
Virtualization and the PI System
8
approach will provide the flexibility to use adapter teaming for load balancing and fault tolerance while
segmenting network I/O for guests to a single adapter or team of adapters to provide the best throughput.
Additionally, make sure the network devices (e.g. switches) that these adapters are connected to are
redundant to create a completely fault tolerant environment from the endpoint to the PI System on the
virtual host.
Configuration and Fault Tolerance
There are several factors to making any system implementation successful and a key factor for most is
providing fault tolerance for highly available, business critical systems. Fault tolerance provides the
ability for a system to continue to function in the event of a hardware or software failure. Without a fault
tolerant implementation, a single component outage may bring down the entire system and application
structure and processes would cease to function.
Figure 1 depicts an example of a fault tolerant configuration of a virtualization host on either the
VMWare or Microsoft platform. There are two virtual machines running on a single virtualization host
server with multiple hardware redundant components. On each virtual machine, there are two network
cards: one connecting to the virtual switch on the guests network and one connecting to the virtual switch
on the storage/backup network. The traffic for the backup processes are isolated from the normal network
traffic by binding the virtual switch for the storage/backup network to an independent physical network
card, Physical NIC 3, on the host. For the normal network traffic, the virtual network switch is teamed to
two physical network cards, Physical NIC 2 and Physical NIC 4, providing fault tolerance and increased
bandwidth. As with the storage/backup configuration, the console connection to the virtualization host
server is connected to an independent physical network card, Physical NIC 1, to isolate the traffic from
the other networks.
For additional fault tolerance, the physical network cards connected to the virtual switch of the guest
network, Physical NIC 2 and Physical NIC 4, are connected to separate production network switches.
Finally, any Logical Unit Numbers used to address the SAN, LUNs, that are connected to the
virtualization host are connected through redundant host bus adapter (HBA) connections. The two
connections will provide volume access in the event of physical card failure of the HBA.
Best Practices
9
Figure 1
Virtualization Host
Host SAN Storage Adapters
Host Network Adapters
Virtualization Hypervisor
Physical
NIC 1
Virtual Switch
Console
Production Network Switch 2
HBA 1
Physical
NIC 2
Physical
NIC 3
HBA 2
Virtual Machine
Virtual Switch
Storage Network -
Backups
Virtual Switch
Guests
OPERATING SYSTEM
APPLICATION
Production SAN Switch 1
Host
CPUs
Host
MEMORY
Host
DISK
Virtual Machine
OPERATING SYSTEM
APPLICATION
Physical
NIC 4
Production Network Switch 1
Production SAN Switch 2


Virtualization and the PI System
10
Product Specific Recommendations
The following table provides virtualization considerations by product. These recommendations are
intended to be a starting point when architecting the virtual environment.
Product Memory Disk CPU Networking
PIServer Planmemoryaccordingtothe
InstallationGuide.Consider
addinganadditional10%of
memoryforVMoverhead.
Usefixeddisks,sized
accordingtothe
recommendationsin
theplanningguide.
SizebyInstallation
GuideorHardware
andSystem
Recommendations.
Considerentire
processor
allocationtoguest.
Considerisolating
networkI/Oto
specificnetwork
cardsintheVM
server.Generally
4networkcards
are
recommended.
PIAF Minimumof1GBofRAM.
Consideraddinganadditional
10%ofmemoryforVM
overhead.
Usefixeddiskswitha
minimumof500GB
freespace.IfSQLwill
beruninthesame
VM,consultthe
MicrosoftSQL
planningguidefor
configuration
recommendationsfor
SQL.
1GHZMinimum,
willbenefitfrom
fasterandmulti
coreCPU.
Considerisolating
networkI/Oto
specificnetwork
cardsintheVM
server.Generally
4networkcards
are
recommended.
PIACE Dependsoninstallation IfACEisinstalled
ontheDataserver
considerusing
multiple
processorsor
multicoreCPUs
IfACEisinstalled
onaclient
machine,add
additional
network
resourcesto
handleI/O.
Interfaces Dependsoninterface
recommendation
Sizediskforbuffering
accordingto
requirements
MinimalCPU Considerisolating
networkI/Oto
specificnetwork
cardsintheVM
server.Generally
4networkcards
are
recommended.
PIHA SubjecttoPIServerMemory
recommendations.
However,itisrecommended
thatPIHAnodesarecreated
onseparateVM
environments.Donotputtwo
PIHAnodes,oranyother
redundantPISystem
components,onthesame
VMHostasdoingsoremoves
faulttolerance.
SubjecttoPIServer
Recommendations
SingleCPU Considerisolating
networkI/Oto
specificnetwork
cardsintheVM
server.Generally
4networkcards
are
recommended.
Virtualization High Availability Strategies vs. PI High Availability
11
Virtualization High Availability Strategies vs. PI High
Availability
Many customers ask: Why do I need PI high availability (PI HA) when Im using a high availability
strategy in my virtual environment? There are a few things to consider when thinking about using a
virtual high availability strategy (Virtual HA) vs. a PI high availability strategy.
Virtual High Availability Strategies all strive for the same common goals regardless of the virtual
platform, they are:
1. Improved Service Levels
2. Improved utilization of computing resources
3. Reduction in the footprint of systems thru better utilization
In contrast, PI high availability has slightly different goals which can complement a virtual high
availability strategy, those goals are:
1. Improved Service Levels
2. Data Duplication
3. Data Availability
A key differentiator between PI high availability and virtual high availability strategies is that PI is
capable of replicating datasets among several servers to provide duplicate data sets that can be used for
client failover. This strategy provides a level of data availability and improved service level when
combined with PI N-way buffering.

PI System Considerations PI High Availability Virtual high availability
Operating System Updates Achieves availability by
providing data redundancy thru a
secondary PI Server during an
update
Does not achieve availability
during the system update cycle
Software Upgrades Achieves availability by
providing PI data redundancy
thru a PI Server secondary node
Does not achieve availability
during the system upgrade cycle
Software Failure Achieves availability by
providing data redundancy thru a
PI Server secondary node no
process data is lost
Has the ability to provide
recoverability during a software
failure via snapshots. This
provides the last known good
configuration but some PI data
will likely be lost.
Hardware Failure Achieves availability by
providing data redundancy thru a
PI Server secondary node
Provides availability thru virtual
high availability by moving the
VM to another VM host

Virtualization and the PI System
12
Hardware Migration Achieves availability by
providing data redundancy thru a
PI Server secondary node
Provides availability thru virtual
high availability by moving the
VM to an alternate host
Network Failure Achieves availability by
providing data redundancy thru a
secondary node, network failures
cause clients to connect to other
nodes
Redundant connections provided
thru virtual high availability or
by moving the VM to an
alternate host
Load Distribution Achieves load distribution thru
multiple servers, data duplication
and client distribution
Achieves load distribution
through virtual host software that
has the ability to migrate the
guest to a host with the required
resources
Class of Service (Users) Users/clients can be assigned to
connect to any server in the
collective providing the ability to
segregate users based on required
service levels. PI HA can also be
used to replicate data across
security zones
Defines class of service by
availability of computing
resources. Through resource
management software virtual
machines migrate to hosts with
available resources.
Geographic Separation Collectives across WAN links
can be configured
Virtual high availability in most
cases cannot be implemented
across WAN links

PI High Availability and Virtual High Availability independent or
complementary?
Many customers consider PI high availability and Virtual high availability mutually exclusive. Certainly
though, they are not and can be used together to create a highly available and scalable PI system.
Customers who already have invested heavily in virtual technologies should consider mixing PI HA and
virtual high availability. This marriage of technologies, blends together to create the best that both have to
offer. The table below outlines the benefits to the PI system by combining PI HA and virtual high
availability:

Considerations PI High Availability Virtual High
Availability
PI HA and Virtual High
Availability
Operating System
Updates
Achieves availability by
providing data
redundancy thru a
secondary PI Server
Does not achieve
availability during the
system update cycle
Combined solution would
use PI HA to provide
availability during an
update
Virtualization High Availability Strategies vs. PI High Availability
13
Software Upgrades Achieves availability by
providing PI data
redundancy thru a PI
Server secondary node
Does not achieve
availability during the
system upgrade cycle
Combined solution would
use PI HA to provide
availability during an
update
Software Failure Achieves availability by
providing data
redundancy thru a PI
Server secondary node
no process data is lost
Has the ability to
provide recoverability
during a software
failure via snapshots.
This provides the last
known good
configuration but
some PI data will likely
be lost.
Provides data availability
thru PI HA secondary
nodes and snapshots thru
virtual high availability
Hardware Failure Achieves availability by
providing data
redundancy thru a PI
Server secondary node
Provides availability
thru virtual high
availability by moving
the VM to another VM
host
Increases the availability
of any PI HA enabled
node without complicated
operating system
clustering. Combined
with PI HA, virtual high
availability can provide
very high levels of uptime
with zero data loss
Hardware Migration Achieves availability by
providing data
redundancy thru a PI
Server secondary node
Provides availability
thru virtual high
availability by moving
the VM to an alternate
host
Utilizing Virtual high
availability simple
hardware migration with
no configuration changes
to PI HA, data is always
available
Network Failure Achieves availability by
providing data
redundancy thru a
secondary node, network
failures cause clients to
connect to other nodes
Redundant connections
provided thru virtual
high availability or by
moving the VM to an
alternate host
Minimizes network
failures as a cause of data
loss thru the use of virtual
networking and PI HA
data duplication
Load Distribution Achieves load
distribution thru multiple
servers, data duplication
and client distribution
Achieves load
distribution thru virtual
host software that has
the ability to migrate
the guest to a host with
the required resources
Combines client affinity
thru PI HA and
computing resource
loading from virtual high
availability to provide
efficient utilization of
computing resources

Virtualization and the PI System
14

Class of Service (Users) Users/clients can be
assigned to connect to
any server in the
collective providing the
ability to segregate users
based on required service
levels. PI HA can also be
used to replicate data
across security zones
Defines class of service
by availability of
computing resources.
Through resource
management software
virtual machines migrate
to hosts with available
resources.
Combines client
affinity thru PI HA
and computing
resource loading
from virtual high
availability to
ensure the quality
of service for users.
Geographic Separation Collectives across WAN
links can be configured
Virtual high availability
in most cases cannot be
implemented across
WAN links
N/A

Virtualization Best Practices
Customers virtualizing production PI Systems should keep in mind the following best practices during
implementation.
Failover Rules
When using PI HA and virtual high availability its important to take time to define how the virtual
environment will handle failover. This is especially important when virtualizing the PI Server collective.
1. Create failover rules that prevent the primary and secondary server from running on the same
physical host. This will ensure that a PI Server is active if one of the host servers fails.
2. Review rules for resource scheduling. Moving PI System virtual machines when they
require additional resources is a good practice; however it would be better to move other
guests from the virtual machine to provide more resources to the PI System. This is an
important strategy when virtualizing interface nodes as the migration process will stop
data collection during the migration.


References
15
References

VMware Configuration Maximums
http://www.vmware.com/pdf/vi3_301_201_config_max.pdf

Microsoft Hyper-V TechNet Library
http://technet.microsoft.com/en-us/library/cc730764.aspx

PI Server Installation and Upgrade Guide
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/documentation/streamfiles.
aspx?file_id=1c0ec4c0-d9fb-4a8c-80f1-d21da2d0d5b0

Hardware and System Sizing Recommendations Spreadsheet
http://techsupport.osisoft.com/techsupport/nontemplates/download%20center/downloadcenter.aspx?down
load_file=8d7f6f38-2ed3-43f3-a7f5-a15789e6bca7

Microsoft Hyper-V Planning and Deployment Guide
http://download.microsoft.com/download/8/1/5/81556693-1f05-494a-8d45-
cdeeb6d735e0/HyperV_Deploy.doc

VMWare Infrastructure 3 Primer
http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_prim.pdf

Running SQL Server 2008 in a Hyper-V Environment Best Practices and Considerations
http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-
5bfcf076d9b9/SQL2008inHyperV2008.docx