Re: [PATCH] libvirt: update default extra storage drive

[Luis Chamberlain <mcgrof@kernel.org>]

On Wed, May 07, 2025 at 12:19:26PM +0200, Daniel Gomez wrote:
> On Tue, May 06, 2025 at 01:23:42PM +0100, Luis Chamberlain wrote:
> > On Tue, May 06, 2025 at 11:18:28AM +0200, Daniel Gomez wrote:
> > > From: Daniel Gomez <da.gomez@samsung.com>
> > > 
> > > kdevops expects NVMe to be selected as stated in the config.
> > 
> > In which config?
> 
> It's part of the help here "We always expect to use...":
> 
> config LIBVIRT_EXTRA_STORAGE_DRIVE_NVME
> 	bool "NVMe"
> 	output yaml
> 	help
> 	  Use the QEMU NVMe driver for extra storage drives. We always expect
> 	  to use this as we expect *could* be outperforming the virtio driver.

Ah yeah that's outdated.

> > So, the history here was that through experience on a lot of testing
> > (specially the stable folks) they experienced *tons* of NVMe timeouts
> > as flaky failure tests. Part of this was root caused to the slow
> > performant qemu NVMe driver since it lacked using qemu IO threads, which
> > allows the device to perform I/O in its own thread rather than in the
> > main QEMU thread. Virtio already has support IO threads, so as soon as we
> > switched to virtio that fixed the issues.
> 
> config LIBVIRT_EXTRA_STORAGE_DRIVE_VIRTIO
> 	bool "virtio"
> 	output yaml
> 	help
> 	  Use the QEMU virtio driver for extra storage drives. Use this if you
> 	  are having issues with "NVMe timeouts" issues when testing in a loop
> 	  with fstests and cannot upgrade your QEMU version. If you select this
> 	  you won't be able to test ZNS.
> 
> I read the help the other way around as you have just described it. I think text
> needs an update then.

Indeed.

> > Yes, it would be good to make NVMe the default backend storage driver
> > but if default qemu release on distros don't yet have IO thread support
> > then it makes no sense to switch over, sadly.
> 
> I understand.
> 
> The problem was found when I run blktests with block and nvme profiles
> where an NVMe drive was expected in the vm. Would then a 'select
> LIBVIRT_EXTRA_SOTRAGE_DRIVE_NVME' work for blktests in this case?

So blktests can be used in two modes, one without specifying any
devices, and one with it. If you don't specify any device it uses
loopback frabics to create loopback nvme drives to then test nvme.

So I'd say testing against both would be good, but either works.

  Luis