[PATCH v3 0/4] iotests fixes

[PATCH v3 0/4] iotests fixes

[Eric Farman]

Hi Kevin, Hanna,

Here is a third version of iotests fixes from our s390x systems.
They aren't related, just came up walking through the failures.

In fact, only patch 4 has existed in the previous versions of this "series",
as it remains stubborn for me (hence me putting it at the end). This time,
I added a check against the qemu-storage-daemon to try to do a mount against
a null device (similar to the test_fuse_support() routine in fuse-mmap-shared),
to bail out of the test earlier than failing on the "real" command later on.

I look forward to your feedback...

v1: https://lore.kernel.org/r/20260725125651.3896151-1-farman@linux.ibm.com/
v2: https://lore.kernel.org/r/20260728192644.2879028-1-farman@linux.ibm.com/
v2->v3:
 - [EF] Add two fixes for NBD tests, and one (new) fix for another FUSE test
 - [HC] Rework the fix to 108, and perform a dummy mount to see if fuse works

Eric Farman (4):
  iotests/nbd-in-qcow2-chain: use default machine
  iotests/nbd-tls-iothread: skip on non-x86 hardware
  iotests/fuse-truncate: skip if FUSE is not usable
  iotests/108: skip if fuse is unsuable

 tests/qemu-iotests/108                      | 17 +++++++++++++++++
 tests/qemu-iotests/tests/fuse-truncate      |  9 ++++++---
 tests/qemu-iotests/tests/nbd-in-qcow2-chain |  2 +-
 tests/qemu-iotests/tests/nbd-tls-iothread   |  4 ++++
 4 files changed, 28 insertions(+), 4 deletions(-)

-- 
2.53.0

[PATCH v3 1/4] iotests/nbd-in-qcow2-chain: use default machine

[Eric Farman]

Some of the NBD tests explicitly specify `-machine q35` which won't work
when running against, say, qemu-system-s390x.

The nbd-in-qcow2-chain test runs fine with the default machine on a z16
host, so allow it to run in other configurations.

Fixes: 24fd6d75b3 ("iotests: Add coverage of recent NBD qio deadlock fix")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 tests/qemu-iotests/tests/nbd-in-qcow2-chain | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/tests/nbd-in-qcow2-chain b/tests/qemu-iotests/tests/nbd-in-qcow2-chain
index 455ddfa86f..e35f072eba 100755
--- a/tests/qemu-iotests/tests/nbd-in-qcow2-chain
+++ b/tests/qemu-iotests/tests/nbd-in-qcow2-chain
@@ -43,7 +43,7 @@ TEST_IMG="$TEST_IMG.base" _make_test_img $size
 echo
 echo "=== Starting QEMU and exposing base image ==="
 
-_launch_qemu -machine q35
+_launch_qemu
 h1=$QEMU_HANDLE
 _send_qemu_cmd $QEMU_HANDLE '{"execute": "qmp_capabilities"}' 'return'
 _send_qemu_cmd $QEMU_HANDLE '{"execute": "blockdev-add",
-- 
2.53.0

[PATCH v3 2/4] iotests/nbd-tls-iothread: skip on non-x86 hardware

[Eric Farman]

Like nbd-in-qcow2-chain, this test assumes a q35 machine is
present, which might not be available on other hosts.
Unlike that test, simply allowing it to run with the default machine
still throws an errors. Fence this to PC-only machines for now.

Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 tests/qemu-iotests/tests/nbd-tls-iothread | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tests/qemu-iotests/tests/nbd-tls-iothread b/tests/qemu-iotests/tests/nbd-tls-iothread
index a2fb07206e..4326e2d3e5 100755
--- a/tests/qemu-iotests/tests/nbd-tls-iothread
+++ b/tests/qemu-iotests/tests/nbd-tls-iothread
@@ -47,6 +47,10 @@ cd ..
 _supported_fmt qcow2  # Hardcoded to qcow2 command line and QMP below
 _supported_proto file
 
