P2V Consideration and Pre-Post Migration Checklist

Candidate selection:

Use capacity tools (Capacity Planner for ex.) to qualify a physical server as a P2V candidate, some points to note:

  • Small to medium sized workloads which use less SpecInt are the best fit for Virtualization, the SpecInt can eventually increase with the influx of new hardware which has increased CPU speeds. But most of the applications are not CPU intensive
  • Check the memory utilization at 95th Percentile, Memory allocation can be huge, more than 30+ GB, but keep a check on Active Memory, which is always the key
  • Average Disk Read/Write at the 95th percentile should not be way too high, benchmarks are set within the organization depending on their bandwidth and usage, same goes with network
  • It’s the Storage Protocol which dictates your disk space requirements, SAN can be an expensive deal, but worth looking at Thin provisioning (NFS) if there are large disk space requirements with low “Disk Usage”
  • Set benchmarks for OS drives, only if your applications and DB reside on Data volume
  • Application which does not have low latency requirements
  • Can be anything, Exchange, SQL, Oracle, SAP or any business critical application as long as it gets the required resources

Some showstoppers which might prevent candidate selection:

  • Applications with low latency
  • Very large workloads and large data sets
  • Non Standard hardware requirements, modems, fax cards, dongles etc

Pre Migration Checks:

  • Use Capacity tools to qualify a physical server as a P2V candidate, preferably Capacity Planner
  • Hostname
  • OS Type
  • Server Model
  • # of CPU sockets and Cores
  • Physical memory installed
  • Disk Capacity requirements, any LUNS from FC or SCSI or NFS mount points (CIFS)
  • CPU, Memory and Disk usage (Capacity tools can give an insight)
  • Decide on vCPU’s, Virtual Memory and Disk space to be allocated
  • It’s always good to have a local Administrator account on the physical box prior to P2V, else login atleast once using your domain credentials so that it’s stored in the local SAM
  • Record the IP configuration, possibly a screen dump of ipconfig
  • iLO information
  • Check for disk defragmentation
  • Check whether the applications are hardcoded to any IP/Mac addresses
  • RDP access
  • Information about all the applications and check which services are required to be stopped during migration
  • Possibly a runbook, which provides an update on the milestone, P2V started, in progress, successful or failed etc
  • On board resources from OS and Application teams, their contact information
  • Ensure there are no Hardware dongles, take note of compatibility, else the effort is wasted
  • Ensure the firewall rules are opened for the destination network, if applicable
  • Ensure your ESX/ESXi host’s management port group is connected to atleast 1GB port

Post Migration Checklist:

  • Ensure to power off the physical server before powering on the VM, else ensure the Network Adapter is disabled on the VM
  • Install VMware tools and ensure the Hardware Version is compliant with the ESX/ESXi version
  • Removed unwanted serial ports and uninstall all the Hardware Services, HP Insight Manager etc
  • Ensure there are no yellow exclamation marks in the Device Manager
  • Check and Adjust the Hardware Abstraction Layer, if required
  • Once the server is powered on, enable the NIC and assign the IP address
  • Start up all the disabled Application services if any, also check all the Automatic Services are started
  • Ensure the Physical Server is no longer pingable in the network, else you may run into Duplicate entries in AD
  • Get your OS teams (Check Windows Events log) and Application team for stress testing
  • Test Network and Disk latency
  • Most importantly “User Experience”

Please feel free to add if I have missed anything critical

Oracle Design Best Practices on vSphere

Let me start with some general considerations while deploying Oracle on vSphere

  • Do not install any software components that aren’t necessary, such as Office Suites, Graphics, Sound & Video Programs and Instant Messaging services
  • It is also recommended to disable some unnecessary foreground and background host processes
  • For Linux, anacron, apmd, atd, autofs, cups, cupsconfig, gpm, isdn, iptables, kudzu, netfs, and portmap
  • For Windows, alerter, automatic updates, clip book, error reporting, help and support, indexing, messenger, netmeeting, remote desktop, and system restore services
  • For Linux installs, the database administrator (DBA) should request that the system administrator compile a monolithic kernel, which will only load the necessary features


  • Oracle databases are not usually heavy CPU consumers and therefore are not characterized as CPU-bound applications
  • As always start with less number of vCPU’s and then increase the count depending on the workload
  • Enable Hyper Threading for Intel Core i7 Processors
  • Use %RUN, %RDY & %CSTP metrics to determine CPU performance


  • Set memory reservations equal to the size of the Oracle SGA, atleast for Production systems
  • Acceptable to introduce more aggressive over-commitment in non-production environments such as development, test, and QA etc
  • Set the Virtual Machine to Automatic selection of CPU/MMU Virtualization option
  • Use Large Memory pages, enabled by default on ESX 3.5 and later


  • Oracle is not heavy when it comes to network utilization
  • Use separate virtual switches, with each switch connected to its own physical network adapter to avoid contention between the ESX service console (applicable for 4.1 and earlier), the VMkernel, and virtual machines (especially virtual machines running heavy networking workloads).
  • To establish a network connection between two virtual machines that reside on the same ESX/ESXi host, connect both virtual machines to the same virtual switch. If the virtual machines are connected to different virtual switches, traffic will go through wire and incur unnecessary CPU and network overhead
  • Use the VMXNET network adapter for optimal performance
  • For IP based storage, enable Jumbo frames end to end


  • A dedicated LUN for DB VM’s if the applications have a demanding I/O profile
  • Use VMFS for Single Instance Oracle DB
  • Make sure the VMFS is aligned properly, create the VMFS partitions using vCenter
  • Use Oracle Automatic Storage Management, preferably ASM disk groups with equal disk types and geometries. At a minimum, create two ASM disk groups; one for log files, which are sequential in nature; and one for datafiles, which are random in nature
  • Create a primary controller for use with a disk that will host the system software (boot disk) and a separate PVSCSI controller for the disk that will store the Oracle data files