You guys are absolute rockstarts! Yannick connected and was able to resolve the issue, thank you again for all of your hard work!

@olivierlambert strange one, thank you Olivier, I created a ticket 7714072

Thank you all seems I've got my answer, will go core

@olivierlambert you're a grandmaster, never even considered that It seems to be stuck but likely firewall will have a look thank you

Just checking if there is any impact in XCP-NG and / or XO that may be impacted by the log4j vulerability? Not sure if some of the API's uses java?

@olivierlambert Perfect, setting the parameter on both the VM and the snapshot resolves the issue. I am able to continue backups Thank you both for helping!

Okay let me rephrase, is there then an option to "move" a VM's backup from 1 backup to another. This is simply to avoid having to restart the backup process on some of them?

VM is backup on with delta backups on hypervisor 1 with a backup called "Backup Weekly" - I now want to move that backup to a new Backup called "Host 1 Backup Weekly" - Everything stays the same, destinations etc, it's only that a CR process will also be added now to the new backup.

Can I change the snapshot name to form part of a different backup?

We need to seperate our backups to not be part of a collective but on a "per host" level. Everything stays the same, accept for a CR that we have different (host a > host b and host b > host) - As we've already got these backups running, is it possible to change some tags on the VM's and seperate them into the jobs without having to start a complete new backup?

You guys are absolute rockstarts! Yannick connected and was able to resolve the issue, thank you again for all of your hard work!

@olivierlambert strange one, thank you Olivier, I created a ticket 7714072

@olivierlambert Alright I created the conf file described here:

https://xcp-ng.org/docs/api.html#_24h-task-timeout

I then did a xe-toolstack-restart (which I assume is needed to updated the configuration). Restart had no errors, said "done" - but the toolstack isnt coming online, when I try and reconnect I get a connection refused, and accessing the host (https://10.1.3.8) also returns connection refused.

I then deleted the file created, and restarted the toolstack again:

[15:38 jerry xapi.conf.d]# xe-toolstack-restart
Executing xe-toolstack-restart
done.
[15:38 jerry xapi.conf.d]#

Nothing appears give an indication that something is broken. Is there a log somewhere I can have a look at to see what error may have occurred?

Just another reason why XCP / XO is the best! Just ran into this exact same issue and boom, you guys have it sorted

1 question, must the XAPI change be setup on both hosts (so the sending and receiving server)?

So migrated our XO VM to another host and I assume the last step is that it migrates the network data and obviously at the time where it stopped the XO network on the origin server, it also stopped it from copying accross the network info.

The VM is running on the new host but we cannot remove the network entry, it says that the object does not exist. I understand why but wondering if we can fix this as I am worried it may cause issues down the line. It seems that we can add new interfaces so we'll get the VM running again, just want to use this as a practical learning curve.

Another question is, if I want to re-use the disk (so create a new VM from the disk), what steps should I take? I also noted that there is a copy button on the disk tab for a SR, but it does not seem to do or trigger anything

Any tips would greatly be appreciated

works like a charm, thank you gents!

So after the install I can see the version and build is already the same (master/58 8.2.1), but the new host has 45 patches to be installed. Does the individual patches also influence the migration restriction or do you look at the build / version?

@olivierlambert off course and accept it that way, just trying a workaround as 2 of the 3 hosts now is on the same level (with 5 due patches) - Updating the 3rd (new host) will install it with the newest patches, which will lead to us not being able to migrate VM's between the 3. Hoping there is a way to get the 3rd one patched to this level, or how does XCP manage the migration check, does it include patches aswell or does it look at the version 8.2.1 (which is the latest)?