+if [ "$QEMU_DEFAULT_MACHINE" != "pc" ]; then
+    _notrun "Requires a PC machine"
+fi
+
 # pick_unused_port
 #
 # Picks and returns an "unused" port, setting the global variable
-- 
2.53.0

[PATCH v3 3/4] iotests/fuse-truncate: skip if FUSE is not usable

[Eric Farman]

Commit 951227d3755 ("iotests: skip FUSE tests when FUSE is not usable")
reworked some of the fuse-related tests to skip where needed,
but the new test fuse-truncate raced with that and missed out on the
same treatment. Add that same python-esque skip logic to this test.

Fixes: 7d06bbb2d9 ("iotests: test O_TRUNC behavior for fuse exports")
Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 tests/qemu-iotests/tests/fuse-truncate | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/qemu-iotests/tests/fuse-truncate b/tests/qemu-iotests/tests/fuse-truncate
index 7eee35111c..f3d2f1866c 100755
--- a/tests/qemu-iotests/tests/fuse-truncate
+++ b/tests/qemu-iotests/tests/fuse-truncate
@@ -32,9 +32,12 @@ def check_fuse_support():
     test_qsd.stop()
     os.remove(fuse_mount_point)
     if 'error' in res:
-        assert (res['error']['desc'] ==
-                "Parameter 'type' does not accept value 'fuse'")
-        iotests.notrun('No FUSE support')
+        desc = res['error']['desc']
+        if desc == "Parameter 'type' does not accept value 'fuse'":
+            iotests.notrun('No FUSE support')
+        if 'Failed to mount FUSE session' in desc:
+            iotests.notrun('FUSE not usable in this environment')
+        assert False, desc
 
 def check_sudo_support():
     try:
-- 
2.53.0

[PATCH v3 4/4] iotests/108: skip if fuse is unsuable

[Eric Farman]

It is possible that the ability to fusermount is restricted
to privileged users. Rather than waiting for this test to
perform a mount and subsequently fail, perform a dummy mount
early on and skip the tests if fuse is not usable.

Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 tests/qemu-iotests/108 | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
index bf808b3512..8dc725cf66 100755
--- a/tests/qemu-iotests/108
+++ b/tests/qemu-iotests/108
@@ -73,6 +73,23 @@ else
         _notrun 'Passwordless sudo for losetup or FUSE support required, but' \
                 'neither is available'
     fi
+
+    # Test to see if fuse is usable or not (permissions, etc.)
+    export_mp="$TEST_DIR/fuse-export"
+    touch "$export_mp"
+
+    response=$($QSD \
+        --blockdev null-co,node-name=export-node \
+        --export fuse,id=fuse-export,node-name=export-node,mountpoint="$export_mp",allow-other=off \
+        --pidfile "$TEST_DIR/qsd.pid" 2>&1)
+    if [[ $response = *"Failed to mount FUSE session to export"* ]]; then
+        _notrun 'FUSE support is not usable (permission error?)'
+    fi
+
+    if [ -f "$TEST_DIR/qsd.pid" ]; then
+        qsd_pid=$(cat "$TEST_DIR/qsd.pid")
+        kill -KILL "$qsd_pid"
+    fi
 fi
 
 echo
-- 
2.53.0

Re: [PATCH v3 0/4] iotests fixes

[Eric Farman]

On 8/13/26 2:37 PM, Eric Farman wrote:
> Hi Kevin, Hanna,
> 
> Here is a third version of iotests fixes from our s390x systems.
> They aren't related, just came up walking through the failures.

Hi Kevin, Hanna,

Just bumping this up the list. Any thoughts?

This series applies cleanly to today's master, and without this I can 
still reproduce the errors described within.

Thanks,
Eric

