Created attachment 1843760 [details]
error screenshot

I've tried several times to reproduce this and cannot. It seems to work just fine for me with a nightly build of rhel-8.6. Can you provide any more information to help reproduce? Is it architecture-specific? Can you share the domain xml?

This problem is also happened when I tried to edit a storage hardware for a vm.

packages:
virt-manager-3.2.0-1.el8.noarch
libvirt-7.10.0-1.module+el8.6.0+13150+28339563.x86_64

Steps to Reproduce:
1. Prepare a VM 
2. Connect to $remote_server
3. Open VM details and check the virtual device detail 

>>
Error refreshing hardware page: Argument 1 does not allow None as a value

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/details/details.py", line 1714, in _refresh_page
    self._refresh_disk_page(dev)
  File "/usr/share/virt-manager/virtManager/details/details.py", line 2007, in _refresh_disk_page
    self._addstorage.set_dev(disk)
  File "/usr/share/virt-manager/virtManager/device/addstorage.py", line 327, in set_dev
    self.widget("disk-removable").set_active(removable)
TypeError: Argument 1 does not allow None as a value

this error also happens when created a VM, customize a virtual disk.

Please check the attachment to get more info.

After an error occurs, I am still able to change the bus type and the xml file changed successfully. Besides, every single click in this window will trigger this error.

This problem only can be reproduced on RHEL8.6. arc x86_64, I think this not architecture-specific because I can reproduce this on x86_64.

