HP Virtual Server Environment: Tips for Application Developers

Memory Migration
Memory migration is a new feature of 11i v3. At first release memory can be removed from or
added to (hence migrated between) vPars. The first release of Integrity VM after 11i v3 will also
include support for adding or removing memory from an Integrity VM guest OS. On a vPar, memory
can be allocated as Interleaved Memory (ILM) or Cell Local Memory (CLM), and specific memory
ranges can be added or deleted. Memory can also be specified as “base”, which cannot be
removed, or “floating”, which can be removed. This means that application developers have new
opportunities to take advantage of increased memory during peak loads, and to release memory for
other applications (and other OS instances) when not needed. Again, as with all other VSE
capabilities, applications will continue to work correctly, unchanged, in an environment with memory
migration. These new capabilities are available for use when the application developer and system
administrator choose. Detailed information regarding memory migration in vPars is available in the
vparresources(5) man page. Additional information on usage and best practices will be available in
white papers shortly, search for “Memory Migration” on docs.hp.com.
Effects of VSE on Applications
Some applications may experience performance variations when resources are reallocated and some
may not scale with the addition of new resources. Nonetheless, other than variations in performance,
the applications will still execute as expected.
Performance in a Virtual Server Environment
Before deploying any application in a production environment, a prudent amount of testing should be
done to ensure that the necessary level of performance will be achieved in production. Configuration
choices such as number of cores, size of memory, I/O paths, kernel tunables, accelerator software
and administrative procedures should all be evaluated. The same is true when deploying applications
in a VSE. The application should be exercised across a suitable range of variation (migrate cores,
allocate extra CPU shares, etc) to ensure that the resources available to the application will be
sufficient to meet anticipated loads, and that the application can make use of the additional
resources.
Many applications flex with no issues. Many applications flex well within the range needed in a
production environment. For example, an application may not flex well going from a one core
environment to a 64 core environment, but may flex just fine within a range from 4 cores to 16 cores.
Applications that use large numbers of threads or processes (relative to the number of cores available)
tend to flex very well. Environments that use FSS based resource partitions tend to flex very well.
Environments that involve multiple applications, or multiple separate instances of an application tend
to flex very well.
See Appendix B – “Assessing application performance in a VSE” for a simple procedure to assess
how well a specific application will perform in a VSE.
Compatibility on HP Integrity Virtual Machines
HP Integrity Virtual Machines provide application binary compatibility for HP-UX 11i v2 Itanium native
applications, as long as the application has no device hardware dependencies, or depends only on
devices virtualized by Integrity VM. Integrity VM virtualizes the serial port, SCSI-2 mass storage and
Ethernet networking. Guest storage can reside on a SAN, but the SAN management must be done