[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qemu-nbd thinly-provisioned exported qcow2 disk get io error in gues

From: Hanna Reitz
Subject: Re: qemu-nbd thinly-provisioned exported qcow2 disk get io error in guest vm.
Date: Thu, 25 Nov 2021 17:43:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0

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'/>
<target dev='sda' bus='scsi'/>
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?


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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]