Hi!

@pdonias will answer all the rest, but in terms of contributions, yes, PR are very welcome! (and it's not in contradiction with https://xen-orchestra.com/docs/contributing.html#contributing)

It means the kernel tried to deference a null pointer. This generates a page fault which can't be handled in the kernel- if it's running a user task (but in kernel space), it generally makes an "Oops" which (uncleanly) kills the current task and may leak kernel resources. If it's in some other context, e.g. an interrupt, it generally causes a kernel panic.

@GriAle Should be fixed: https://github.com/vatesfr/xen-orchestra/commit/ba03a4849831deecda7b8139374b5c43bf90d2b3

0 julien-f committed to vatesfr/xen-orchestra chore(xo-server): update to hashy@0.11.1 Fixes https://xcp-ng.org/forum/post/50866 Introduced by 49890a09b7a3c4bcbe7f462577c6d0a7da8b7006 Fixes argon2id support which is the new default algorithm since argon2@0.28.7

@CptHyper Yes, Only that card is working. I am using 6 of them in a pool and works great for about a year now. You will also need the driver for your Guest VM as well. Overall pretty easy to set this up once you find the driver!

@julien-f It is likely a broken xva. I did interrupt those as they were exporting, however I was a bit confused as to why it was checked by a different backup task. In other words this screen clip is from a delta backup, not a xva export.

I was more expecting it to show up on the XVA export backup task.

FWIW, I was having similar kernel panics on my HP DL380G8 today. Two Xeon E5-2620 2 GHz, microcode version 0x71a. It's happened before, but only on a reboot.

Today, the kernel panics weren't consistent as to which CPU it was. I saw it get as high as CPU 22 and as low as CPU 3.

I was viewing POST via iLO remote console. After about an hour of allowing it to reboot on its own or with my manually resetting it via iLO GUI, I went to my data center and turned on the monitor and switched to the KVM channel the server was on. It came back up then. HTH.

@Denson Was this ever resolved?
In Xen Orchestra go to Settings/Servers and you will see a "Read Only" switch that might address the problem.
-Jorge

@florent @olivierlambert Looking at failed S3 backup problems the retry should be easy. Currently on the job report there is a button to restart all failed VM backups in that job. Can you just add an option for automatic restart failed VM backups after job completion. It can even be a separate job (just as clicking the button is). It would just "click" the restart failed VMs button once (or a setting) after a few minutes (or a setting). Or it could start the new job as pending or delayed and start after a few minutes allowing for time to cancel it.

Thank you, that fix worked.

Feel free to open a support ticket so we can see together if it makes sense, as I said it was written for some specific cases and it's not prime for broad use case.

@olivierlambert i have created config.httpInactivityTimeout.toml in /opt/xen-orchestra/packages/xo-server with the content from above. Not sure how i can check if thats actually set.

BTW: this is not a CR Backup Problem, i also dont see Tasks running for my "normal" Backup Job. I cant check "how far" the actual Backup runs and if that differs.

https://github.com/vatesfr/xen-orchestra/pull/6315

Rajaa-BARHTAOUI created this issue in vatesfr/xen-orchestra open fix(xo-web/tasks): fix not displayed tasks when running CR backup #6315

I do not see any VIF order here.
Is there a way to force it on the template config level?

@olivierlambert
thanks

Hello, we will take a look into that and keep you posted.

@jaayb Amazing, TYSM!

XCP-NG UBUNTU VM on a UBUNTU Docker
3866d4e2-8895-4e51-8cde-3bddef1f51d0-image.png

Somehow faster except Floating is more dead.

@Zevgeny

For a few snapshots it's fine - the issue comes when you have large numbers. Most of my first-hand experience with this specific issue comes from Hyper-V but the logic applies here.

This is from VMware but the concept is the same and has some good reading on snapshots in general.

Running a virtual machine on a snapshot for extended periods of time can cause instability and data loss.
https://kb.vmware.com/s/article/1015180

The underlying issue stems from the nature of snapshots. With none you have a single VHD containing all of the data for the VM, once you take a snapshot a new delta VHD is created with all new data written going forward from the time of the snapshot. So, in order to have a complete VM you have the original VHD + the delta VHD.

This is fine in smaller numbers, but once you start having 10, 15, 20+ snapshots, every one of those represents an additional VHD in the chain. This results in performance degradation because you're reading from multiple potential files as only new data is written to the deltas.

This is actually from XO's blog: https://xen-orchestra.com/blog/xenserver-coalesce-detection-in-xen-orchestra/

@olivierlambert

agree 1000% which is why when you guys get things to work; please share it like the tutorials in the past

will help many people and draw many to XCP-ng and thus to Vates