> 
> In fact, only patch 4 has existed in the previous versions of this "series",
> as it remains stubborn for me (hence me putting it at the end). This time,
> I added a check against the qemu-storage-daemon to try to do a mount against
> a null device (similar to the test_fuse_support() routine in fuse-mmap-shared),
> to bail out of the test earlier than failing on the "real" command later on.
> 
> I look forward to your feedback...
> 
> v1: https://lore.kernel.org/r/20260725125651.3896151-1-farman@linux.ibm.com/
> v2: https://lore.kernel.org/r/20260728192644.2879028-1-farman@linux.ibm.com/
> v2->v3:
>   - [EF] Add two fixes for NBD tests, and one (new) fix for another FUSE test
>   - [HC] Rework the fix to 108, and perform a dummy mount to see if fuse works
> 
> Eric Farman (4):
>    iotests/nbd-in-qcow2-chain: use default machine
>    iotests/nbd-tls-iothread: skip on non-x86 hardware
>    iotests/fuse-truncate: skip if FUSE is not usable
>    iotests/108: skip if fuse is unsuable
> 
>   tests/qemu-iotests/108                      | 17 +++++++++++++++++
>   tests/qemu-iotests/tests/fuse-truncate      |  9 ++++++---
>   tests/qemu-iotests/tests/nbd-in-qcow2-chain |  2 +-
>   tests/qemu-iotests/tests/nbd-tls-iothread   |  4 ++++
>   4 files changed, 28 insertions(+), 4 deletions(-)
> 

Re: [PATCH v3 4/4] iotests/108: skip if fuse is unsuable

[Kevin Wolf]

Am 13.08.2026 um 20:37 hat Eric Farman geschrieben:
> It is possible that the ability to fusermount is restricted
> to privileged users. Rather than waiting for this test to
> perform a mount and subsequently fail, perform a dummy mount
> early on and skip the tests if fuse is not usable.
> 
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

There is a typo in the subject line (s/unsuable/unusable/).

>  tests/qemu-iotests/108 | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
> index bf808b3512..8dc725cf66 100755
> --- a/tests/qemu-iotests/108
> +++ b/tests/qemu-iotests/108
> @@ -73,6 +73,23 @@ else
>          _notrun 'Passwordless sudo for losetup or FUSE support required, but' \
>                  'neither is available'
>      fi
> +
> +    # Test to see if fuse is usable or not (permissions, etc.)
> +    export_mp="$TEST_DIR/fuse-export"
> +    touch "$export_mp"
> +
> +    response=$($QSD \
> +        --blockdev null-co,node-name=export-node \
> +        --export fuse,id=fuse-export,node-name=export-node,mountpoint="$export_mp",allow-other=off \
> +        --pidfile "$TEST_DIR/qsd.pid" 2>&1)

If FUSE is available, this hangs because QSD doesn't exit by itself, but
waits for clients to connect.

--daemonize might give you the right semantics (print errors while
setting up the export to stderr, exit after initialising everything)
when combined with your code below to kill QSD.

> +    if [[ $response = *"Failed to mount FUSE session to export"* ]]; then
> +        _notrun 'FUSE support is not usable (permission error?)'
> +    fi

Should this part use _notrun_on_fuse_error()?

Kevin

Re: [PATCH v3 1/4] iotests/nbd-in-qcow2-chain: use default machine

[Kevin Wolf]

Am 13.08.2026 um 20:37 hat Eric Farman geschrieben:
> Some of the NBD tests explicitly specify `-machine q35` which won't work
> when running against, say, qemu-system-s390x.
> 
> The nbd-in-qcow2-chain test runs fine with the default machine on a z16
> host, so allow it to run in other configurations.
> 
> Fixes: 24fd6d75b3 ("iotests: Add coverage of recent NBD qio deadlock fix")
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
>  tests/qemu-iotests/tests/nbd-in-qcow2-chain | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/qemu-iotests/tests/nbd-in-qcow2-chain b/tests/qemu-iotests/tests/nbd-in-qcow2-chain
> index 455ddfa86f..e35f072eba 100755
> --- a/tests/qemu-iotests/tests/nbd-in-qcow2-chain
> +++ b/tests/qemu-iotests/tests/nbd-in-qcow2-chain
> @@ -43,7 +43,7 @@ TEST_IMG="$TEST_IMG.base" _make_test_img $size
>  echo
>  echo "=== Starting QEMU and exposing base image ==="
>  
> -_launch_qemu -machine q35
> +_launch_qemu
>  h1=$QEMU_HANDLE
>  _send_qemu_cmd $QEMU_HANDLE '{"execute": "qmp_capabilities"}' 'return'
>  _send_qemu_cmd $QEMU_HANDLE '{"execute": "blockdev-add",

