On Mon, Jul 10, 2023 at 16:39:43 +0300, Андрей Ячменёв wrote:
> Hello!
>
> I want to make patch for exposing min_io_size and opt_io_size properties
> to
> export block topology information to the guest. This is needed to set
> optimal
> i/o alignment for storages in underlay.
>
> This option already exists in qemu but haven't been implemented yet in
> libvirt.
>
> It is assumed if you do not set these values qemu wont be report that into
> the guest. Inside guest undefined opt_io_size value transferred to
> sys/block/{drive}/queue/optimal_io_size like 0. And filesystems like xfs
> or
> ext4 don't set correct aggregated io size (typicaly 32k bytes for xfs).
Note that qemu apart from the possibility to explicitly specify the size
supports also a 'backend_defaults' option, which is by default in _AUTO
mode. Inside of 'blkconf_blocksizes()' the block size defaults are then
populated.
By default in _AUTO mode 'conf->physical_block_size' and
'conf->logical_block_size' are auto-populated but not
'conf->opt_io_size' or the discard granularity setting.
I think we should give the users the possibility to enable the
qemu-configured defaults in this case knowing the proper value to
configure may be non-trivial, more on that below.
>
> At the moment i think to make a patch with changes to the conf and qemu
> parts
> of libvirt.
>
> These options should be added to the address tag in the guest xml to
> section
> for disk devices. The values should be positive integers. To use these
> options,
> you must use qemu.
Libvirt already handles some of the sibling values for configuring block
sizes via:
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/sda'/>
<geometry cyls='16383' heads='16' secs='63' trans='lba'/>
<blockio logical_block_size='512' physical_block_size='4096'/>
<target dev='hdj' bus='ide'/>
</disk>
Thus you should be able to use that placement without the need to
reinvent any placement. Placing it under address would even be wrong.
> Can you tell me if there are any additional restrictions about this
> options
> that should be taken into account?
In libvirt we generally try to expose config knobs which make sense for
the users to set. That requires that the users know how to set the
option properly. Based on that I'd suggest that you first and foremost
allow the users to enable the backend defaults in qemu, as that seems to
set many things optimally without the user needing to know more.
Later then you can also add knobs to fine tune the values if necessary.
Please don't forget to read our contribution guidelines and follow the
coding style we have in place.
Note that some of the knobs may not be available in all supported QEMU
versions (libvirt currently supports qemu-4.2 and newer) which may
require adding a capability check.
If you have any questions regarding specifics feel free to ask on-list
or on our IRC channel.
