Skip to main content
This page covers advanced configuration topics for production MacStadium VDI environments. These are optional enhancements beyond the initial deployment. You don’t need them to get started, but they unlock performance, scale, and automation capabilities.

Performance optimization

Bridged networking configuration

When using bridged networking, VMs connect directly to your physical network as native devices, receiving their own IP address from your network’s DHCP server. This enables direct communication with other network devices without NAT. Requirements:
  • A working DHCP server on your network that can assign IPs to VMs
  • Sufficient IP addresses in your subnet (one per VM)
  • MacStadium VDI running Orka Engine 3.3.0 or later
Important limitations:
  • Orka Engine doesn’t save the network interface with the VM. Pass network_interface every time you deploy or start a VM, including when vm.yml starts a whole group of VMs. A VM started without it comes up on NAT.
MacStadium VDI deployments require bridged networking. Without it, VMs receive NAT IPs (192.168.64.x) that Citrix Cloud and end users can’t reach.
Configuration: Bridged networking is set on each VM when you deploy or start it, with the network_interface variable. Step 1: Find the host network interface Specify which physical network interface on your Orka hosts connects to your DHCP-enabled network. To determine the correct interface, SSH to each Orka host and check:
Look for the interface with an IP in your corporate network range. Step 2: Deploy VMs with bridged networking
Set network_interface to the host’s network interface, for example en0. Without it, the VM uses NAT. Step 3: Verify VMs received DHCP addresses
VMs should show IP addresses from your corporate network range, not 192.168.64.x. Troubleshooting bridged networking: If VMs have 192.168.64.x addresses instead of corporate IPs, they were deployed without network_interface, or with the wrong interface:
  1. Confirm the interface name is correct: SSH to host and run ifconfig
  2. Delete and redeploy affected VMs with network_interface set
Deleting VMs matches names by prefix. delete.yml, and vm.yml with desired_state=absent, delete every VM whose name starts with the vm_name you pass, not only the VM with that exact name. For example, vm_name=citrix-vda-finance deletes every VM in that group. Before you delete, run list.yml and make sure no VM you want to keep has a name that starts with the value you’re passing.
If VMs can’t reach network services after getting DHCP addresses, verify your DHCP server provides valid gateway and DNS settings:
For complex bridged networking issues, contact MacStadium Support.

HDX tuning for latency-sensitive workloads

For users editing video, audio, or using graphics-intensive applications who report lag or stuttering: 1. Enable Adaptive Transport (Framehawk) for high-latency connections: Citrix Cloud Console → Policies → Create new policy → HDX Adaptive Transport → set “Adaptive Transport” to “Preferred” → apply to affected Delivery Groups. 2. Adjust visual quality settings: For users on high-bandwidth connections: Policies → Visual Display → Visual Quality → “Build to Lossless” For users on low-bandwidth connections: Policies → Visual Display → Visual Quality → “Medium” 3. Enable GPU acceleration (M4 Macs): M4 Macs support GPU passthrough for VMs. Requirements: Orka 3.5+, macOS 15.5+ on the host, specific VM configuration.
GPU acceleration is not yet automated in the Orka Engine Ansible playbooks. Contact MacStadium support for GPU-enabled VM deployment guidance.
4. Test with Citrix HDX Monitor: Download the Citrix HDX Monitor tool to identify bottlenecks: network latency, bandwidth constraints, and frame rate drops. Use results to fine-tune HDX policies further.

Resource allocation (CPU, memory, storage)

VM CPU and memory are set when you deploy the VM, not inherited from the golden image. deploy.yml allocates 2 vCPUs and 4096 MB of memory unless you pass cpu and memory (in MB). Disk size works the other way: a VM gets the disk size stored in its image, so it’s whatever the golden image was built with. The playbooks don’t change it. To deploy a VM with more resources, pass cpu and memory to deploy.yml:
Recommended high-spec configuration for power users: 8+ CPU cores and 32 GB RAM. Storage comes from the golden image’s disk size.
Overprovisioning resources reduces VM density on hosts. Monitor host utilization to ensure you’re not running fewer VMs than capacity allows.

Automation enhancements

Extending Ansible playbooks

The orka-engine-orchestration playbooks provide core functionality. Common extensions include: Automated image update workflow:
Deleting VMs matches names by prefix. delete.yml, and vm.yml with desired_state=absent, delete every VM whose name starts with the vm_name you pass, not only the VM with that exact name. For example, vm_name=citrix-vda-finance deletes every VM in that group. Before you delete, run list.yml and make sure no VM you want to keep has a name that starts with the value you’re passing.
Scheduled capacity scaling:
Health check automation:
Schedule this every 15 minutes and pipe output to your monitoring system.

Integrating with CI/CD pipelines

Automatically build and deploy updated golden images when application code changes. Example: GitHub Actions workflow:
push_image.yml saves image-test-01 with vm save and pushes it to the registry, so the new image includes the application you copied to the test VM and tested.

Scheduled maintenance tasks

Use this schedule as a baseline:

Multi-tenant considerations

Isolation strategies

Option 1: Delivery Group separation Deploy all VMs from shared infrastructure. Separate users into different Citrix Delivery Groups with different policies per group. Simple and resource-efficient, but teams share hardware and one team’s resource spike affects others. Option 2: VM group separation Deploy separate VM groups per tenant (citrix-vda-finance, citrix-vda-engineering), each with its own golden image. Groups still share Orka hosts. Option 3: Host-level separation Allocate specific Orka hosts to specific tenants:
The playbooks run against the hosts group, so make the tenant groups children of hosts. Deploy tenant VMs only to their assigned hosts:
deploy.yml builds its plan on the Ansible control node, so include localhost in --limit. Complete resource isolation with no noisy-neighbor problems, but reduced flexibility and potential underutilization.

Chargeback and cost allocation

Track resources per tenant:
Calculate per-VM cost: divide host cost (hardware + MacStadium hosting) by VMs per host, then multiply by VM count per tenant.

Tenant-specific policies

Apply different Citrix policies per tenant:
  1. Create separate Delivery Groups per tenant
  2. Create policies with appropriate settings per tenant (for example, Finance: no clipboard, no file transfer; Engineering: full access)
  3. Filter policies by Delivery Group name
Each tenant gets appropriate controls without affecting others.