VMware ESXi and vSphere Cluster Management
Configure vApp Settings in VMware vSphere
Learn how to configure vApp CPU and memory controls, IP allocation policies, VM startup order, shutdown behavior, and advanced metadata in vSphere.
A vApp is a logical container for one or more related virtual machines. Besides organizing inventory objects, a vApp lets an administrator apply operational settings to the group, including resource controls, IP address allocation behavior, startup sequencing, shutdown sequencing, and application metadata.
Administrators commonly edit vApp settings when they need to control resource consumption, define how member virtual machines obtain network addresses, or coordinate application dependencies. For example, a database VM can start before an application VM that depends on it, while a business-critical vApp can receive a higher relative resource priority than a test vApp.
vApp settings at a glance
| Setting category | What it controls | Key configuration choices | Operational consideration |
|---|---|---|---|
| CPU Resources | CPU entitlement and consumption for the vApp | Shares, reservation, and limit | Reservations consume cluster capacity; limits can throttle workloads |
| Memory Resources | Memory entitlement and consumption for the vApp | Shares, reservation, and limit | Reservations affect capacity planning; low limits can cause guest performance problems |
| IP Allocation | How member VMs obtain IP addresses | Fixed, Transient, or DHCP | The selected policy must match the network design and available services |
| Start Order | Power-on and power-off sequencing for member VMs | Startup groups and delays | Delays are not a substitute for checking that a service is actually ready |
| Advanced Settings | Application identity and administrator-defined metadata | Product, vendor, and custom properties | Property names and values should be documented for people and automation |
Open the vApp Edit Settings interface
- In the vSphere Client, locate the vApp in the inventory.
- Open the vApp's context menu or actions menu.
- Select Edit Settings.
- Select the category you need, such as CPU Resources, Memory Resources, IP Allocation, Start Order, or Advanced Settings.
- Change the required values and apply or save the configuration.
Exact labels and the available fields can vary with the vSphere version, licensing, object type, and permissions. If an option is unavailable, verify that you selected the vApp rather than a VM and that your account has permission to edit the object.
Configure CPU resource settings
CPU resource controls determine how the vApp receives processor capacity from its parent resource hierarchy. They are most important when the host or cluster cannot immediately satisfy all workloads.
CPU shares
CPU shares are a relative priority. When CPU contention exists, a vApp with more shares receives a larger relative portion of available CPU than a vApp with fewer shares. Shares do not reserve a fixed number of megahertz or guarantee performance when the system is not contended.
For example, assigning higher CPU shares to a production vApp than to a test vApp expresses the production workload's greater importance during contention. Shares have little visible effect when sufficient CPU capacity is available.
CPU reservation
A CPU reservation is a guaranteed amount of CPU capacity for the vApp, subject to the capacity and admission rules of the parent host, cluster, or resource hierarchy. Reservations can protect critical workloads, but they also consume planning capacity even when the vApp is not actively using all of the reserved CPU.
Large reservations may prevent other VMs or vApps from powering on, migrating, or obtaining their planned reservations. Set them only when the workload has a measured requirement and the cluster can support it.
CPU limit
A CPU limit is the maximum CPU capacity the vApp can consume. A limit can be useful for deliberate containment, but an unnecessarily low limit caps the vApp even when unused host capacity is available. This can make a workload appear CPU-starved despite low overall cluster utilization.
Configure memory resource settings
Memory shares
Memory shares provide a relative priority during memory contention. A vApp with higher shares is favored over one with lower shares when the host or cluster must decide how to distribute constrained memory resources. Shares do not guarantee a fixed amount of memory.
Memory reservation
A memory reservation guarantees memory capacity for the vApp, provided the parent resource hierarchy can satisfy the reservation. Reservations improve predictability for important workloads but reduce available capacity for other objects and must be included in cluster capacity planning.
Before increasing a reservation, check current and planned host capacity, failover requirements, maintenance capacity, and the effect on VM power-on or migration operations.
Memory limit
A memory limit sets the maximum memory available to the vApp. A restrictive limit can cause guest operating systems or applications to experience memory pressure even though physical host memory remains available. Review the limit whenever a workload performs poorly or reports unexpected paging, swapping, or application pressure.
| Control | CPU or memory behavior | Use during contention | Potential risk if misconfigured |
|---|---|---|---|
| Shares | Relative priority compared with sibling workloads | Favor an important vApp over lower-priority workloads | They provide no absolute guarantee and have limited effect without contention |
| Reservation | Guaranteed CPU capacity or host memory capacity | Protect a known baseline requirement | Consumes capacity and can prevent power-on, migration, or failover operations |
| Limit | Maximum CPU consumption or memory available | Contain a workload intentionally | A low value can throttle or starve a workload despite unused host capacity |
Choose an IP allocation policy
An IP allocation policy defines how the vApp provides IP addresses to its member virtual machines. The policy must agree with the guest operating system configuration, network connectivity, address-management process, and any application requirement for stable addresses.
Fixed allocation
With fixed IP allocation, addresses are manually configured. Use this approach when the application stack requires documented, stable addresses and an administrator has a controlled addressing plan. Record the address, subnet mask or prefix, gateway, DNS settings, and the VM using each address.
Fixed allocation provides predictable persistence, but changes are manual. A moved or cloned vApp can create conflicts if the same addresses are used on another network or deployment.
Transient allocation
With transient IP allocation, vCenter Server assigns addresses from a configured IP pool when the vApp powers on. An IP pool is a defined address range with associated network settings. This policy suits a portable vApp that should receive addresses from centrally managed ranges at power-on.
Transient allocation requires a correctly configured, reachable, and sufficiently large IP pool. Address assignment is tied to the vApp lifecycle rather than being a permanently hand-entered guest address, so administrators should not assume that an address remains unchanged across every power cycle or deployment.
DHCP allocation
With DHCP IP allocation, a DHCP service supplies addresses to the guest systems. DHCP is appropriate when network infrastructure centrally manages leases and the applicable network can reach the DHCP service.
Validate the DHCP scope, lease availability, VLAN or port group connectivity, relay configuration when applicable, and guest network settings. DHCP is convenient, but a VM's address may change when its lease changes unless the DHCP service provides a reservation or other stable-address mechanism.
| Policy | Address source | When addresses are assigned | Persistence and management behavior | Typical use case | Requirements |
|---|---|---|---|---|---|
| Fixed | Administrator-defined configuration | Manually, before or during deployment | Predictable when the plan is maintained; changes are manual | Applications requiring documented stable addresses | Addressing plan and conflict prevention |
| Transient | vCenter Server IP pool | When the vApp powers on | Managed from the configured pool; assignment may vary across lifecycle events | Portable vApps using centrally managed address ranges | Configured IP pool, available addresses, and compatible network design |
| DHCP | DHCP server | When the guest requests a lease | Lease-based and potentially changeable | Networks where DHCP centrally manages client addresses | Reachable DHCP service, correct connectivity, and available scope capacity |
Configure virtual machine start order
Start order is the sequence in which member virtual machines are powered on. Rather than requiring one long list, vSphere organizes VMs into startup groups. All VMs in an earlier group start before VMs in a later group. VMs in the same group are treated as peers, so do not use the same group when one VM depends on another.
A startup delay is the wait period between groups. Delays allow an operating system, database, directory service, or other dependency time to initialize before the next group starts. A delay is only a time-based pause; it does not verify that a guest or application is ready.
- Open the vApp's Edit Settings interface and select Start Order.
- For each member VM, assign the VM to the appropriate startup group.
- Order the groups from earliest to latest.
- Set the delay before the next group starts, where appropriate.
- Document the dependency represented by each group and the expected reverse shutdown sequence.
Shutdown occurs in reverse group order. A VM in a later startup group shuts down before a VM in an earlier group. This behavior is useful when consumers should stop before the services they consume, but it must be included in the dependency design.
| Startup group | Virtual machine | Startup delay before next group | Startup role | Shutdown sequence |
|---|---|---|---|---|
| 1 | Linux database VM | 120 seconds | Provides data service first | Shuts down last |
| 2 | Windows application VM | 60 seconds | Starts after the database has had time to initialize | Shuts down before the database VM |
| 3 | Web or reporting VM | Configured as needed | Starts after the application tier | Shuts down first |
Configure advanced vApp settings
Product and vendor information
Advanced settings can include product information and vendor information. Use these fields to identify the application represented by the vApp, the software or service provider, and other deployment context useful to administrators.
Custom properties
A custom property is administrator-defined metadata attached to a vApp. Properties can describe the application owner, environment, service tier, release, support group, or a value consumed by a deployment, guest-customization, or automation workflow.
Define each property consistently. Document the property name, data type or expected format, permitted values, whether the value is required, and the person or tool that consumes it. For example:
application_owner = platform-team
environment = production
service_tier = tier-1
Metadata is not automatically meaningful to every tool. A property helps automation only when the consumer is designed to read that property and interpret its value correctly.
Save and validate changes
- Review every changed category before applying the configuration.
- Confirm CPU and memory shares reflect workload importance, reservations fit available capacity, and limits are not unintentionally restrictive.
- For fixed allocation, verify the manual addressing plan. For transient allocation, verify the IP pool, address range, and available capacity. For DHCP, verify service reachability and scope capacity.
- Check every member VM's startup group, group order, delay, and expected reverse shutdown behavior.
- Review product, vendor, and custom property values for accuracy and documented naming.
- Apply or save the settings.
- In a maintenance window or non-production environment, test vApp startup and shutdown when application dependencies are involved.
- After testing, verify not only that VMs powered on, but also that guest services became ready in the intended order and that clients could connect.
Troubleshooting vApp settings
A dependent application starts before its database
- Check whether both VMs are in the same startup group.
- Verify that the database VM is in an earlier group than the application VM.
- Increase the delay if the dependency needs more time to initialize.
- Use service-readiness checks or application validation rather than treating the delay as proof that the database is ready.
Virtual machines shut down in an unexpected order
- Remember that shutdown follows reverse startup-group order, not the same order as startup.
- Review group assignments against the dependency chain.
- Ensure that a service provider is in an earlier startup group than its consumer if the consumer must stop first.
Transient allocation does not provide an expected address
- Verify that transient allocation is selected.
- Check that the associated IP pool and address range are configured correctly.
- Confirm that the pool has sufficient unused addresses and that its network settings match the VM network.
- Check whether the chosen policy is appropriate for the deployment's persistence requirements.
DHCP allocation does not provide an address
- Confirm that a DHCP service is available and reachable on the applicable network.
- Validate VLAN, port group, routing, relay, and firewall configuration as applicable.
- Check DHCP scope capacity and guest network configuration.
The vApp performs poorly despite available host capacity
- Review CPU and memory limits; a low limit can throttle the vApp even when the host has unused capacity.
- Check whether reservations can be satisfied within the cluster, including failover and maintenance capacity.
- Compare shares with the priorities of sibling vApps and resource pools.
- Use workload measurements to adjust settings rather than increasing reservations or limits without a capacity plan.
Exam-relevant notes
- Shares are relative: they matter primarily during contention and are not guarantees.
- Reservations guarantee capacity: they improve predictability but consume capacity for planning and admission purposes.
- Limits cap consumption: an unnecessarily low limit can cause performance problems even when physical capacity is available.
- Transient allocation uses a vCenter-managed IP pool at vApp power-on.
- DHCP allocation depends on a reachable DHCP service.
- Fixed allocation is manually configured and is suitable when stable, documented addresses are required.
- Startup groups control lifecycle order: earlier groups start first, and shutdown proceeds in reverse group order.
- A startup delay is not a readiness test. Validate the actual guest or application service.
For related administration work, continue with vApp settings as a reference for the resource, networking, lifecycle, and metadata controls available at the vApp level.