diff options
Diffstat (limited to 'results/classifier/zero-shot/118/device/2912')
| -rw-r--r-- | results/classifier/zero-shot/118/device/2912 | 43 |
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 000000000..6c4efb259 --- /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: + |