(In reply to Jonathon Jongsma from comment #2)
> I've tried several times to reproduce this and cannot. It seems to work just
> fine for me with a nightly build of rhel-8.6. Can you provide any more
> information to help reproduce? Is it architecture-specific? Can you share
> the domain xml?

Looking at the traces, IMO the same error message "Argument 1 does not allow None as a value" has more than one root cause by two different scenarios:

1. On MDEV devices (originally reported)
2. On virtual disk devices (hit by Hongzhou, comment#6)

With the latest nightly compose I can't reproduce 1. but I can reproduce 2. reliably. So I'm changing the title and updating BZ links.

As pointed out by Hangzhou

> After an error occurs, I am still able to change the bus type and the xml file changed successfully. Besides, every single click in this window will trigger this error.

so I'm lowering severity to High.

For reproduction of 2. I really just had to import a guest image locally, I did not have to do this remotely. I'm attaching the domain xml in any case.

Steps to reproduce:
1. Import vm from image file with default settings
OR
1'. virsh define atttached domain.xml
2. Open VM details
3. Click VirtIO Disk 1

Compose/Versions this reproduces with:
RHEL-8.6.0-20211206.1
kernel-4.18.0-353.el8.x86_64
libvirt-daemon-7.9.0-1.module+el8.6.0+13150+28339563.x86_64
virt-manager-3.2.0-1.el8.noarch

I'm setting the Regression keyword because this doesn't reproduce with
virt-manager-2.2.1-4.el8.noarch
libvirt-daemon-6.0.0-37.module+el8.5.0+12162+40884dd2.x86_64

Created attachment 1845075 [details]
domain xml

Aha. It looks like this is an unrelated bug that was already fixed upstream in commit e7222b5058c8874b15fbfd998e5eeb233f571075

Verify this bug with following packages:
virt-manager-3.2.0-2.el8.noarch
virt-install-3.2.0-2.el8.noarch

step1. Prepare a VM 
step2. Connect to VM
step3. Open VM details and check the virtual device detail by clicking VirtIO

Test result:
VM detail shows correctly and no error messages exist, that's as expected. So I change the status to verified.

Thank you Hongzhou!

Hi Sebastian,

Because this bug first report on S390, so could you double check the bug?

Thanks

(In reply to Hongzhou Liu from comment #21)
> Hi Sebastian,
> 
> Because this bug first report on S390, so could you double check the bug?
> 
> Thanks

I don't think it's necessary to double check on s390 as it's an arch-independent fix and our base scenario start virt-manager on x86_64 and connects to headless s390x server.

Verified successfully on s390x, too, because IBM reported they reproduced it on s390x, details s. https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c31

Re-opening this bug, because the proposed fix was not sufficient as described at https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c35

We also need to backport commit cf93e2dbff28fe05d6d45364c579f923b157beb1 from upstream to fully fix the issue.

(In reply to Jonathon Jongsma from comment #24)
> Re-opening this bug, because the proposed fix was not sufficient as
> described at https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c35
> 
> We also need to backport commit cf93e2dbff28fe05d6d45364c579f923b157beb1
> from upstream to fully fix the issue.

Out of curiosity can you point to the commit? I searched the virt-manager repo on github for this to no avail.

(In reply to smitterl from comment #30)
> (In reply to Jonathon Jongsma from comment #24)
> > Re-opening this bug, because the proposed fix was not sufficient as
> > described at https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c35
> > 
> > We also need to backport commit cf93e2dbff28fe05d6d45364c579f923b157beb1
> > from upstream to fully fix the issue.
> 
> Out of curiosity can you point to the commit? I searched the virt-manager
> repo on github for this to no avail.

https://github.com/virt-manager/virt-manager/commit/cf93e2dbff28fe05d6d45364c579f923b157beb1

Here is the original upstream bug report that prompted the upstream fix: https://github.com/virt-manager/virt-manager/issues/226. The guest apparently needs to be running in order to trigger this second scenario.

(In reply to Jonathon Jongsma from comment #32)
> (In reply to smitterl from comment #30)
> > (In reply to Jonathon Jongsma from comment #24)
> > > Re-opening this bug, because the proposed fix was not sufficient as
> > > described at https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c35
> > > 
> > > We also need to backport commit cf93e2dbff28fe05d6d45364c579f923b157beb1
> > > from upstream to fully fix the issue.
> > 
> > Out of curiosity can you point to the commit? I searched the virt-manager
> > repo on github for this to no avail.
> 
> https://github.com/virt-manager/virt-manager/commit/
> cf93e2dbff28fe05d6d45364c579f923b157beb1
> 
> Here is the original upstream bug report that prompted the upstream fix:
> https://github.com/virt-manager/virt-manager/issues/226. The guest
> apparently needs to be running in order to trigger this second scenario.

Thanks Jonathon. I still fail to reproduce this issue on a running machine. With this and the scenarios that I covered in 

https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c31
https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c32

I think we need info from IBM to clarify which scenario exactly and versions led to their reporting this https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c26

Until we've come to a conclusion I set this again back to VERIFIED. I hope that's okay.

Until then, IMO we should not risk our beta compose stability with an additional backport.

IBM, please can you help clarify which exact scenario you ran to reproduce the trace you reported in https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c26?
We can also sync on slack or schedule a meeting to accelerate this. Thanks!

(Note: on the 8.6 compose we deliver/depend on python3-gobject-3.28.3-2.el8.s390x)

Finally with Boris help I've been able to reproduce this with a specific (valid) XML.



<domain type='kvm'>
  <name>vser</name>
  <uuid>f6e3dc7d-05a5-4410-ba4c-a9fa24acc68b</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='s390x' machine='s390-ccw-virtio-rhel8.6.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <cpu mode='host-model' check='partial'/>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/avocado/data/avocado-vt/images/jeos-27-s390x-clone.qcow2'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
    </disk>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='virtio-serial' index='0'>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:93:0c:c7'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
    </interface>
    <console type='pty'>
      <target type='sclp' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <audio id='1' type='none'/>
    <hostdev mode='subsystem' type='mdev' managed='no' model='vfio-ccw'>
      <source>
        <address uuid='ca9a7109-469c-4790-bc4d-94ba19718217'/>
      </source>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0002'/>
    </hostdev>
    <memballoon model='virtio'>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0007'/>
    </memballoon>
    <panic model='s390'/>
  </devices>
  <seclabel type='dynamic' model='selinux' relabel='yes'/>
  <seclabel type='dynamic' model='dac' relabel='yes'/>
</domain>

Reproduced with:
virt-manager-3.2.0-3.el8.noarch

Steps:
1. Define (via virsh or virt-install) a VM with XML as in comment#36
2. Start the VM (via virsh or virt-install)
3. Start virt-manager, connect to host where VM from 1. was defined
4. Double click on VM
==> Error is shown but details window never displayed.

Pre-verified with:
virt-manager-3.2.0-4.el8_rc.2792a24f20.noarch

Confirmation tested that the Error above after 4. doesn't show.

Junqin, do you think we should do more regression testing for the commit? ref. https://github.com/virt-manager/virt-manager/commit/cf93e2dbff28fe05d6d45364c579f923b157beb1

Thanks, Jonathon for the scratch-build. I'll set this back to POST.

(In reply to smitterl from comment #37)
> Reproduced with:
> virt-manager-3.2.0-3.el8.noarch
> 
> Steps:
> 1. Define (via virsh or virt-install) a VM with XML as in comment#36
> 2. Start the VM (via virsh or virt-install)
> 3. Start virt-manager, connect to host where VM from 1. was defined
> 4. Double click on VM
> ==> Error is shown but details window never displayed.
> 
> Pre-verified with:
> virt-manager-3.2.0-4.el8_rc.2792a24f20.noarch
> 
> Confirmation tested that the Error above after 4. doesn't show.
> 
> Junqin, do you think we should do more regression testing for the commit?
> ref.
> https://github.com/virt-manager/virt-manager/commit/
> cf93e2dbff28fe05d6d45364c579f923b157beb1
> 
> Thanks, Jonathon for the scratch-build. I'll set this back to POST.

Hi smitterl,
To be honest, I can't reproduce the https://bugzilla.redhat.com/show_bug.cgi?id=1995125#c26 on the x86_64 platform with virt-manager-3.2.0-3.el8.noarch.
Steps followed comment#6.

And what's the special part of comment#36, then I can define such VM on the x86_64 platform, thanks?

BR,
juzhou.

I am not 100% sure, but I can "fix" the error by making sure that the VM has consoles, graphical and text. I assume this is related with the menu item "View -> Consoles". If that list is empty the error would trigger.

I came to this conclusion after adding print() for (label, dev, tooltip) around where the error occurs[1] and started virt-manager with the --debug flag.

Initially I used a minimal XML, removing all but the <disk> below the <devices> node and it reproduced, the triplet with values
(label, dev, tooltip) = (No graphical console available, None, None)

After adding a graphics element I hit it again but with
(label, dev, tooltip) = (No text console available, None, None)

So I also added a text console and then could see the details.

IIRC, there might also be some caching; I assume the safest way to try this is:

1. Define a VM that doesnt' have any text or graphical consoles and start the vm
2. Make sure to close all virt-manager instances first
3. Open virt-manager and double click on the machine
==> the error pops up (screenshot attached).


[1]  File "/usr/share/virt-manager/virtManager/details/console.py", line 281, in rebuild_menu
    item.set_sensitive(sensitive)
TypeError: Argument 1 does not allow None as a value

Created attachment 1865175 [details]
error window

Hi Sebastian, Thanks for your comment, I am able to reproduce this bug:
packages:
virt-manager-3.2.0-3.el8.noarch
virt-install-3.2.0-3.el8.noarch

Step 1: Run this command to install a vm with --graphics=none or --console=none
virt-install \
--disk /home/vm04.img,size=20 \
--location http://download.eng.pek2.redhat.com/rhel-8/composes/RHEL-8/RHEL-8.7.0-20220305.2/compose/BaseOS/x86_64/os/ \
--graphics=none| --console=none

Step 2: Start virt-manager and click vm to get details.

Result: an error pops up same with smitterl's attachment 1865175 [details]

Now Pre-Verify this bug with
Packages:
virt-manager-3.2.0-4.el8.noarch
virt-install-3.2.0-4.el8.noarch

Step 1: Run this command to install a vm with --graphics=none, --console=none
virt-install \
--disk /home/vm04.img,size=20 \
--location http://download.eng.pek2.redhat.com/rhel-8/composes/RHEL-8/RHEL-8.7.0-20220305.2/compose/BaseOS/x86_64/os/ \
--graphics=none| --console=none

Step 2: Start virt-manager and click vm to get details.

Virtual hardware details show correctly and no errors pop up while clicking each option.

Base on this result I add Verified:tested for this bz, Thanks

Verify this bug with
Packages:
virt-manager-3.2.0-4.el8.noarch
virt-install-3.2.0-4.el8.noarch

Step 1: Run this command to install a vm with --graphics=none, --console=none
virt-install \
--disk /home/vm.img,size=20 \
--location http://download.eng.pek2.redhat.com/rhel-8/composes/RHEL-8/RHEL-8.7.0-20220305.2/compose/BaseOS/x86_64/os/ \
--console=none

Step 2: Start virt-manager GUI, click the vm just created, check the display and vm details

Result: The Graphic console display normal and all options in vm details can be checked correctly.


Base on this result, I change the status for this bug to Verified.

@

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt-manager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1862