@john.c Thank you for all the great ideas, keep em' comming!

@john.c Yes, will do! Thanks again for all the input, it is greatly appreciated.
Happy Day

@fohdeesha Thank you very much for the corrections and details, I will be looking into addressing each issue directly....

@poddingue Hey, it's just fun building stuff, even if it ends up in the bit-bucket (as unfotunately that's the destiny of all things anyway).
Happy Day

@poddingue Thank you for the reply, and correction. I totally missed the fact that the Load Balancer plugin has DRS-Type functionality (as well as many more customizable options and features). I'll have to look into it. Thanks again, and Happy Day

PROJECT DECOMMISSIONED

As noted below, all the functions in this plugin are included in the much fully-featured built-in load-balancer plugin. Please refer to the documentation for more details.

---

Affinity Manager Plugin

WHAT: In keeping with my previous project (Tag-Automation Plugin, found here), I am releasing the Affinity Manager Plugin, which is a fully tag-driven plugin for Xen Orchestra. It works similar to VMware's DRS to ensure continuous uptime and optimal resource allocation of crucial VMs and services.

---

PROGRAM FEATURES

• Host Affinity (RunOn) Run VMs on specific host group (e.g. a particular data center or set of hosts)
• Host Anti-Affinity (NotOn) Keep VMs off of specific host group
• VM Keep-Together (KeepTogether) Keep named group of VMs on the same host (follows Leader VM)
• VM Separation (KeepApart) Spread named group of VMs across unique hosts (best-effort)

---

REAL-WORLD EXAMPLES

Core-Critical Service Protection (AM-RunOn)

• Example #1: Run core-critical services in sepparate Data Centers
• Goal: Ensure crucial VMs (i.e. MS AD, DNS, etc.) are protected from possible DC outage
• VM Tag: AM-RunOn_P1-DC1-HOST (applied to "Primary" crucial service VM)
• VM Tag: AM-RunOn_P1-DC2-HOST (applied to "Secondary" crucial service VM)
• Host Tag: P1-DC1-HOST (applied to each POOL-1/Data Center 1 host)
• Host Tag: P1-DC2-HOST (applied to each POOL-1/Data Center 2 host)
• Result: The primary service VMs (i.e. MS AD Controller) will run on DC1 host(s), and the secondary service VMs will run on DC2 host(s)

Database High Availability (KeepApart)

• Example #2: Run database servers on different physical hosts
• Goal: Protect critical DB servers from possible host outage
• VM Tag: AM-KeepApart_DBCluster1 (applied to both DB VMs)
• VM Tag: AM-RunOn_P1-DC2-HOST (applied to "Secondary" crucial service VM)
• Result: Ensures DB servers run on different hosts

Note: Tag rules are soft-enforced. For example, if a data center outage occurs all VMs will automatically run any available hosts.

---

VM TAG SYNTAX

Apply tags to VMs in the XO UI:

VM TAG / RULE	EXAMPLE	MEANING
AM-RunOn_{HostGrpName}	AM-RunOn_P1-DC2-HOST	VM should run on hosts tagged P1-DC2-HOST
AM-NotOn_{HostGrpName}	AM-NotOn_P2-DC1-HOST	VM should NOT run on hosts tagged P2-DC1-HOST
AM-KeepTogether_{GrpName}	AM-KeepTogether_AppStack1	Keep all group VMs on same host (follows Leader VM)
AM-KeepApart_{GrpName}	AM-KeepApart_DBCluster1	Spread group VMs across unique hosts (best effort)

Note: Multiple rules can be combined on a single VM. For example, a VM can have both
AM-RunOn_P1-DC1-HOST and AM-KeepTogether_WebCluster simultaneously.

---

HOST TAG SYNTAX

Apply tags to hosts in the XO UI (i.e. to define host groups):

EXAMPLE HOST TAG	POOL	LOCATION
P1-DC2-HOST	POOL-1	Data Center 2
P2-DC1-HOST	POOL-2	Data Center 1

---

INSTALLATION

Note: "Airgap" in the tar.gz file below, simply means the bundle includes all required dependencies for both an offline or online installation.

1. Download the latest airgap release tarball from GitHub:
   {link-removed}

