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 
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)?
We're migrating our VM's to 2 new hosts (non-pool hosts) - The 1 pool has been live now for 2 months and I can see there are patches to be installed:
8.2.1
release/yangtze/master/58
We're busy setting up the next host and there will be initial patching. How can I setup the new host and patch it to the same version above so that we're able to have these 2 hosts on the same patch level? We're unable to shutdown the old host as there is too many running VM's and want to ensure we don't have differences in the versions.
Using the XOA can this be done or would we need to update using the command line? And if so, how can I achieve this?
@dredge999 yeah in hindsight thats what I should have done I wonder if I can restore the config files and have the VM operational again. It's more getting it to stop now without a host restart
2 points
Good news is this was a non-critical VM, losing it wouldnt be a big issue, however, I want to learn from this experience on how to potentially fix it.
First issue I see is that the VM is now stuck on the origin host as the config files are missing. How can I "remove" this VM so that it no longer shows as a running VM?
Then, I have the VHD file on the original host, it fortunately was not deleted. How do I create a new VM with this disk? I assume the disk is still "mounted" to the broken VM, so where do I start with this process?
The worst result, I migrated a VM from 1 standalone host to another. After some time I went back to see progress and see there are no pending tasks. The VM is not on the new host, and it seems to still "be" on the old host but it's non responsive. Console does nothing, cannot shut it down with an error indicating "Config" for the VM is missing:
Here is the migration log:
vm.migrate
{
"vm": "429077f8-2582-5932-71f2-27cc30123754",
"force": true,
"mapVifsNetworks": {
"05bc9d14-24b2-42e5-a7df-3bf6b46720dd": "dd8d028b-71a5-b9b8-7efc-4e03261dc90a"
},
"migrationNetwork": "48e4aeaf-af9c-dd97-8af6-93e48df0353e",
"sr": "0d5c70cc-57d4-e770-1b06-11e052cde02c",
"targetHost": "551aa992-eeab-4ce6-9d9e-87dd3e7551dc"
}
{
"code": 21,
"data": {
"objectId": "429077f8-2582-5932-71f2-27cc30123754",
"code": "INTERNAL_ERROR"
},
"message": "operation failed",
"name": "XoError",
"stack": "XoError: operation failed
at operationFailed (/home/xo5/xen-orchestra/packages/xo-common/api-errors.js:26:11)
at file:///home/xo5/xen-orchestra/packages/xo-server/src/api/vm.mjs:497:15
at runMicrotasks (<anonymous>)
at runNextTicks (node:internal/process/task_queues:61:5)
at processImmediate (node:internal/timers:437:9)
at process.callbackTrampoline (node:internal/async_hooks:130:17)
at Xo.migrate (file:///home/xo5/xen-orchestra/packages/xo-server/src/api/vm.mjs:483:3)
at Api.#callApiMethod (file:///home/xo5/xen-orchestra/packages/xo-server/src/xo-mixins/api.mjs:394:20)"
}
When I try to shutdown the VM on the old host:
vm.stop
{
"id": "429077f8-2582-5932-71f2-27cc30123754",
"force": true,
"bypassBlockedOperation": false
}
{
"code": "INTERNAL_ERROR",
"params": [
"Object with type VM and id 429077f8-2582-5932-71f2-27cc30123754/config does not exist in xenopsd"
],
"task": {
"uuid": "3c0f9353-d694-6ccf-8d5c-bf68a508d74a",
"name_label": "Async.VM.hard_shutdown",
"name_description": "",
"allowed_operations": [],
"current_operations": {},
"created": "20230324T13:57:32Z",
"finished": "20230324T13:57:32Z",
"status": "failure",
"resident_on": "OpaqueRef:4649e134-1941-4655-b731-7e96455226f5",
"progress": 1,
"type": "<none/>",
"result": "",
"error_info": [
"INTERNAL_ERROR",
"Object with type VM and id 429077f8-2582-5932-71f2-27cc30123754/config does not exist in xenopsd"
],
"other_config": {},
"subtask_of": "OpaqueRef:NULL",
"subtasks": [],
"backtrace": "(((process xenopsd-xc)(filename lib/xenops_utils.ml)(line 391))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 1922))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 2064))((process xenopsd-xc)(filename list.ml)(line 121))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 2057))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 2213))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 2746))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 2756))((process xenopsd-xc)(filename lib/xenops_server.ml)(line 2775))((process xenopsd-xc)(filename lib/task_server.ml)(line 177))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3302))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3470))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3742))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3740))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3311))((process xapi)(filename lib/backtrace.ml)(line 210))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3317))((process xapi)(filename ocaml/xapi/xapi_vm.ml)(line 438))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 131))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/rbac.ml)(line 233))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 104)))"
},
"message": "INTERNAL_ERROR(Object with type VM and id 429077f8-2582-5932-71f2-27cc30123754/config does not exist in xenopsd)",
"name": "XapiError",
"stack": "XapiError: INTERNAL_ERROR(Object with type VM and id 429077f8-2582-5932-71f2-27cc30123754/config does not exist in xenopsd)
at Function.wrap (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/_XapiError.js:16:12)
at _default (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/_getTaskResult.js:11:29)
at Xapi._addRecordToCache (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/index.js:954:24)
at forEach (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/index.js:988:14)
at Array.forEach (<anonymous>)
at Xapi._processEvents (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/index.js:978:12)
at Xapi._watchEvents (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/index.js:1144:14)"
}
Any ideas?
We're planning this for tomorrow so any last minute thoughts will greatly be appreciated.
We have a NAS we want to share between hosts. There are 3 hosts in total. 2 of these are our "primary" hosts, each has 2 SR's.
We want to setup a CR backup to replicate Server 1 SR 1 to Server 2 SR2 and Server2 SR1 to Server 1 SR2 as part of a availability job. I have opened a support ticket and Yannick recommends we keep the 2 hypervisors in their own pools, however, he says it is indeed possible for us to create a replication job the way we envision below. The problem is just that we're going into production with this so curious if there are others doing something similar and if there is a chance we may run into unknown issues down the line? As I now know one cannot simply remove a host from a pool without destroying all vm's on the local SR, I am worried that we go ahead with this and we end up with a case where the CR does not work as planned and at that time have to figure out a way to reset and do over.
So, in a nutshell, is there a chance we may run into issues down the line? Should we rather keep the servers in seperate pools and only have 1 of the 2 hypervisors have access to the NAS and if the hypervisor goes down we can then figure out how to move it to the other hosts?
Thank you @olivierlambert
So in principle there would be no concern with the design of having 2 hypervisors each with 2x local storage repositories each, and each replicating it's storage to another hypervisor in the same pool? Sorry for being anal about this, as we're going into production with this I'm just trying to be prepared for some strange scenario that can occur? Is this a common practice?
Also, if I do CR, how do I avoid 2 VM's being backed up as we only want to backup the primary / running VM?
We're busy migrating from numerous hypervisors to 2 primary ones with each hypervisor (XCP) having 2 separate storage repositories into a single pool so that they can share a common NAS. We want to setup continuous replication from server A SR1 > server B SR2 and same server B SR1 > server A SR2. This will also allow for the hosts to share a common NAS.
Are there any risks or is this frowned upon to replicate a VM within the same pool? I recall having an issue in the past with a duplicate GUID issue, but not sure if that was applicable to this problem?
The XO team is also bringing the magic!
I know I cannot migrate / CR from a newer to older hypervisor version, so not sure if same applies for older to newer migration / CR
Server A is slightly older than Server B (XCP version) - Can Server A CR a VM to Server B and will it start?