Configure vApp Settings in VMware vSphere
Learn how to configure vApp CPU and memory resources, IP allocation, VM startup and shutdown order, and advanced metadata in VMware vSphere.
A vApp is a vSphere container used to group and manage related virtual machines as one application. For example, a database VM, application VM, and web VM can be placed in one vApp so administrators can apply resource, networking, and power-operation settings to the application group.
vApp-level settings provide a consistent management boundary. Instead of configuring every virtual machine independently, you can define resource priorities, reservations, limits, IP allocation behavior, startup dependencies, shutdown behavior, and application metadata for the group.
Before continuing, you should understand how to create a vApp, navigate the vSphere inventory, manage virtual machines, and plan basic application dependencies.
What You Can Configure in a vApp
- CPU resources: Shares, reservations, and limits for the vApp.
- Memory resources: Shares, reservations, and limits for the vApp.
- IP allocation: Fixed, transient through vCenter Server IP pools, or DHCP-based addressing.
- Startup order: Groups of virtual machines, group sequence, and startup delays.
- Shutdown order: The reverse of the startup group sequence.
- Advanced properties: Product information, vendor information, and custom key-value properties.
Open the vApp Configuration Interface
- Sign in to the vSphere Client connected to vCenter Server.
- Locate the vApp in the inventory. Depending on the inventory view, it may be under a datacenter, cluster, host, or resource pool.
- Select the vApp and open its actions menu or context menu.
- Choose the action for editing or configuring settings. The exact label can vary between vSphere versions and client layouts.
- Review the configuration categories in the dialog before changing values.
The available categories generally include resource allocation, IP allocation, startup order, and advanced or application properties. If a category is unavailable, check that you selected the vApp rather than one of its virtual machines and that your account has sufficient permissions.
Configure CPU Resources
CPU controls determine how the vApp competes for processor capacity with other workloads. The controls apply to the vApp as a container; the virtual machines inside it still have their own virtual CPU configurations and may also be affected by cluster, host, or resource-pool settings.
CPU shares
CPU shares are relative priorities used when CPU resources are contested. A vApp with higher shares receives a larger proportion of available CPU than a vApp with lower shares, assuming the workloads are actively using CPU. Shares do not reserve a fixed amount of CPU and do not create additional processor capacity.
CPU reservation
A CPU reservation guarantees a minimum amount of CPU capacity for the vApp when it is powered on, subject to available host or cluster capacity. Use a reservation when the application has a documented minimum service requirement and the environment can reliably provide that capacity.
CPU limit
A CPU limit caps the CPU capacity the vApp can consume. A low limit can throttle every contained workload even when unused CPU exists elsewhere. Set a limit only when deliberate containment is required, such as controlling a test or low-priority environment.
Configure Memory Resources
Memory controls influence how the vApp competes for physical memory. They do not change the configured memory size of each VM. Instead, they control the vApp's priority, guaranteed capacity, or maximum consumption within the available virtualization resources.
Memory shares
Memory shares define relative priority during memory contention. Higher shares improve the vApp's position compared with containers that have lower shares, but they are meaningful only when contention exists.
Memory reservation
A memory reservation guarantees a minimum amount of memory capacity for the vApp. Reservations can help protect a business-critical application, but they consume capacity that may no longer be available for other workloads. Size the reservation from measured demand rather than assigning the total configured VM memory automatically.
Memory limit
A memory limit sets the maximum memory capacity available to the vApp. An unnecessarily restrictive limit can cause guest operating systems and applications to experience pressure even when the host has free memory. Review application requirements and performance data before applying one.
vApp Resource Settings
| Setting | Applies To | Purpose | Planning Consideration |
|---|---|---|---|
| CPU shares or priority | CPU demand from the vApp | Sets relative priority during CPU contention | Use higher priority for important workloads; it is not a guarantee |
| CPU reservation | CPU capacity for the vApp | Guarantees a minimum CPU amount | Reserve only a measured, required minimum and confirm host capacity |
| CPU limit | Maximum CPU consumption | Caps CPU usage | A low limit can throttle application performance |
| Memory shares or priority | Memory demand from the vApp | Sets relative priority during memory contention | Use relative priority when workloads compete for memory |
| Memory reservation | Memory capacity for the vApp | Guarantees a minimum memory amount | Reservations reduce capacity available to other workloads |
| Memory limit | Maximum memory consumption | Caps memory available to the vApp | A restrictive limit can create memory pressure unnecessarily |
For a business-critical application group, a practical starting point is higher CPU and memory priority, followed by reservations only where a minimum service level is required. Avoid using limits as a substitute for capacity planning.
Choose an IP Allocation Policy
An IP allocation policy defines how IP addresses are provided to virtual machines associated with the vApp. The policy must match the network design, guest operating-system configuration, and any deployment or power-on workflow used by the environment.
Fixed allocation
With fixed IP allocation, addresses are manually specified and maintained. Choose this method when systems require predefined addresses, such as an application with firewall rules, DNS records, or licensing tied to known addresses. Verify that the address, subnet mask or prefix, gateway, and DNS information are complete and correct.
Transient allocation
Transient IP allocation allows vCenter Server to assign addresses dynamically from a configured IP pool when the vApp starts. An IP pool contains an address range and related network settings. The required pool must exist, contain available addresses, and be associated with the appropriate network.
Because assignment occurs as the vApp powers on, power-on can fail or produce unexpected addressing if the pool is missing, exhausted, incorrectly scoped, or unavailable to the selected network. Confirm pool capacity before using transient addressing.
DHCP allocation
DHCP is a network service that supplies IP configuration dynamically to clients. Select DHCP when the guest networks can reach a DHCP service and that service is responsible for address assignment. DHCP reservations may be useful when a workload needs a consistent address while retaining DHCP management.
vApp IP Allocation Policies
| Policy | How Address Is Assigned | Infrastructure Dependency | Best-Fit Use Case |
|---|---|---|---|
| Fixed | Administrators manually specify and maintain addresses | Correct guest and network configuration; address documentation | Applications requiring predefined addresses |
| Transient | vCenter Server assigns an address from an IP pool when the vApp starts | Configured, reachable, and available vCenter Server IP pool | Managed application packaging and repeatable dynamic deployment |
| DHCP | A DHCP service supplies the address and other IP settings | Reachable DHCP server and suitable DHCP scope | Networks designed for centrally managed dynamic addressing |
Configure Virtual Machine Startup Order
Startup ordering is useful when the virtual machines in a vApp have dependencies. A startup group is a set of virtual machines that start together before virtual machines in later groups. Group ordering does not replace application-level health checks; it only establishes the sequence in which power-on operations are initiated.
- Open the vApp edit settings workflow.
- Open the startup order or startup sequence section.
- Assign each virtual machine to a startup group.
- Arrange the groups so prerequisites appear before dependent services.
- Set a startup delay, the wait period between startup stages or groups.
- Review the order and save the configuration.
Virtual machines in the same startup group start together from the vApp's point of view. Do not place a dependent service and its prerequisite in the same group if the dependent service must wait for the prerequisite. Use a later group and allow enough time for boot, network initialization, and service readiness.
Two-tier application example
Place the Linux database VM in the first startup group. Set a 120-second delay before the next group. Place the Windows application VM in the second group.
Startup group 1: Linux database VM
Delay before group 2: 120 seconds
Startup group 2: Windows application VM
Shutdown: group 2 stops before group 1The delay should be based on observed startup and readiness time, not an arbitrary value. If the database sometimes needs more than two minutes to accept connections, increase the delay or use application-aware readiness validation.
Understand Virtual Machine Shutdown Order
Shutdown follows the inverse of the startup group order. Later startup groups shut down before earlier groups. In the two-tier example, the Windows application VM in group two shuts down before the Linux database VM in group one.
Reverse shutdown protects dependencies by stopping clients and application services before the services they depend on. Plan graceful guest shutdown behavior, service stop time, and data consistency requirements. A vApp shutdown sequence does not guarantee that an application has completed its own graceful shutdown unless the guest tools, operating system, and application are configured to do so.
Startup and Shutdown Group Behavior
| Startup Group | Example Virtual Machine | Startup Position | Delay Before Next Group | Shutdown Position |
|---|---|---|---|---|
| First group | Linux database VM | Starts first | For example, 120 seconds | Stops last |
| Second group | Windows application VM | Starts after the first group and its delay | Set according to the next dependency | Stops before the first group |
| Later groups | Web, reporting, or client VMs | Start in ascending group order | Use a delay appropriate to service readiness | Stop in descending group order |
Configure Advanced vApp Settings
Product and vendor information
Product information identifies the application or packaged solution represented by the vApp. Vendor information records the organization or team that supplied or maintains it. These fields are useful when administrators manage packaged applications, internal services, or exported application environments.
Custom properties
A custom property is a configurable key-value setting for application-specific information. Properties can record deployment-specific values, environment identifiers, ownership data, or configuration inputs used by packaging and deployment processes.
Use clear property names and document allowed values. Metadata improves operational handoff, but it does not automatically configure an application unless the deployment workflow or guest software is designed to consume the property.
Validate Changes After Saving
- Reopen the vApp settings and confirm that CPU and memory shares, reservations, and limits were saved.
- Verify that the IP allocation policy matches the network design.
- For transient allocation, confirm that the relevant IP pool has available addresses and correct network settings.
- Check startup groups, group order, and delays.
- Confirm that shutdown order is the reverse of the intended startup dependency order.
- Review product, vendor, and custom property values.
- Test the vApp startup sequence during a safe maintenance window.
- Verify the expected IP address after power-on.
- Confirm that each application dependency is reachable and ready before dependent services start.
- Perform a controlled shutdown test and verify graceful service behavior.
Resource settings should also be checked against host or cluster capacity. For broader resource-pool concepts, see how resource pools work and how to create a resource pool.
Troubleshoot Common Problems
A dependent VM starts too early
Likely causes include placing both VMs in the same startup group, ordering groups incorrectly, or setting a delay that is too short. Move the dependency to an earlier group, move the dependent VM to a later group, increase the delay, and test application readiness.
A VM receives an unexpected IP address
Check whether fixed, transient, or DHCP allocation was selected intentionally. For transient allocation, verify the IP pool, available addresses, network association, and related settings. For DHCP, verify DHCP scope availability and network reachability. For fixed allocation, check every manually specified address and gateway value.
The vApp performs poorly during contention
Review CPU and memory shares, reservations, and limits. Low shares may reduce priority, reservations may not cover the required minimum, and a limit may be capping consumption. Remove or raise unnecessary limits and adjust priority or reservations based on measured demand and available capacity.
Shutdown causes service errors
Confirm that the application tier is in a later startup group than its dependency, because later groups shut down first. Check that guest operating systems and applications receive enough time to stop gracefully, then perform a controlled shutdown test.
Exam-Relevant Notes
- Shares provide relative priority during contention; they are not guaranteed capacity.
- A reservation guarantees a minimum amount of CPU or memory capacity, provided the required capacity can be admitted.
- A limit caps consumption and can cause throttling even when unused capacity exists.
- Transient IP allocation depends on a configured vCenter Server IP pool and is associated with vApp power-on.
- Virtual machines in the same startup group start together.
- Startup proceeds from earlier groups to later groups; shutdown proceeds in reverse.
- A startup delay is a wait period between startup stages and should reflect actual service readiness time.
For related administration tasks, review editing virtual machine settings, virtual machine startup and shutdown automation, and vSphere networking configuration when those topics are available in your course path.