I don't see what the machine type is needed for, so this is probably
fine.

Eric (Blake), any specific reason you added the machine type in this
test case so that removing it might cause a regression?

Kevin

Re: [PATCH v3 4/4] iotests/108: skip if fuse is unsuable

[Eric Farman]

On 9/24/26 9:00 AM, Kevin Wolf wrote:
> Am 13.08.2026 um 20:37 hat Eric Farman geschrieben:
>> It is possible that the ability to fusermount is restricted
>> to privileged users. Rather than waiting for this test to
>> perform a mount and subsequently fail, perform a dummy mount
>> early on and skip the tests if fuse is not usable.
>>
>> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> 
> There is a typo in the subject line (s/unsuable/unusable/).
> 
>>   tests/qemu-iotests/108 | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
>> index bf808b3512..8dc725cf66 100755
>> --- a/tests/qemu-iotests/108
>> +++ b/tests/qemu-iotests/108
>> @@ -73,6 +73,23 @@ else
>>           _notrun 'Passwordless sudo for losetup or FUSE support required, but' \
>>                   'neither is available'
>>       fi
>> +
>> +    # Test to see if fuse is usable or not (permissions, etc.)
>> +    export_mp="$TEST_DIR/fuse-export"
>> +    touch "$export_mp"
>> +
>> +    response=$($QSD \
>> +        --blockdev null-co,node-name=export-node \
>> +        --export fuse,id=fuse-export,node-name=export-node,mountpoint="$export_mp",allow-other=off \
>> +        --pidfile "$TEST_DIR/qsd.pid" 2>&1)
> 
> If FUSE is available, this hangs because QSD doesn't exit by itself, but
> waits for clients to connect.
> 
> --daemonize might give you the right semantics (print errors while
> setting up the export to stderr, exit after initialising everything)
> when combined with your code below to kill QSD.

Good point. I note that similar logic exists elsewhere in 108, with a 
loop to wait for the qsd.pid file to disappear from a daemonized QSD, 
which would probably be warranted.

> 
>> +    if [[ $response = *"Failed to mount FUSE session to export"* ]]; then
>> +        _notrun 'FUSE support is not usable (permission error?)'
>> +    fi
> 
> Should this part use _notrun_on_fuse_error()?

Ah, of course. Not sure why I neglected to use that here.

> 
> Kevin
> 

Re: [PATCH v3 1/4] iotests/nbd-in-qcow2-chain: use default machine

[Eric Blake]

On Thu, Sep 24, 2026 at 03:04:46PM +0200, Kevin Wolf wrote:
> Am 13.08.2026 um 20:37 hat Eric Farman geschrieben:
> > Some of the NBD tests explicitly specify `-machine q35` which won't work
> > when running against, say, qemu-system-s390x.
> > 
> > The nbd-in-qcow2-chain test runs fine with the default machine on a z16
> > host, so allow it to run in other configurations.
> > 
> > Fixes: 24fd6d75b3 ("iotests: Add coverage of recent NBD qio deadlock fix")
> > Signed-off-by: Eric Farman <farman@linux.ibm.com>
> > ---

> >  
> > -_launch_qemu -machine q35
> > +_launch_qemu
> >  h1=$QEMU_HANDLE
> >  _send_qemu_cmd $QEMU_HANDLE '{"execute": "qmp_capabilities"}' 'return'
> >  _send_qemu_cmd $QEMU_HANDLE '{"execute": "blockdev-add",
> 
> I don't see what the machine type is needed for, so this is probably
> fine.
> 
> Eric (Blake), any specific reason you added the machine type in this
> test case so that removing it might cause a regression?

This would have been copy-and-paste from some other test, and not
something specific to this one.

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org