@MajorP93 Nice job, i'm thinking about working on an api route to have those infos without needing to go to the server console

@julienXOvates Noted, thank you!

I have restarted XO as well as my NAS several times since Saturday. Still no change. Regards, Marc

Hi @DevFlint, tasks are now correctly visible in the swagger documentation

Hi @slavavrn, FYI, its now possible to revert a snapshot via the REST API. POST /vms/:id/actions/revert_snapshot And the body of the endpoint: { "snapshotId": <snapshot-id> "snapshotBefore": boolean (optional) }

@pszelestey Hi, yes, we've pushed an initial commit and a few more here https://github.com/vatesfr/cluster-api-provider-vates/ it is moging every day. Ping us in Matrix/Discord devops if you want to chat live while trying

2 paths we are doing in parallel: We are doing our best to make it upstream in Linux, it's a regression after all. We know how to fix it, so hopefully this will be fixed quickly. Then, we'll have to wait for a Linux kernel update in main distros. Invariant TSC in Xen is also a way to fix it, because we want to improve that anyway. But as Teddy said, it's more work and it will take more time.

@dthenot Thanks a lot for the information. I did some more testing on my end and I've now noticed differences in handling VDI format across different SR types (local LVM and EXT). Should I expect even more differences across remote SR types like LVMoHBA or NFS or are these differences more like block based vs file system based SRs? Any way, it looks like I have to consult the following keys: image-format vdi_type type In my tests, local EXT SRs tend to have only one of them, while local LVM SRs tend to have first two or all three, depends which one was used when creating the VDI.

@danp I see your response to my concern was to add a block on the script being able to run on 8.2, without an update to the elif bug @anthoineb acknowledged. While I can remove your addition and fix that other bug myself, I just wanted to give you some feedback as to why I expressed the issue in the way I did - it wasn't because I feel an entitlement to anything, just sharing my perceptions to @antoineb I have been a xen cli user for a couple of decades, give or take. I moved to xcp-ng with a lot of PV legacy. That was a blocker to using 8.3 straight away, otherwise I would have. The workflow I had established to update the VMs to HVM included adding a new volume for /boot and /boot/efi, and then switching boot OFF on the legacy disk. It was worrying when I went to complete the migration to HVM with the announced EOL of 8.2.1, that suddenly the disks I needed to work with, both legacy and new, had disappeared in XO so I couldn't follow my SOP to move the VMs to HVM, and then proceed to upgrade to 8.3. Given how relatively widespread this issue seems to be, I am surprised that Vates wouldn't treat it as a reputational issue and want to help users to resolve it so that corporates can have confidence to move their cloud to xcp-ng platform, even if they are a startup or in the initial stages of a move and can't yet invest in Pro Support. I note you have a "Pro Support Team" badge, and understand that may not mean you work for Vates, but I gather offer Pro Support. Valuable service. While I am not encouraging this thread to become a marketing channel, it would speak well for xcp-ng, Vates and the Pro Support community if this important issue was handled differently - even if it was "we have tested on 8.2.1 internally and should be able to fix it for you quickly and cost effectively if you join our X plan or request a quote on Y page." I appreciate all you've shared and wasn't being dismissive of your recommendation to upgrade to 8.3, just the timing of this issue - arising right before the EOL of 8.2.1 made that a bit of a "chicken and egg problem". I gather from what you've said on this thread that you don't expect upgrading to 8.3 to be a problem with VDI in this state, so I guess I will just soldier on with creating an xcp-ng CLI SOP to upgrade the remaining PVs to HVM, upgrade to 8.3, and then use the script that has been shared - since you've now made it clear in the code that it shouldn't be run on 8.2. I am thankful that it was shared as guidance, if not a fix in my situation.

@poddingue Not seeing it anymore

Yes, there's a weird issue when using both XOSTOR and HA, probably due to the HA mechanism itself. @Team-Storage is on it

@henri9813 said: Hello, I see also this behavior which is "new" since few weeks. Previously, when a backup start: it stake a snapshot ( if there another one before, it delete it ). it upload the snapshot as a backup it coalesce the backup on the remote. end of the game. Now, the old snapshots are not deleted anymore which can lead easily to some disk full. Even with a retention of 1, the problem is present. I observe this only in Backup job, not DR/CR job. I just updated my XO to latest version, i will see if the issue is fixed. Hi @henri9813 , Issue should be resolved in 6.5.x, can you confirm on your side ? Thanks!

@tsukraw multiple NBD connection will open multiple reading connection, but the writing one is always one stream per disk in incremental replication with full replication, it's one stream for read and one for write

@Bryanvh No problem The issue you encountered wasn't very clear. Therefore, I've proposed a change to the XAPI to make the error more explicit (this will likely be implemented in future XAPI releases). So instead of SSL Certification failure the message will be: POOL_JOINING_MASTER_CERTIFICATE_NOT_IN_POOL_BUNDLE. Thank you very much for your patience and for bringing this issue to our attention. References: https://github.com/xapi-project/xen-api/pull/7112 LucienLassalle opened this pull request in xapi-project/xen-api closed xapi: Improve error reporting when pool join fails on TLS verification #7112

Maybe you can check for a bigger timeout on your UDM?

@acebmxer Yeah, it does not show up as an available device in XOA or XCP-ng Center. Just listed when running lspci

Hi, everyone Thank you for your help. I had a flux that was blocked by our firewall. The button worked after that. But it doesn't explain why I lost this configuration and had to reinstall it. Thanks again.