Hello everyone,

I absolutely understand the point regarding datacenters. I am using xcp-ng for years in smaller - non datacenter - environments and its great. Therefore I added the nut packages (8.2 and 8.3) and it works like a charm. It's installation is well explained in:

https://xcp-ng.org/forum/topic/4300/performing-automated-shutdown-during-a-power-failure-using-a-usb-ups-with-nut-xcp-ng-8-2/13?_=1742229073030

However, I agree with @Kajetan321 that it would be great if the nut package could be included in the standard "updated" packages repo since its added quite some benefits (imho) for "smaller" IT environments. However, I do not know how much effort it takes to maintain that.

Hello everyone. I tripped over this issue. If someone got another approach I would be interested.

Thanks to @lsouai-vates I had a look at:

https://github.com/vatesfr/xen-orchestra/blob/ab56924b1d046ccf6c09dfe7a4ab47deb5d77f4a/packages/xo-acl-resolver/index.js

and

https://github.com/vatesfr/xen-orchestra/blob/ab56924b1d046ccf6c09dfe7a4ab47deb5d77f4a/packages/xo-server/src/xo-mixins/acls.mjs#L150-L168

To what I understand it is not possible as a Non-Admin user to get information like pools, ... By creating a new admin user limiting the resources via ACLS with viewer right worked around this. However, granting admin rights still looks sort of strange.

Just in case someone struggled as well this information might help.

Hello everyone,

I absolutely understand the point regarding datacenters. I am using xcp-ng for years in smaller - non datacenter - environments and its great. Therefore I added the nut packages (8.2 and 8.3) and it works like a charm. It's installation is well explained in:

https://xcp-ng.org/forum/topic/4300/performing-automated-shutdown-during-a-power-failure-using-a-usb-ups-with-nut-xcp-ng-8-2/13?_=1742229073030

However, I agree with @Kajetan321 that it would be great if the nut package could be included in the standard "updated" packages repo since its added quite some benefits (imho) for "smaller" IT environments. However, I do not know how much effort it takes to maintain that.

Hello everyone. I tripped over this issue. If someone got another approach I would be interested.

Thanks to @lsouai-vates I had a look at:

https://github.com/vatesfr/xen-orchestra/blob/ab56924b1d046ccf6c09dfe7a4ab47deb5d77f4a/packages/xo-acl-resolver/index.js

and

https://github.com/vatesfr/xen-orchestra/blob/ab56924b1d046ccf6c09dfe7a4ab47deb5d77f4a/packages/xo-server/src/xo-mixins/acls.mjs#L150-L168

To what I understand it is not possible as a Non-Admin user to get information like pools, ... By creating a new admin user limiting the resources via ACLS with viewer right worked around this. However, granting admin rights still looks sort of strange.

Just in case someone struggled as well this information might help.

@peo
I am sorry, I must have missed your statement about the discs.

Okay. We can both confirm:

• CBT based delta backups fail on some VMs, causing an iterating success / failure backup behavior.
• removing "Purge snapshot data when using CBT" flag works around it, but at the costs of additional "doubling" storage space.
• In addition only I observed, that it always and only happens to me, when there is are additional discs involves. Delta backup of VMs within the same backup job but different machines work at my place.

I will observe this during this week and then file a bug report.

@peo
Hi. Sorry for bothering you. I may have expressed in-precise in my question.

For reporting a bug we need to get the most specific information possible. That helps developers to pinpoint a bug. Since I have only trouble with VMs having additional virtual discs (disc created on a local SR on the same host as the VM) attached to it, I would like to know if you have a counter example. Or in other words: Do all your VMs only have a single virtual disc?

@manilx feedback would be very interesting as well.

Thank you for your support.

@peo
Hi thank you. Your are most likely right about the backup storage overflow.

Just two more questions:

• have you every experienced this problem on a VM with only one disc attached? I am asking since at my site only delta backups fail with additional discs attached.
• Is this somehow addressed as a bug or shall I officially report a bug, since now quite a few users experience this problem.

@peo Hi, thank you for your quick reply. Since I had this storage issues after disabling it, I am a little bit careful. My knowledge is really limited about CBT based backups, can you tell me, what it means in terms of storage use. To my understanding it will keep the snapshots and thereby significantly increase space usage, or do I miss something? And have you heard about whether the bug is officially known and worked on?

Hi everyone again. I pretty much got back to square one. What I can observer is, that all my VMs where I added additional disc run into the above error code. So 1 disc per VM works fine for 6 backups, the two others VMs (on with 2 disc, one with 5 discs) fail. Does CBT based delta backups only work if there is no disc attached? I really appreciate any help.

Hi everyone, just FYI. During my delta backup testing, I ran out of space on my NAS (although it should have had enough?!?). It must have created more data then I expected. Therefore I had other priorities, I removed the backups and set up new delta backups. However, thereby I could not dive into further exploring the problems.

@manilx okay. I will wait and see. Backup runs tonight.

Hi @manilx.

thank you for the quick reply. I indeed do have it enabled.

I am just surprised since the exact same job worked previously and it does not make sense to me to keep it. Nevertheless I have to admit, that my knowledge is limited to these types of snapshots and its impact upon storage usage. Just FYI, there is this discussion I found: https://xcp-ng.org/forum/topic/10400/purge-snapshot-data-when-using-cbt-why-wouldn-t-i-enable-this.

However, your point is very good. I just disabled it in order to validate your thesis. If so, I think upon our system behavior we could then report some sort of "bug". Did you backup did not work from the start either or was it also after "some sort of modifications"?