Re: qemu-nbd thinly-provisioned exported qcow2 disk get io error in guest vm.

[Hanna Reitz]

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