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

@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

@peb2 said in XOA letsencrpyt module not setting acmeDomain:

Hello,

I'm new to Xen and XOA (migrating from Vmware) and I was wondering if anyone could help me with a problem.

I'm trying to use the Letsencrypt module as specified in:

https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/mixins/docs/SslCertificate.md?ref=xen-orchestra.com

However, the XOA doesn't seem to be passing the variable for 'acmeDomain' so I get a certificate without a CN.

Has anyone else seen this problem or know what my mistake may be?

Here's my /etc/xo-server/config.toml:

#=====================================================================

# HTTP proxy configuration used by xo-server to fetch resources on the
# Internet.
#
# See: https://github.com/TooTallNate/node-proxy-agent#maps-proxy-protocols-to-httpagent-implementations
#httpProxy = 'http://jsmith:qwerty@proxy.lan:3128'

# Configuration of the embedded HTTP server.
[http]
# If set to true, all HTTP traffic will be redirected to the first
# HTTPs configuration.

redirectToHttps = true

# Basic HTTP.
[[http.listen]]
# Port on which the server is listening on.
port = 80


# Basic HTTPS.
[https]
#
# You can find the list of possible options there https://nodejs.org/docs/latest/api/tls.html#tls.createServer
#
# The only difference is the presence of the certificate and the
# key.

hostname = '0.0.0.0'

[[http.listen]]
port = 443

# Whether to autogenerate a self signed certificate if the `cert` and `file`
# entries could not be found.
#
# Default: true
#autoCert = false
autoCert = true

# File containing the certificate (PEM format).
#
# If a chain of certificates authorities is needed, you may bundle
# them directly in the certificate.
#
# Note: the order of certificates does matter, your certificate
# should come first followed by the certificate of the above
# certificate authority up to the root.
#cert = '/etc/ssl/cert.pem'
cert = '/etc/ssl/xoa.cert.pem'

# File containing the private key (PEM format).
#
# If the key is encrypted, the passphrase will be asked at
# server startup.
#key = '/etc/ssl/key.pem'
key = '/etc/ssl/xoa.key.pem'

# ACME (e.g. Let's Encrypt, ZeroSSL) CA directory
#
# Specifies the URL to the ACME CA's directory.
#
# A identifier `provider/directory` can be passed instead of a URL, see the
# list of supported directories here: https://www.npmjs.com/package/acme-client#directory-urls
#
# Note that the application cannot detect that this value has changed.
#
# In that case delete the certificate and the key files, and restart the
# application to generate new ones.
#
# Default is 'letsencrypt/production'
acmeCa = 'zerossl/production'

# Domain for which the certificate should be created.
#
# This entry is required.
acmeDomain = 'xoa.mydomain.com'

# Optional email address which will be used for the certificate creation.
#
# It will be notified of any issues.
acmeEmail = 'myemail@mydomain.com'

The acmeDomain needs to be the actual Fully Qualified Domain Name (FQDN) which XOA uses. Also some verification and/or validation will need to be added either as a text file to the XOA appliance (in a web accessible directory) or as a DNS text record for XOA FQDN.

Also update the acmeEmail so its the actual email to be used for receiving the notification of issues. These don't look valid to me this is critical for them to be real, active and valid as the ACME Client uses these to send the certificate requests and renewals to the certificate authority!!