2. SCP the tarball to your XOA:

   scp xo-affinity-manager-airgap-vX.X.X.tar.gz <xoa-user>@<xoa-ip>:/tmp/
   

3. Create the plugin folder:

   sudo mkdir -p /usr/local/lib/node_modules/xo-server-affinity-manager
   

4. Extract directly into the plugin directory:

   sudo tar -xzvf /tmp/xo-affinity-manager-airgap-vX.X.X.tar.gz -C /usr/local/lib/node_modules/xo-server-affinity-manager/ --strip-components=1
   

5. Restart xo-server:

   sudo systemctl restart xo-server
   

6. Verify registration:

   sudo journalctl -u xo-server -n 100 --no-pager | grep -A3 "affinity-manager"
   

   You should see:
   [INFO] xo-affinity-manager: Plugin factory called -- xo context: YES
   [INFO] xo-affinity-manager: Plugin loaded -- waiting for core started.
   xo:plugin INFO successfully register affinity-manager

7. Enable and configure the plugin in XO:
   Settings -> Plugins -> affinity-manager -> Enable

---

CONFIGURATION

(XO > Settings > Plugins)

• Enforcement Schedule — Run every 15 minutes, hourly, or daily (configurable)

• Dry Run Mode — Logs all intended actions without migrating anything (default: ON)

• Log Path — Configurable path to the log (Created automatically if it does not exist).

• Pool Safety — Cross-pool migration is always blocked (i.e. Plugin only migrates VMs within the same pool)

• Log Rotatate — Rotate/compress log files at 10 MB (keeping 3 archives)

---

LINKS

GitHub: https://github.com/johnezero/xo-affinity-manager

---

STANDARD DISCLAIMER HERE

This software is provided AS-IS without any express or implied warranty.
While this plugin is being used in a production environment managing live VMs,
you should always review the code and test it in a non-production environment
before full deployment.
Note: The plugin is designed to ONLY take action on VMs with specific predefined tags assigned -- all other VMs are never touched.
Use Dry-Run mode to preview all changes before applying them.
That said, as always - your mileage may vary...

@poddingue Oh yes (dumb me). Very good, we'll see if they respond (as now there's two @ refferences). Happy Day

@poddingue Sorry for my ignorance on this, but I went to the @Team-Storage page and it appears to be private (with no way to post my question). I hit the "Request Invitation" button, but not sure that's what I need to do to post a question either...

@poddingue Thank you for all the details and advise. I will reach out to them to see if it is anywhere on the project horizon. Thanks much, and have a great day!

Just checking if Vates actively working with PureStorage (aka now EverPure) on replicating the vmware pure-plugin app (i.e. that gives you the ability to restore individual VMs from SafeMode Snapshots)? I know this would be highly valuable, with as many XO/Pure customers that there are out there.

Why I am asking, is I'm starting to look into building a pure-plugin myself, but didn't want to go too far down the road if an official plugin is forthcoming anytime soon.

@julienXOvates Noted, thank you!

@MathieuRA Wow, and wow! Thanks for the detail on RBAC, I'll have give it a look. Unfortunately the current plugin doesn't get any where near the "deep-weeds" of all that, and basically just uses the built-in "Admin, Operator and Viewer" roles to auto-provision (via Autopilot) new VMs as they show up (i.e. during a migration project, etc. ). We needed something for our current VMware-to-XCP-ng migration project, and '"Where's there's a will, there's a way" kicked in and the plugin came to be.
Thanks again for your input, and let me know if anything else comes to mind...
Happy Day

@poddingue FYI: I posted the "Feature Request" to the feedback channel here as you suggested.
Hopefully if enough people were used to the way VMware allowed "multiple granular permissions to be set per VM", it will get some traction. Thanks again for pointing me in the right direction.
Happy Day

@poddingue Thank you for the feedback, and suggestion. I will post a request regarding the one-ACL-per-VM issue, as I know it's an issue with our current 600+ VM VMware-to-XCP-ng migration project. Happy Day

UPDATE: Tag-Based-Automation Plugin

WHAT: The xo-tag-automation plugin is a native xo-server plugin that enforces VM performance tiers, manages group permissions, and synchronizes VM metadata -- all driven by VM tags and NFS-hosted CSV files (see below for more details). In general only apply one performance and/or permission action tag per VM. Note: Currently XO only allows one ACL assignment per VM (e.g. assigning "Dept1-Operator", and" Dept3-Admin" to the same VM does not work).

