john.c

@SylvainB said in WORM Backups with XCP-ng / Xen Orchestra - Seeking Solutions & Experience:

Hello everyone,

I'm exploring options for implementing WORM (Write Once, Read Many) capabilities for my backups within my XCP-ng environment, specifically using Xen Orchestra.

My current setup:

• XCP-ng Version: 8.3
• Xen Orchestra Version: 5.106.4 (Stable)
• Intended Backup Target: Synology NAS

My primary goal is to ensure that my backup data, once written, becomes immutable for a defined retention period, offering protection against accidental deletion or ransomware attacks.

My questions are:

1. Does Xen Orchestra offer any native WORM features or integrations that I might be overlooking for its backup jobs?
2. If not directly, has anyone successfully implemented WORM backups with a similar perimeter (XCP-ng, Xen Orchestra, and potentially a Synology NAS or other storage solution)? I'm very interested in learning about your setup, the specific technologies you used (e.g., storage features, specific configurations), and any lessons learned or best practices.

Any insights, architectural recommendations, or shared experiences would be highly valuable.

Thank you in advance for your help!

Best regards,

SylvainB

You can setup in the Synology its WriteOnce feature, then configure the appropriate configuration settings, including retention ones.

This will prepare the appropriate WORM environment you’re looking for. It will work well due it being the equivalent to Vates solution and/or the S3 based one.

https://kb.synology.com/en-in/search?tags[]=WriteOnce

@afk said:

Hi everyone,

Some of you may already be aware of this but I learned the news this morning.

https://www.virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads/

Essentially, Broadcom has decided, without any announcement, to remove all download links (and even some documentation it seems) for VDDK.
This impacts all migration tools that use the VDDK for copying data of VM disks.

If you have any version of VDDK, please keep it somewhere safe and make backups.

I only have a x86-64 linux release from september 2025 that I used for testing V2V. Obviously, I can't share any link here but the release has the following sha256 hash:

79d215198f1b8fd1d240a16b27ac2543c521ae2afdc1876444c2acf8945d74ca VMware-vix-disklib-9.0.0.0.24742305.x86_64.tar.gz

Apparently, web archival links are also taken down.

@olivierlambert
With Broadcom removing public access to VDDK downloads, we now have users who either cannot obtain VDDK at all or whose existing VDDK installations (main + backup) have become corrupted.

This creates a real need for a fully open‑source fallback path inside V2V, one that still meets the performance requirements normally associated with VDDK.

The open‑source community has already demonstrated that VDDK‑level throughput is achievable without VMware’s proprietary stack. Several projects have shown that:

• Parallel NBD can saturate modern storage bandwidth when implemented correctly
• Highly multithreaded block pipelines can outperform single‑threaded VDDK transfers
• A throwaway Linux Proxy Copy VM can act as an efficient intermediary, reading blocks via NBD and streaming them directly to the destination hypervisor.

This approach avoids VDDK entirely, remains fully open source, and provides a reliable fallback for users who can no longer access VMware’s proprietary components.

Given the direction Broadcom is taking, having this fallback inside V2V would significantly improve resilience for XCP‑ng users and ensure long‑term independence from VMware licensing changes.

The Proxy Copy VM must be treated as an ephemeral orchestration component — automatically excluded from the migration set and destroyed once the transfer completes — ensuring it never interferes with HA, LB, or startup/shutdown sequencing.

This architecture also gives Vates a clean, open‑source answer to Broadcom’s decision to pull public VDDK access — ensuring V2V remains fully functional even if VMware continues removing or restricting proprietary components.

@wtdrisco said in Hosts compatibility:

As I am starting to build an environment for testing to replace VMWare, I had a question related to hardware.

When setting up multiple hosts, do these need to match the same specs (like VMWare?) for HA (moving VMs from host to host)?

I have several DELL R series servers, and some do not have the exact same CPU model or one has less memory than the other.

When setting up (HOST POOLS??) if I needed to migrate VMs, will this support different host configurations?

If the the hosts don't match by close enough, especially if their capabilities (e.g. instruction sets) and specifications. Then in the case of capabilities then the non-matching ones will be suppressed by XCP-ng so that they all match. Also when migrating the specifications, of hosts really need to match so that when VMs are placed on the hosts. There's no issues when live migrating between the each of the pool member hosts.

As the VMs expect at least a certain number of cores dependent on the hosts, and the number specified per each VM. If this number isn't met then that VM can't migrate to a specific host, which don't meet or exceed it.

@ThierryC01 said in XCP-ng 8.3 betas and RCs feedback :

@bleader Update successful, no issue so far. There is just a message appearing when starting the update: "Delta RPMs disabled because /usr/bin/applydeltarpm not installed."

All VM working for now.

That's harmless. It's just notifying that the system doesn't have deltarpm package installed. This package reduces the size of updates based on what's already installed.

@still_at_work said in First SMAPIv3 driver is available in preview:

Hello @olivierlambert ,

I am joining this topic as I have a few questions about SMAPIv3:

• Will it allow provisioning of VDIs larger than 2TB?

• Will it enable thin provisioning on iSCSI SRs?

Currently, the blockers I encounter are related to my iSCSI storage. This is a major differentiating factor compared to other vendors, and resolving these blockers would significantly increase your market share.

Thanks !

