On 11.11.21 04:19, Liang Cong wrote:
Dear all,
I am facing an issue while using qemu-nbd thinly-provisioned exported
qcow2 disk.
below is the steps:
1. qemu-img create -f qcow2 /tmp/img.qcow2 100M
2. qemu-nbd -f raw /tmp/img.qcow2
3. then I use it as a virtual disk in guest vm with xml like below:
<disk type='network' device='disk'>
<driver name='qemu' type='qcow2'/>
<source protocol='nbd'>
<host name='xxx.xxx.xxx.xxx' port='10809'/>
</source>
<target dev='sda' bus='scsi'/>
</disk>
4. when i start the guest and try to format it in the guest, I got the
error:
blk_update_request: critical target error, dev sda, sector 204672 op
0x1:(WRITE) flags 0x800 phys_seg 16 prio class 0
but I tried with the disk image created with full allocated by command:
qemu-img create -f qcow2 /tmp/img.qcow2 100M -o preallocation=full
then there is no error, so I assume it is related to the
thinly-provisioned feature.
I am using: qemu-kvm-6.1.0, libvirt-7.8.0 on Red Hat Enterprise Linux
release 8.6 Beta
So can you kindly help to confirm whether the thinly-provisioned cause
the error?
and if so, are there any plan to fix or add new feature for it?
Hi,
NBD as a protocol is generally most suited to export virtual disks, not
arbitrary data. By passing `-f raw` to qemu-nbd, you prevent it from
interpreting the qcow2 format, and so it will export the qcow2 file over
NBD instead of the virtual disk it represents, and thus in turn the
client will have to interpret the qcow2 format (as can be seen by having
to specify the qcow2 format in the VM XML).
When using NBD, you should always have the NBD server interpret the
image format (i.e. pass `-f qcow2` to qemu-nbd) so it can present the
virtual disk the image represents over the NBD protocol. The client
should see only this raw disk (`raw` instead of `qcow2` in the VM XML).
From a technical perspective, the exact problem is that NBD does not
support writes beyond the end of file, which is something that qemu’s
qcow2 driver relies on, e.g. to grow thinly provisioned files on guest
writes. Therefore, such writes will cause the errors you’ve seen.
(Even if NBD supported writes beyond EOF, I would still always recommend
having the NBD server interpret the image format, unless there are
pressing reasons to have the client see and be able to modify the image
metadata.)
Hanna