So brace yourself as there's a lot to chew below,, but I promise if your actively involved with a sizable migration project like we are (a.k.a. "Who can afford VMware anymore?"), it will be well worth your time once you have the plugin setup and running (especially in the "Set-it and Forget-it" Permissions AutoPiolot mode). Enjoy....

FEATURES

---

PERFORMANCE SYNC
Automatically applies CPU weights and IO priorities (sched-pri) based on VM performance tier tags:

0-core   -- CPU weight: 2048  IO priority: 7
1-high   -- CPU weight: 1024  IO priority: 7
2-normal -- CPU weight: 512   IO priority: 5
3-low    -- CPU weight: 256   IO priority: 2

All tier weights and IO priorities are fully configurable in the plugin UI. Note: Under normal conditions these performance settings do not affect anything. It's only when system resources are under high-load that the tiering levels ensure important VMs get priority over non-critical workloads, etc.

---

PERMISSION SYNC
VM tags ending in -Admin, -Operator, or -Viewer (e.g. "Dept1-Operator", "Dept2-Admin", etc.) automatically trigger appropriate XO Group creation and ACL assignments for the designated VM.

CSV PERMISSION MANAGEMENT FILES
Two CSV files on your NFS share drive the workflow:

current-vms.csv
A live export of your entire VM inventory. Contains UUID, Name, CurrentTags, NewTags, CurrentNotes, and NewNotes columns. Edit the NewTags and NewNotes columns and run the plugin (e.g. push the [Test plugin] button) to apply changes in bulk. The CSV auto-refreshes after each run. A staleness warning fires if the CSV has not been updated within a configurable number of days.

preload-vms.csv
Pre-stage tag and notes configurations for VMs that do not exist yet -- before they are migrated or created. The moment a VM matching a preload entry appears in XO, the plugin applies (on next scheduled interval) its tags and notes automatically and removes the entry from the preload file.

---

PERMISSION AUTOPILOT
Designed for active migration and onboarding projects. Automatically applies permission settings on scheduled interval, based on preload-vms.csv contents. Note: Should be disabled when not actively involved in migration projects.

---

DRY-RUN / EXPORT-CSV MODE
When Dry-Run is ON (the default), the plugin previews all changes in the XO logs without applying any changes, and simultaneously exports a fresh copy of all VM metadata to current-vms.csv with blank NewTags and NewNotes columns ready to fill in. Turn Dry-Run OFF to apply changes for real.

---

RUN NOW (e.g. The [Test plugin] button)
Trigger a full enforcement cycle instantly from the XO plugin UI without waiting for the next scheduled run.

---

NFS LOGGING
All activity is written to structured log files on your NFS share:

xo-tag-automation.log         -- full run log (auto-rotates at 2MB)
xo-tag-automation.log.1      -- previous log backup
xo-tag-automation-summary.log -- run summary entries only
daily-summary.log             -- nightly VM count and new VM report

Logs are also available via xo-cli API methods (see below).

---

LEGACY MIGRATION
If you have an existing vm_metadata.csv from an older version, the plugin automatically renames it to current-vms.csv on first run. No manual migration needed.

---

SECURITY -- PLEASE READ CAREFULLY

This plugin automates infrastructure changes. Security is not optional. Please take both of the following seriously before enabling Permission Sync or Autopilot.

---

-- REST API SERVICE ACCOUNT --

This plugin uses the XO JSON-RPC API internally. Use a dedicated service account (never your personal admin credentials). Note: REST API is only required for the Permissions Sync functions, it's not required if you just want to use the Performance Sync plugin functionality.

Recommended setup (generic -- adapt to your environment):

1. Create a dedicated XO user account for the service (e.g. a non-admin account with only the minimal access permissions required)

2. Generate a scoped API token via xo-cli:
   xo-cli --register
   xo-cli token.create

3. Store the token securely -- treat it like a password!

4. Refer to the official Vates REST API documentation for full token management guidance:
   https://xen-orchestra.com/docs/restapi.html

---

-- NFS SHARE SECURITY --

The NFS share hosts your CSV files and logs. Anyone with write access to the share can modify VM tags and permissions.

