summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/device/2912
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/zero-shot/118/device/2912')
-rw-r--r--results/classifier/zero-shot/118/device/291243
1 files changed, 43 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/device/2912 b/results/classifier/zero-shot/118/device/2912
new file mode 100644
index 00000000..6c4efb25
--- /dev/null
+++ b/results/classifier/zero-shot/118/device/2912
@@ -0,0 +1,43 @@
+device: 0.845
+graphic: 0.817
+virtual: 0.704
+vnc: 0.509
+ppc: 0.448
+risc-v: 0.432
+semantic: 0.423
+boot: 0.309
+register: 0.289
+KVM: 0.275
+PID: 0.268
+i386: 0.237
+hypervisor: 0.207
+debug: 0.204
+network: 0.182
+x86: 0.160
+arm: 0.155
+VMM: 0.150
+TCG: 0.138
+architecture: 0.100
+kernel: 0.097
+performance: 0.094
+files: 0.091
+socket: 0.090
+user-level: 0.090
+mistranslation: 0.071
+permissions: 0.065
+peripherals: 0.060
+assembly: 0.024
+
+qcow2 image corrupted after snapshot+bitmap action
+Description of problem:
+When taking a backup of the VM via snapshot + bitmap, the qcow2 image became corrupt:
+`qcow2: Marking image as corrupt: Preventing invalid write on metadata (overlaps with bitmap directory); further corruption events will be suppressed`
+
+This resulted in a corrupt (unfix-able) image (see #2909).
+
+While this process is something that happens multiple times a day, we never hit any issue.
+The underlying storage didn't report any error, so it seems like something inside qemu broke the image.
+Steps to reproduce:
+Unfortunately, I was unable to reproduce this issue yet.
+Additional information:
+