@raniers1 1. Direct DB modification of Global Configs
No cache issue here. CloudStack reads global configs through the standard DAO layer, which queries the DB at read time — no stale cache involved. For those KVM HA parameters (kvm.ha.recover.failure.threshold etc.), just update the configuration table directly. No MS restart needed. In production, API/UI is still the safer route to avoid human error, but functionally direct DB mod is fine. 2. Enabling HA on already-uploaded templates HA flags on templates (vm_template) and VMs (vm_instance) are independent. Modifying the template's HA flag in DB only affects VMs deployed after the change; existing VMs are not impacted. Low risk. If you also need HA on already-deployed VMs, you'll need to update vm_instance — template change alone won't cover that.
