Thank you for this constructive argument

Have a nice day.

@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils is installed on the system, something that is present on our doc but might be missing in some install scripts.

We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues

Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome

FYI, this feature has been released

Hey everyone!

The patch is finally here

Sorry for the delay

How to test?

1. Select the latest channel on your XO appliance
2. Upgrade to Xen Orchestra 5.43.2
3. Go to the Proxies page and either Deploy a proxy or upgrade the appliance of your existing ones

What's here?

• Full Backup
• Disaster Recovery

Known limitations/issues

Scheduled for Step 2 at the end of the month.

• Network configuration for the proxy appliance
• Delta Backup
• Continuous Replication
• Detailed logs, they are currently empty
• Restoring backups
  Work-around: create a normal remote (not linked to the proxy) connected to the same storage and import via the XO appliance

Thank you for your feedbacks

Indeed, there is a major issue with the fix, I'm on it.

Sorry for this

Answered on the XO forum, thank you

Indeed, this is an XO bug, incomplete VMs should be ignored by smart mode, we'll fix it in the next releas.

That sounds feasible indeed

Unless the shell option is used, no shell interpreter (Bash, cmd.exe, etc.) is used, so shell features such as variables substitution (echo $PATH) are not allowed.

-- https://github.com/sindresorhus/execa#execafile-arguments-options

AFAIU, execa use spawn which does not do any arguments parsing, those are passed verbatim to the underlying command (probably via a call to execvp).

If we would have used the shell option, this command would indeed run a shell which would have parsed the command line and therefore be susceptible to injection, but we are not using this

@jefftee Hi, this is a display issue related to with memory backups, for more information, take a look at this issue: https://github.com/vatesfr/xen-orchestra/issues/5089

julien-f created this issue in vatesfr/xen-orchestra

open [Backup] suspend_VDI should not be taken in consideration for full qualification #5089

@normanghenderson I'm currently working on this feature, I had hoped to be able to release this for the September release but due to last minute issue it will likely be postponed for the end of October.

Note that this will ship in the proxy first before making its way to regular backups.

Best regards,

Hi,

Did you read the documentation?

Hi, sorry for the delay!

Please read xo-cli's documentation, you need to use JSON when you want to pass non-string values:

xo-cli vm.set id=89517372-b45b-ca36-4c51-dd17c0e760c0 CPUs=json:3

The problem is likely related to quotes and the shell syntax.

Unfortunately, I'm not familiar with it and cannot help you a lot.

I read somewhere that you should be able to escape quotes by doubling them, that may be worth a try:

"VIFs=json:[{""bootable"":true,""device"":0,""size"":8589934592,""type"":""system""}]"

Which OS/shell are you using?

My example was incorrect, system needs to be quoted as well, I have fixed my message now.

Anyway, the error is strange, I would have expected an invalid JSON error, which version are you using? (xo-cli --help)

@bajiya2024 Two things:

• be careful with shell quotes and interpolation
• the text following json: must be valid JSON

VIFs='json:[{"bootable":true,"device":0,"size":8589934592,"type":"system"}]'

@nodesocket You can override this setting in your config file: https://github.com/vatesfr/xen-orchestra/blob/c4d96fbc492c86d7d0365efcbe13bd0b6dd2f9a0/packages/xo-server/config.toml#L132

@RKENS Good question, during the replication, a new VM is created with the same settings as the original one, and this at every run. Therefore that's perfectly normal that this property reappears.

I don't see how that's a problem because, as you said it yourself, the start operation is disabled by the replication job.

I think it makes sense that the auto start is set like on the original VM so you can simply start the replication when necessary without having to think about enabling it.

Indeed, this is an XO bug, incomplete VMs should be ignored by smart mode, we'll fix it in the next releas.