Worth reading before deploying this somewhere that matters. This plugin runs commands as root on your hypervisors, so its trust model is not incidental.
Every action reaches a hypervisor through the Morpheus execution-request API
(POST /api/execution-request/execute). The plugin never opens an SSH
connection of its own and holds no host credentials.
Those execution requests run as root on the hypervisor. In practice the
plugin issues virsh, qemu-img, tar and file operations against paths you
select in the UI.
Stored in plugin settings (Administration → Plugins → VM XML Editor), and read back only by the plugin.
Give it its own service account. Two reasons:
- Everything the plugin runs is attributed to the account that owns the key in Morpheus's audit trail. A personal token makes that trail useless.
- The account needs permission to execute scripts against hypervisors, which is a high privilege. Scoping it to one purpose limits the damage if the key leaks.
Rotate the key by replacing it in plugin settings; nothing caches it elsewhere.
Installs predating 1.11.7 kept the key in
/var/opt/morpheus/morpheus-ui/plugins/vm-xml-editor-config.json, which is still
read as a fallback. If you have migrated to plugin settings, delete that file
— otherwise a plaintext key is sitting on disk for no reason.
Path (under /var/opt/morpheus/morpheus-ui/plugins/) |
Contents |
|---|---|
vm-xml-editor-backups/ |
XML backups sent to the "appliance" destination |
vm-xml-editor-backups.json |
Index of every backup: VM, host, path, size, sha256 |
vm-xml-editor-audit.json |
Actions taken: applies, backups, reverts, conversions |
vm-xml-editor-logs/ |
Bundles produced by "Collect logs" |
Domain XML can contain sensitive material — VNC passwords, cloud-init payloads, host paths, MAC addresses. Backups and log bundles inherit whatever is in it. Treat those directories as sensitive and include them in whatever you do about appliance backups and retention.
Nothing is sent anywhere outside your appliance and hosts. There is no telemetry.
Paths accepted from the UI are checked to be absolute and free of .., and
names are restricted to a conservative character set before reaching a shell.
Conversion output is written to named files only — no globbing, and no recursive
delete of a directory you nominated, since that directory is usually a datastore
holding live disks.
That said: anyone who can reach the XML Editor tab can run privileged operations on your hypervisors. Restrict the plugin the way you would restrict any tool with that reach — through Morpheus roles and permissions on who can see Infrastructure → Compute.
- A backup is taken before every apply, to a destination you choose.
- Changes go to the persistent definition, never the running one.
- Three server-side validators run before
virsh define— disk drivers, firmware, boot order — and any can refuse the change. - Removing a disk detaches it from the XML; it never deletes an image file.
- Conversion never defines a domain.
Open an issue for anything non-sensitive. For something that should not be public, contact the maintainer directly rather than filing publicly.