RVC changelog
The following describes the important updates to the SC//Reliant™ Virtual Controller 3.x Client documentation. We occasionally make small updates to fix typos and address minor feedback that won't be displayed in the table.
| RVC Version | Description | Date |
|---|
3.13.0 |
RVC 3.13.0 Improvements:
- KVM backups include vTPM state and UEFI NVRAM - A full KVM backup now captures the virtual machine's vTPM state and UEFI NVRAM store alongside the disk image, and a restore puts them back. Backups taken before 3.13.0 do not contain either file, so a UEFI or vTPM virtual machine restored from one may require manual intervention afterward.
- New kvm.full_backup_info method - Describes a full backup archive without extracting it, including the RVC version that created it, the virtual machine it was taken from, and whether it carries the NVRAM store and vTPM state.
- Host capabilities in kvm.system_info -
kvm.system_info now reports the capabilities the host offers to virtual machines, such as the CPU model and modes, firmware types, disk buses, and video models.
- Puppet run status reporting - The Puppet module now reports whether Puppet is running, stopped, or disabled, along with the process ID, the last run time, the user who disabled it and when, the next scheduled run, and the active environment. This covers the features previously provided by the MCollective agent.
- Persisted Puppet run output - RVC now saves the output of the most recent Puppet run to a predefined file, on both singleton nodes and clusters, so it can be reviewed later. Only the most recent run is retained.
- Post-run hooks for Puppet - Scripts placed in the hook directory now run automatically after a Puppet run, so diagnostics and host validations can be carried out as part of the run. Each hook reports its own result, and the run ends with a pass or fail summary. Hooks can be skipped for a single run with
--skip-hooks.
- Puppet runs refused while Puppet is disabled -
puppet.run now refuses to run when Puppet is disabled on the node, and reports the reason and the user who disabled it. Use --force to run anyway. puppet.disable now requires --message.
- Cluster-aware Puppet runs -
puppet.run --cluster runs Puppet on both nodes of a cluster in sequence, starting with the primary or secondary node, and skips the second node if the first run fails.
- Running tasks survive an rvc-server restart - The rvc-server now resumes orchestration of its tasks after a service restart, so a long-running job such as a Puppet run or an ownership transfer continues and stays monitored instead of being lost. This also covers stopping the service and upgrading the RVC packages while a job is in flight.
- Cluster Wipe removes UEFI virtual machines - The Cluster Wipe step of an ownership transfer now removes UEFI virtual machines together with their NVRAM store, so the first Puppet run afterward is not blocked by leftover virtual machine definitions.
- Decimal sensor readings -
sys.sensors no longer fails when a sensor reports a decimal value.
| September 21, 2026 |
3.12.0 |
RVC 3.12.0 Improvements:
- New docker.pull method - Asynchronously pulls Docker images. Accepts an array of image tags and returns immediately, pulling in the background.
- New sys.uptime method - Reports the duration since the last system boot, returning both an ISO 8601 timestamp and a humanized uptime string.
- New sys.report method - A single call provides a full node status overview, including Docker, KVM, and Puppet summaries plus system metrics (CPU, memory, storage, network).
| June 3, 2026 |
3.11.0 |
RVC 3.11.0 Improvements:
- [New / Beta Release] Introduced a new Puppet module in RVC with capabilities to run, enable, disable, and manage Puppet executions. This is part of the ongoing effort to move Puppet operations into RVC and does not replace the Puppet Launcher yet.
- Cluster Module Enhancement (
cluster.execute) – Added a new method that enables executing RVC commands across cluster nodes, allowing operations to run on the primary node, secondary node, or both.
| March 12, 2026 |
3.10.0 |
RVC 3.10.0:
-
Improvements to In-place Upgrade: The Orchestrator, which manages the overall upgrade process, now incorporates a verification step for the software image before proceeding with the installation enhancing security and reliability. This verification includes:
- Image Integrity Check: Ensuring the image file is complete and has not been corrupted during transfer.
- Signature Validation: The Orchestrator will now verify the digital signature embedded within the upgrade image. This confirms that the image is authentic and has not been tampered with by unauthorized parties, bolstering the security of the overall upgrade process.
| February 11, 2026 |