STRONGLY RECOMMENDED

• Run the NFS share from a dedicated VM -- not a general-purpose NFS server.

• Restrict NFS exports to the XOA IP address only:
  /srv/nfs/share<XOAIP>/32(rw,sync,no_subtree_check,no_root_squash)

• Do NOT expose the NFS share to the general network or to end-user access.

• Admins who need to edit CSV files can SCP them to/from the XOA:
  EXAMPLE:
  Download CSV from XOA to your workstation
  scp <xoa-user>@<xoa-ip>:/path/to/current-vms.csv ./

  Upload edited CSV back to XOA
  scp ./current-vms.csv <xoa-user>@<xoa-ip>:/path/to/current-vms.csv

• Use firewall rules to enforce NFS access at the network level in addition to the exports configuration

Failure to secure the NFS share is a serious security risk.

---

UPGRADING FROM THE STANDALONE SCRIPT

If you installed the old standalone set-performance.sh script, you can remove it before enabling the plugin as follows:

1. Remove the script:

   sudo rm /usr/local/bin/set-performance.sh
   

2. Remove the crontab entry:

     crontab -e
     (delete the line referencing set-performance.sh)
   

3. Note: The plugin handles its own scheduling via the XO UI. No manual cron configuration is required.

---

INSTALLATION

1. Download the latest airgap release tarball from GitHub:
   https://github.com/johnezero/xo-tag-automation_plugin/releases

2. SCP the tarball to your XOA:

   scp xo-tag-automation-airgap-vX.X.X.tar.gz <xoa-user>@<xoa-ip>:/tmp/
   

3. Create the plugin folder:

   sudo mkdir -p /usr/local/lib/node_modules/xo-server-tag-automation
   

4. Extract directly into the plugin directory:

   sudo tar -xzvf /tmp/xo-tag-automation-airgap-vX.X.X.tar.gz -C /usr/local/lib/node_modules/xo-server-tag-automation/ --strip-components=1
   

5. Restart xo-server:

   sudo systemctl restart xo-server
   

6. Verify registration:

   sudo journalctl -u xo-server -n 100 --no-pager | grep -A3 "tag-automation"
   

   You should see:

   [INFO] xo-tag-automation: Plugin factory called -- xo context: YES
   [INFO] xo-tag-automation: Plugin loaded -- waiting for core started.
   xo:plugin INFO successfully register tag-automation
   

7. Enable and configure the plugin options in XO:
   Settings -> Plugins -> tag-automation -> Enable

---

XO-CLI API METHODS

The plugin exposes several API methods accessible via xo-cli:

xo-cli xo-server-tag-automation.exportCsv
Export current VM inventory to current-vms.csv

xo-cli xo-server-tag-automation.downloadCsvApi
Print CSV content to stdout

xo-cli xo-server-tag-automation.uploadCsvApi content@./current-vms.csv
Push an edited CSV back to the NFS share

xo-cli xo-server-tag-automation.getLog lines=100
View the last N lines of the plugin log

xo-cli xo-server-tag-automation.getDailySummary
View the nightly VM count summary

xo-cli xo-server-tag-automation.getFilePaths
Show all configured file paths

---

LINKS

GitHub: https://github.com/johnezero/xo-tag-automation_plugin
Vates REST API docs: https://xen-orchestra.com/docs/restapi.html

---

STANDARD DISCLAIMER HERE

This software is provided "AS-IS" without any express or implied warranty. While this plugin is being used in a production environment managing live VMs, you should always review the code and test it in a non-production environment before full deployment.
Note: The plugin is designed to ONLY take action on VMs with specific tags assigned (e.g. untagged VMs are never modified).
Use Dry-Run mode to preview all changes (via log file output) before applying them.

Feedback, input and suggestions and always welcome...

@poddingue Thank you!
"Anything and Everything we can to to improve XCP-ng", is the "Name of the Game"

@tjkreidl Yes, it's all good! Happy Day

@tjkreidl Found it. I re-posted the topic back to the hardware category (and linked the pdf's to the #tobiaskreidl github) here:
Server Admin Guide: A Tale of Two Servers: BIOS, GPU, and NUMA Tuning for XCP-ng: Preserving the valuable work done by Tobias Kreidl (@tjkreidl)