@Danp I was going to do the upgrade over the December / January Christmas break in Australia but that is when this issue became apparent so we didn't want to be making major changes until it was resolved.
I note @anthoineb noted the first report was late August / September 2025 which was just before 8.2.1 reached EOL, so it would be a shame not to have a fix for it tested on 8.2.1 as it seems an upgrade to 8.3 would be unwise while we still have this issue?
@Rod-G
These have 9.4.2-xxxx and I need to go through and update everything now that I see how far behind I am.
the second VM completed fine after its reboot, something was just stuck in a dirty state and got in the way of the import or health check.
Kubernetes CSI Driver for XO new release v0.3.0
Stable CSI Volume Identity: This decouples Kubernetes volume identity from backend storage lifecycle events (e.g. VDI migration between Storage Repositories)
Topology-Aware Volume Provisioning: Dynamic provisioning now supports topology-aware pool selection.
️ Migration required from v0.2.0 to v0.3.0
Full release note: https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.3.0
@kent
You can ask for a trial so you can do it the time you need
If you use XO from the sources, you will have the feature for free (but without support/updater and such)
At first glance, it does not seem so easy.
First, we will implement this feature in XO Lite (soon). We will then see if there is a trivial way to adapt the changes in XO5
This was ultimately traced to a currupted metadata on the VHD and to a stuck tapdisk process on the host where the VM was running.
Solved thanks to a very persistent member of support. Thanks Jon!
@sluflyer06 the warning on XO is to discourage the mass. But you can really try
you can make a config.toml file in ~/.config/xo-server/config.*.toml , it should be loaded , and won't be changed by an XO update . https://github.com/JsCommunity/app-conf
@HeMaN this may have actually worked...
In etc/network/interfaces
The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
This is an autoconfigured IPv6 interface
iface eth0 inet6 auto
post-up route add default via 10.10.10.1 dev eth0
auto eth1
iface eth1 inet static
address 10.10.5.188
post-up route del default dev eth1
Then I don't see why it would be a XO problem
FYI, we use JSON-RPC over websockets. Hopefully, someone at Teleport community would be able to pinpoint the problem
Hi,
In XO Hub, you already have a Debian 11 which is Cloudinit ready This is more a Cloudinit question BTW, you should ask their community. Frankly, Cloudinit doc isn't great and many things changed a lot
@mauzilla There is no easy way to achieve that, it requires updating a number of other_config entries manually.
If you have a paid subscription, open a support ticket and I'll take care of it for you
@MrNaz It merges the past delta backup into the past full backup. Then it does a delta backup..... then you repeat.... Since you only keep one copy it just keeps merging the delta into the full backup. The delta backup depends on the old full backup existing and being correct.
When it does a "full backup", it does a full backup of the data not just a delta (the changes). That way it does not merge the new full backup into the old full backup (or depend upon any old backups). Doing a full backup is a good checkpoint in case the old data (full or deltas) is corrupted.
So having the retention set to 1 basically means you only have the most current backup saved. With backups every 12 hours you might want to set the retention to 20 so you have about 10 days of backups and every 5 days (10 backups) it will do a full backup. Or set it higher if you have more backup space.
@Danp Thanks RAM was problem. There was only 1.5GB, which was default value with XCP-ng center. Now it compiled successfully with 4GB.
[image: 1684340422417-28e1c460-9d67-44b4-b018-96d1b9531bc7-obraz.png]
Hi,
No easily, no (at XCP-ng level at least). Maybe in the future with Open metrics everywhere.
You can already track a VM metrics whatever they move to by having VM metrics from within the VM itself (eg VM is sending its metrics via netdata to a central netdata that will store them in Prometheus for example).
