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
- Orka Engine doesn’t save the network interface with the VM. Pass
network_interfaceevery time you deploy or start a VM, including whenvm.ymlstarts 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.
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:
network_interface to the host’s network interface, for example en0. Without it, the VM uses NAT.
Step 3: Verify VMs received DHCP addresses
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:
- Confirm the interface name is correct: SSH to host and run
ifconfig - Delete and redeploy affected VMs with
network_interfaceset
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.
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:
Automation enhancements
Extending Ansible playbooks
The orka-engine-orchestration playbooks provide core functionality. Common extensions include: Automated image update workflow: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:
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:Tenant-specific policies
Apply different Citrix policies per tenant:- Create separate Delivery Groups per tenant
- Create policies with appropriate settings per tenant (for example, Finance: no clipboard, no file transfer; Engineering: full access)
- Filter policies by Delivery Group name

