Re: vmd writes corrupt qcow2 images
Ori Bernstein writes: > Yep. I can look at it in a few days. > > I'm assuming that the vm was stopped before running the check? > Yes. > On April 18, 2022 3:42:50 PM EDT, Mike Larkin wrote: > > On Mon, Apr 18, 2022 at 12:21:39PM -0400, Dave Voutila wrote: > > "Thomas L." writes: > > Hi, > > I recently tried to use qemu-img with qcow2 images of my VMs and > qemu-img finds them corrupted. I can reproduce the issue in the > following way (on -current, but is the same on -stable; tried different > hosts to exclude hardware errors): > > marsden# vmctl create -s 300G test.qcow2 > vmctl: qcow2 imagefile created > marsden# qemu-img check test.qcow2 > No errors were found on the image. > Image end offset: 262144 > marsden# vmctl start -cL -B net -b /bsd.rd -d test.qcow2 test > > > > marsden# qemu-img check test.qcow2 > ERROR cluster 32769 refcount=0 reference=1 > > 1 errors were found on the image. > Data may be corrupted, or further writes to the image may corrupt it. > 39422/4915200 = 0.80% allocated, 3.31% fragmented, 0.00% compressed clusters > Image end offset: 2610888704 > > I've been able to reproduce the above, but interestingly if I "repair" > the qcow2 image using: > > $ qemu-img -r all test.qcow2 > > It then reports 0 errors. Booting up the vm and installing packages like > python3 and git and then cloning some git repos to work the disk, it > still reports 0 errors. > > Interestingly, if I install something like an Alpine 3.13 guest (just an > iso I had handy), qemu-img reports 0 errors. > > I also looked at a handful of qcow2 images on one of my workstations and > seems only an Alpine and NixOS guest do not have this "corruption" > report. However, I've never experienced any noticeable abnormalities. > > Since I see this from non-OpenBSD guests (Debian, for instance) it > doesn't seem to be our vioblk(4) driver and is probably vmd(8)'s qcow2 > implementation.. > > Anyone familiar enough with qcow2 that might make heads or tails of > this? (cc'd ori@ as he was the original implementer.) > > -dv > > Yeah, Ori would be the right person to answer. If not I can take a look if I > find the time. -- -Dave Voutila
Re: vmd writes corrupt qcow2 images
Yep. I can look at it in a few days. I'm assuming that the vm was stopped before running the check? On April 18, 2022 3:42:50 PM EDT, Mike Larkin wrote: >On Mon, Apr 18, 2022 at 12:21:39PM -0400, Dave Voutila wrote: >> >> "Thomas L." writes: >> >> > Hi, >> > >> > I recently tried to use qemu-img with qcow2 images of my VMs and >> > qemu-img finds them corrupted. I can reproduce the issue in the >> > following way (on -current, but is the same on -stable; tried different >> > hosts to exclude hardware errors): >> > >> > marsden# vmctl create -s 300G test.qcow2 >> > vmctl: qcow2 imagefile created >> > marsden# qemu-img check test.qcow2 >> > No errors were found on the image. >> > Image end offset: 262144 >> > marsden# vmctl start -cL -B net -b /bsd.rd -d test.qcow2 test >> >> > marsden# qemu-img check test.qcow2 >> > ERROR cluster 32769 refcount=0 reference=1 >> > >> > 1 errors were found on the image. >> > Data may be corrupted, or further writes to the image may corrupt it. >> > 39422/4915200 = 0.80% allocated, 3.31% fragmented, 0.00% compressed >> > clusters >> > Image end offset: 2610888704 >> >> I've been able to reproduce the above, but interestingly if I "repair" >> the qcow2 image using: >> >> $ qemu-img -r all test.qcow2 >> >> It then reports 0 errors. Booting up the vm and installing packages like >> python3 and git and then cloning some git repos to work the disk, it >> still reports 0 errors. >> >> Interestingly, if I install something like an Alpine 3.13 guest (just an >> iso I had handy), qemu-img reports 0 errors. >> >> I also looked at a handful of qcow2 images on one of my workstations and >> seems only an Alpine and NixOS guest do not have this "corruption" >> report. However, I've never experienced any noticeable abnormalities. >> >> Since I see this from non-OpenBSD guests (Debian, for instance) it >> doesn't seem to be our vioblk(4) driver and is probably vmd(8)'s qcow2 >> implementation.. >> >> Anyone familiar enough with qcow2 that might make heads or tails of >> this? (cc'd ori@ as he was the original implementer.) >> >> -dv >> > >Yeah, Ori would be the right person to answer. If not I can take a look if I >find the time. > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: vmd writes corrupt qcow2 images
On Mon, Apr 18, 2022 at 12:21:39PM -0400, Dave Voutila wrote: > > "Thomas L." writes: > > > Hi, > > > > I recently tried to use qemu-img with qcow2 images of my VMs and > > qemu-img finds them corrupted. I can reproduce the issue in the > > following way (on -current, but is the same on -stable; tried different > > hosts to exclude hardware errors): > > > > marsden# vmctl create -s 300G test.qcow2 > > vmctl: qcow2 imagefile created > > marsden# qemu-img check test.qcow2 > > No errors were found on the image. > > Image end offset: 262144 > > marsden# vmctl start -cL -B net -b /bsd.rd -d test.qcow2 test > > > marsden# qemu-img check test.qcow2 > > ERROR cluster 32769 refcount=0 reference=1 > > > > 1 errors were found on the image. > > Data may be corrupted, or further writes to the image may corrupt it. > > 39422/4915200 = 0.80% allocated, 3.31% fragmented, 0.00% compressed clusters > > Image end offset: 2610888704 > > I've been able to reproduce the above, but interestingly if I "repair" > the qcow2 image using: > > $ qemu-img -r all test.qcow2 > > It then reports 0 errors. Booting up the vm and installing packages like > python3 and git and then cloning some git repos to work the disk, it > still reports 0 errors. > > Interestingly, if I install something like an Alpine 3.13 guest (just an > iso I had handy), qemu-img reports 0 errors. > > I also looked at a handful of qcow2 images on one of my workstations and > seems only an Alpine and NixOS guest do not have this "corruption" > report. However, I've never experienced any noticeable abnormalities. > > Since I see this from non-OpenBSD guests (Debian, for instance) it > doesn't seem to be our vioblk(4) driver and is probably vmd(8)'s qcow2 > implementation.. > > Anyone familiar enough with qcow2 that might make heads or tails of > this? (cc'd ori@ as he was the original implementer.) > > -dv > Yeah, Ori would be the right person to answer. If not I can take a look if I find the time.
Re: vmd writes corrupt qcow2 images
"Thomas L." writes: > Hi, > > I recently tried to use qemu-img with qcow2 images of my VMs and > qemu-img finds them corrupted. I can reproduce the issue in the > following way (on -current, but is the same on -stable; tried different > hosts to exclude hardware errors): > > marsden# vmctl create -s 300G test.qcow2 > vmctl: qcow2 imagefile created > marsden# qemu-img check test.qcow2 > No errors were found on the image. > Image end offset: 262144 > marsden# vmctl start -cL -B net -b /bsd.rd -d test.qcow2 test > marsden# qemu-img check test.qcow2 > ERROR cluster 32769 refcount=0 reference=1 > > 1 errors were found on the image. > Data may be corrupted, or further writes to the image may corrupt it. > 39422/4915200 = 0.80% allocated, 3.31% fragmented, 0.00% compressed clusters > Image end offset: 2610888704 I've been able to reproduce the above, but interestingly if I "repair" the qcow2 image using: $ qemu-img -r all test.qcow2 It then reports 0 errors. Booting up the vm and installing packages like python3 and git and then cloning some git repos to work the disk, it still reports 0 errors. Interestingly, if I install something like an Alpine 3.13 guest (just an iso I had handy), qemu-img reports 0 errors. I also looked at a handful of qcow2 images on one of my workstations and seems only an Alpine and NixOS guest do not have this "corruption" report. However, I've never experienced any noticeable abnormalities. Since I see this from non-OpenBSD guests (Debian, for instance) it doesn't seem to be our vioblk(4) driver and is probably vmd(8)'s qcow2 implementation.. Anyone familiar enough with qcow2 that might make heads or tails of this? (cc'd ori@ as he was the original implementer.) -dv
