@olivierlambert The update has fixed it, thanks!

@Zevgeny For a few snapshots it's fine - the issue comes when you have large numbers. Most of my first-hand experience with this specific issue comes from Hyper-V but the logic applies here. This is from VMware but the concept is the same and has some good reading on snapshots in general. Running a virtual machine on a snapshot for extended periods of time can cause instability and data loss. https://kb.vmware.com/s/article/1015180 The underlying issue stems from the nature of snapshots. With none you have a single VHD containing all of the data for the VM, once you take a snapshot a new delta VHD is created with all new data written going forward from the time of the snapshot. So, in order to have a complete VM you have the original VHD + the delta VHD. This is fine in smaller numbers, but once you start having 10, 15, 20+ snapshots, every one of those represents an additional VHD in the chain. This results in performance degradation because you're reading from multiple potential files as only new data is written to the deltas. This is actually from XO's blog: https://xen-orchestra.com/blog/xenserver-coalesce-detection-in-xen-orchestra/

@Zevgeny Did you succeed to remove the protection with "xe vm-param-clear"? It didn't worked perfectly for me. Before I use xe vm-param-clear, I have the following: [18:28 xcpng02 ~]# xe vm-param-list uuid=37b7a201-eb45-b7de-5ce4-da25b1c7b547 | grep block blocked-operations (MRW): pause: true; hard_shutdown: true; (unknown operation): true; hard_reboot: true; clean_shutdown: true; suspend: true; clean_reboot: true [18:28 xcpng02 ~]# Now I try to clean: [18:28 xcpng02 ~]# xe vm-param-clear uuid=37b7a201-eb45-b7de-5ce4-da25b1c7b547 param-name=blocked-operations The value given is invalid field: blocked_operation value: (unknown operation) [18:28 xcpng02 ~]# After, "blocked-operations" looks like this: [18:28 xcpng02 ~]# xe vm-param-list uuid=37b7a201-eb45-b7de-5ce4-da25b1c7b547 | grep block blocked-operations (MRW): (unknown operation): true; hard_reboot: true; clean_shutdown: true; suspend: true; clean_reboot: true [18:30 xcpng02 ~]# In the GUI of XOA, the "Protect from accidental shutdown" is removed but not on the command line.

@fohdeesha said in Preventing "new network" detection on different XCP-NG hosts: @Zevgeny As you suspected, this is caused by the VMs booting with new & fresh MAC addresses they've never seen before, which from their point of view means an entirely new NIC. The "clean" solution here would be to have an option or toggle inside of XOA backup jobs, that allows MAC addresses to be preserved - this way the replicated DR VMs on the backup site still have the same MAC addresses. This could be something you could file as a feature request on our github However note that pretty much any VM copy/replicate action will trigger xen to generate a new MAC address (for safety, duplicated MACs are usually bad). This means that even if the MAC is preserved to the DR VMs, when your admin copies the DR VMs and boots them, the new copies will have newly generated MACs. I suppose it would be possible to add a "preserve MAC" checkbox for copy operations too, but I'm not sure if XAPI currently exposes such functionality. Yea, keeping the mac adress would really solve this. We actually edit the mac adress manually on the copied VM's incase we need to start the DR copy up for testing.

@zevgeny Hi, yes this can be easily done by just creating a new network as you described. VMs will be able to access anything in that network/subnet without extra configuration. If they ever need to talk to things outside of that network/subnet (like the internet), they would need a router to route the traffic between subnets

It's not that complicated: it's in a folder with the UUID of the backup job, then the VM is within it's UUID folder. That's it.

@zevgeny Hi, You can export the config for your XOA in Settings > Config > Export and import it on your new XOA

This need to be groomed first. But we are pretty tight this month. Ping @marcungeschikts

Hello @Zevgeny . Finally, we won't be able to display if the vm has changed since the snapshot.

@jaayb Amazing, TYSM!

@olivierlambert Ok, thanks. I will create another topic for the display issue.

@olivierlambert having exactly the same issue as wcom939 reported. What did you mean by "Can you try with xe command to see if you have the same error?" ? Migrate using CLI? there are too many options:)

Hard to tell. If it happens again, try immediately to compare XO behavior with other clients to see if we can tell where is the problem