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.
@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.
@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.
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.