TerraMaster Forum

While testing the Virtual Machine capabilities in TOS 7, I identified an architectural design choice regarding how the TerraVirtualMachine daemon handles QEMU/libvirt domain states. This design breaks interoperability with standard hypervisor management tools and causes UI desynchronization when users attempt to automate their NAS.

• 1. The Problem Statement
  
  Currently, the TerraMaster Virtual Machine application abstracts the VM state into an internal Redis/etcd database rather than using the hypervisor (libvirtd) as the single source of truth.
  
  When a VM is shut down via the TerraMaster Web UI, the TerraVirtualMachine daemon completely removes the domain from libvirtd (treating it as a transient domain). Consequently, the VM simply ceases to exist from the perspective of the underlying hypervisor until the TerraMaster UI powers it on again.
• 2. The User Impact
  
  Because the domain is purged from libvirtd when powered off, users cannot utilize standard open-source tooling to manage their NAS.
  
  Automation is Broken: Standard libvirt API calls, virsh commands, Ansible playbooks, and custom ChatOps/Telegram bots cannot start a powered-off VM because the hypervisor throws a failed to get domain error.
  
  UI Desynchronization: If a user manually defines the VM XML (virsh define) to establish persistence for automation, the TerraMaster UI loses sync. Attempting to manage the VM from the UI thereafter often results in generic errors or failure to resume/start the VM, as the UI's internal Redis state conflicts with the actual libvirtd state.
• 3. Proposed Solutions
  
  I recommend adopting one of the following approaches:
  • Option A: Utilize Persistent Libvirt Domains (Recommended)
    Instead of creating transient domains that are destroyed upon shutdown, the TerraVirtualMachine daemon should use virsh define (or the equivalent libvirt API call) to register the XML configuration permanently.
    
    Benefit: The domain remains known to the hypervisor in a shut off state. Users can safely start the VM via standard virsh commands or third-party tools, and the TerraMaster UI can simply poll libvirtd to accurately reflect the "Running" or "Stopped" state.
  • Option B: Implement Bi-Directional State Synchronization
    If TerraMaster prefers to maintain the Redis database as the primary configuration store, the TerraVirtualMachine daemon should actively listen to standard libvirt lifecycle events. If a user starts or stops a VM via the CLI, the daemon should detect this change and update the Web UI accordingly, preventing the current UI desynchronization errors.
  • Option C: Document a Public CLI for TerraVirtualMachine
    If direct libvirt interaction is discouraged, please consider exposing standard CLI arguments for the /Volume1/@apps/VMs/bin/TerraVirtualMachine binary (e.g., TerraVirtualMachine start <uuid>). This would allow users to write custom automation scripts that safely interact with your proprietary daemon and keep the Web UI in sync.

Thank you for your detailed explanation. I will forward it to the product team for evaluation.

CursaYang wrote: ↑22 May 2026, 08:42

Hi, is there any information if the feature is going to be implemented in future?

Shadeofspirit wrote: ↑30 Jun 2026, 22:42

Thank you for following up on this.

Our product team has thoroughly evaluated your suggestion regarding the VMS optimization. While they find the idea valuable, our current development roadmap is tightly focused on core performance stability updates.

As a result, this feature is not planned for the immediate upcoming releases, but we have logged it in our long-term backlog for future review. We appreciate your patience and understanding."

Shadeofspirit wrote: ↑30 Jun 2026, 22:42

We are currently discussing internally how to automate VMs. We may not necessarily go with your proposed approach, as implementing it would be somewhat impractical. Regardless, delivering an automation solution for our users is indeed our goal, but it will take some time. Please bear with us.