@Pilow The backups kept by LTR are just regular backups with a specific tag, which doesn't change how we treat them. If you want to avoid each of your LTR backup to depend on one another, we recommend to set a full backup interval value to your backup job, which will regularly force a full backup. (even without LTR, having an infinite chain of backups can cause problem in the long term, especially if no healthchecks are made)

@kagbasi-ngc Hi, thanks for your thoughts. I get on well with Linux myself - I’m using XO from source following the documentation, and actually, Ronivay’s script, as you mentioned, makes it all even handier. Still, I can’t help but think - your average home user, a total amateur, is just going to land on the XCP-ng host homepage and click "Deploy XOA". And then they’ve no backup, outside of the trial period. But sure, if XOA is aimed squarely at business and enterprise users with paid licences, fair enough that makes perfect sense. I just feel like backup isn’t really a purely business or enterprise feature, unlike, say, proxy instances or hyper-converged storage. It's something even home users would genuinely benefit from. But as it is mentioned above, that’s just how it’s set up - and like you said yourself, everyone’s got the chance to learn something new. And sure, in the age of AI chatbots, there’s really no excuse not to manage it

So it looks like it was a browser cache problem, solved by deleting it.

The plugin was initially created to check RAID created during install, not custom RAIDs created manually. But that could be an improvement to the plugin @stormi I leave you the honor to add this somewhere

Ping @thomas-dkmt

@andriy.sultanov said in "Block migraton" option on the VM´s Advanced tab: @panzersrmm @panzersrmm said in "Block migraton" option on the VM´s Advanced tab: Hi! Is there a VM parameter that saves this "Block migration" UI button? I wasn't able to identify which one it is with command: xe vm-param-list uuid=<VMuuid> Thank you! How do you mean? Is the XO option not persistent? XO sets these parameters: # xe vm-list uuid=$UUID params=blocked-operations blocked-operations (MRW) : pool_migrate: true; migrate_send: true Which you can set like this yourself: # xe vm-param-set uuid=$UUID blocked-operations:migrate_send=true # xe vm-param-set uuid=$UUID blocked-operations:pool_migrate=true @andriy.sultanov Thank you for your answer! That's what I was looking for. I was looking directly at the VM parameters, with xe vm-param-list uuid=$UUID and I was directly searching for "blocked_migration". Now I know what to look for. @olivierlambert Thank you for pinging the appropriate team for the answer.

Hi, You can use delay or if you want specific order, you need to use vApp, that you can configure with the CLI. See https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands

@tjkreidl We don't need performance, but we do need to test how XCP-ng pools, networking, migration, live migration, backup, import from VMware and so on work. It's just a playground where we can have relatively many XCP-ng hosts, but it's not about performance, it's about efficiency and low requirements, because it's just a playground where we learn, validate how things work, and prepare the process for the final migration from VMware to XCP-ng. We originally had two R630s ready for this, then 4, but that would have been unnecessary, given the power consumption, to have physical hypervisors, so in the end we decided to virtualize it all. Well, on ESXi it's because XCP-ng works seamlessly there in nested virtualization.

This requires some extra plugins to be able to do it, and as it's rather "advanced"/not usual for the main XCP-ng use cases (which is connecting to iSCSI/NFS/shared storages, it's not a priority. Which doesn't mean it's not a good idea or interesting, but there's some work to do it and then to maintain it.

qemu-img convert disk_image_fixed.vhd -O vpc -o subformat=dynamic disk_image_dynamic.vhd

@abudef Indeed, the delay is in milliseconds.

Great, it's working fine now

Usually this error is caused by the merge process still running in the background from a previous backup job.

That's exactly it, thank you [image: 1717165046697-1533660b-c0eb-45b1-b81c-ae50d03a4f36-image.png]

Hi, It's not possible.

There is some diff, but not that much between HyperV, ESXi and Xen. However, it's big enough to require a lot of effort to get nested working correctly, one small mistake and your VM is dead.

@lawrencesystems I think this is quite common when you need to test certain scenarios with multiple hypervisors (backup, migrations, etc.). You only need a couple of HVs with a few tiny running VMs. We have done this setup with nested esxi many times for testing purposes. And since e.g. Ubuntu and Windows work this way, the problem is probably specific to Debian (and maybe others?).

Solved by 583c728

Solved by 583c728

To conclude this: @florent and I discussed the issue in a private conversation. I provided the vmdk file that was causing the problem. It turned out that the problem was caused by the vmdk thin file from VMware Workstation Pro, which has a slightly different structure than the vmdk files on ESXi hypervisors. Currently XO imports these files fine and the problem can be considered solved. Thank you very much @florent for your cooperation and help.