@still_at_work The size limit of the VDI is due to the file format used for these, which is VHD (https://en.wikipedia.org/wiki/VHD_(file_format)). This format can't support more than 2TB, it's known about and are dealing with the issue. It will likely result in a change or addition of a new VDI format likely to be qcow2 unless necessary software for VHDX format is fully open sourced and software for Xen is created which enables create, read, write and use of this format.

It's not a limitation of iSCSI as it also emerges with both NFS and SMB based connections.

@jasonnix The Linux distribution operating system restricts certain commands, operations and/or path (location) to the root account, as well as the location owner.

The path your trying to write to is just one such location as the location is read only to non-root users. If you really wish to write to /usr/local/src then root account is required.

If you use the root account to install then the directory and the Xen Orchestra files will be owner by root. You would need to create a non-root user for the xen orchestra server process. As well as change ownership of the Xen Orchestra files and folders to that non-root account. Though at least the ones which Xen Orchestra should be able to modify as required, when needed.

As well as provide the necessary sudo permissions for the necessary commands to that account.

Using root account to run exposes any vulnerabilities present to the capacity of being exploited as root (aka Administrator) privileges.

Also how good is your internet connection and your connection to GitHub? Cause you could be experiencing a time out packet loss connection issue.

@Octopuss said in ️ XO 6: dedicated thread for all your feedback!:

@olivierlambert Well ok, it's just that last time I tried to ask about stuff I was politely told off because I used the installation script instead of paying (that's not the literal formulation but it's basically what the person responding meant).

I know nothing about any blogs, I just check the main xcp website (FFS I am not even allowed to post links, what a forum...) from time to time, so I have no idea. I just updated the admin interfce for the first time since moving over from ESXi, and was puzzled why it looked the same as the "castrated" lite version when previously (which means v5, apparently) it was full of features. I had no idea it wasn't a completed product.

TL;DR: I am just an idiot who installed this few months ago and has no idea about the details. shrug

You were told off if the script was 3rd party because officially, the scripts may have made changes to the Xen Orchestra source code prior to compilation. They have a set of steps, for building from source which are able to receive support in the forums for. Anyway getting paid support if an organisation is best as their pro support is top notch!

With the blogs which are being referred to are under the “News” links. Which detail releases and other news worthy information.

You can post links but it does take some work, also make sure you’ve read the rules, also going through the introduction training which a forum function bot runs. Doing this will eventually earn you more access and feature functionality. It’ll help you get used to the forums functions.

The XO 6 is a minimum viable product currently, but is growing from there as features from v5 transitions to v6. If there’s features missing from v5 and v6 that are needed please enter them on the Feedback portal, so they can be voted on. It’s link is in several XOA update and release news posts (especially 6.0 and 6.1).

Read both these posts along with others along the way, it will help you get caught up on all of the Xen Orchestra releases and updates.

@olivierlambert said:

@john.c I really liked your "Jean C." signature before your edit You should keep it

I learned a bit of French in 6th form college many years ago now, as part of learning your culture. As part of a Skillpower course unit assignment. As part of this course during Sept 2001 to Summer 2006 went on an academic day trip visit to Boulogne, France.

But it was to a level that was useful for when going on holidays, so wasn’t very fluent.

@jeremie1977 said:

Bonjour,
Nous sommes en plein POC de Vates et je test le build de nos images RHEL avec Packer (d'ailleurs un grand merci à @bvivi57 et @ataxyanetwork pour les tutos et exemples qui m'ont fait gagner un temps précieux ^^ ).

J'ai remarqué que le paramètre "cd_files" ne permettait pas de monter le kickstart au boot
Le provider expose cd_files, mais le contenu n'est pas visible par l'installeur (ou n'est pas attaché à la VM...je n'ai pas sût identifier).
J'ai même tenté avec "floppy_files"...idem.
Est-ce normal ? Voulu ?

Du coup, dans des environnements sans DHCP pendant l'installation, cela empêche l'utilisation d'un kickstart embarqué et oblige à mettre en place une IP via la "boot_command" avec une configuration réseau statique (ce qui oblige a multiplié les builds si plusieurs environnements/site)
Rien de dramatique en soit mais sur les provider Packer Vmware et Nutanix que nous utilisons par ex, cd_files nous permet de couvrir les environnements isolés (air-gapped) et/ou sans DHCP et simplifie grandement les builds automatisés en rendant le code le plus idempotent possible.

L'intérêt est multiple :
Environnements air-gapped : aucun serveur HTTP nécessaire.
Moins de dépendances : le build est autonome.
Compatibilité avec les autres builders Packer (VMware, Nutanix, QEMU...), où nous utilisons cette fonctionnalité pour nos Builds
Sécurité : le kickstart n'est pas exposé sur le réseau, même temporairement.

Si la raison pour laquelle le fichier Kickstart ne peut pas être connecté en réseau ou autrement accessible, c'est parce qu'il contient des secrets. Cela peut valoir la peine de regarder et de vérifier le logiciel de service de détenteur sécurisé secret OpenBao (https://openbao.org/). Qui est un fork public open source de Hashicorp Vault, avant l'entrée en vigueur de la licence BUSL dans les versions ultérieures de Vault. Un autre conseil utile est de combiner l'isolation du masque de sous-réseau avec l'isolation basée sur le VLAN.

Quoi qu'il en soit, saviez-vous qu'une instance de Cockpit, exécutant Cockpit Image Builder peut être utilisée comme Packer, pour créer des images "dorées" de VM via OSBuild ?

Quoi qu'il en soit, bonjour et bienvenue dans la communauté Vates VMS, j'espère que vous la trouverez utile, épanouissante, accueillante et/ou amusante.

Sincèrement,

Jean C.

@olivierlambert I created the issue on GithHub. https://github.com/vatesfr/xen-orchestra/issues/7884