Proposed as a Blocker for 25-final by Fedora user sgallagh using the blocker tracking app because:

 "The release must be able host virtual guest instances of the same release." (Beta Criterion)

I can't reproduce this. Can you upload your VM xml definition file (virsh dumpxml VM_name)?

"virtio1.0-input" is a device name in libosinfo, and not valid to pass to libvirt. IOW, this is probably a virt-manager bug, mistakenly doing straight passthrough from libosinfo.

Created attachment 1217016 [details]
Picture of the auto-added devices

I'm attaching a screenshot of the custom hardware dialog. The offending device appears to be the one I selected here.

I didn't add it manually; it just showed up by default.


For further information, I selected "Linux: Fedora 24" as the OS type, created a custom qcow2 file for the storage and picked 4096MB RAM and 2 CPUs.

For the record, I'm running libosinfo-1.0.0-1.fc25.x86_64 as well.

Created attachment 1217113 [details]
fpaste sysinfo

Attaching system info.

Seeing the same error, reproducible with:

sudo virt-install --name Fedora_25 --ram 4096 --arch x86_64 --disk size=8 --nographic --os-variant fedora23 --location http://kojipkgs.fedoraproject.org/compose//branched/Fedora-25-20161103.n.0/compose/Everything/x86_64/os/ --extra-args="console=ttyS0"

Starting install...
Retrieving file vmlinuz...                                                                                                                                                                                            | 6.5 MB  00:00:00     
Retrieving file initrd.img...                                                                                                                                                                                         |  49 MB  00:00:04     
Allocating 'Fedora_25-2.qcow2'                                                                                                                                                                                        | 8.0 GB  00:00:00     
ERROR    unsupported configuration: unknown input device type 'virtio1.0-input'
Removing disk 'Fedora_25-2.qcow2'                                                                                                                                                                                     |    0 B  00:00:00     
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///system start Fedora_25
otherwise, please restart your installation.


libosinfo-1.0.0-1.fc25.x86_64
libvirt-2.2.0-1.fc25.x86_64
virt-install-1.4.0-3.fc25.noarch
virt-manager-1.4.0-3.fc25.noarch

I can confirm I see the same error as Paul when running virt-install also.

also failing here with:

virt-install -n ${vmname} \
            --memory memory=1536,maxmemory=4096 \
            --vcpus vcpus=1,maxvcpus=3 \
            --cpu host \
            --clock offset=utc,kvmclock_present=yes \
            --features acpi=on,apic=on \
            --location "${vmurl}" \
            --extra-args "ks=${vmks}" \
            --disk pool=default,size=20,bus=scsi,sparse=yes,format=raw \
            --network network=default,model=virtio \
            --graphics spice \
            --sound none \
            --controller scsi,model=virtio-scsi \
            --channel spicevmc,target_type=virtio \
            --channel unix,target_type=virtio,name=org.qemu.guest_agent.0 \
            --video qxl \
            --memballoon virtio \
            --rng /dev/random \
            --noautoconsole 

where vmurl is the fedoraproject repo url for install

this fails with bot a fraw and f25 target ... it worked for a rhel6 target with a 6.8 iso loop mounted

virt-install-1.4.0-3.fc25.noarch

cpuinfo:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 94
model name	: Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz
stepping	: 3
microcode	: 0x9e
cpu MHz		: 1015.655
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 4611.91
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

I booted up another laptop I had (Dell XPS 15 L502x) using the Workstation Live image snapshot from yesterday. I installed the virt-install package in the live environment and tried the virt-install command from comment #7 above.

Same result. (Which tells me it's not likely to be an upgrade-related issue). Perhaps hardware?


processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x15
cpu MHz		: 827.551
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts
bugs		:
bogomips	: 4390.15
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

OK, I did some further investigation. It looks like this incorrect device only gets added when `--os-variant is fedora23 or fedora24. Older Fedora selections and all RHEL selections are unaffected.

So presumably someone made a mistake in the defaults provided by those two profiles.

THis isn't a mistake in libosinfo defaults - the data is all correct. The mistake is virt-manager's interpretation of the data per comment #3.

It is in fact already fixed in virt-manager upstream

commit 1d2cd306773064258f5d02c980b09a683ae77798
Author: Cole Robinson <crobinso>
Date:   Fri Jul 29 13:17:36 2016 -0400

    osdict: Fix incorrect usage of virtio input

Created attachment 1217480 [details]
Patch for dist-git to apply upstream patch

I'm attaching a patch for virt-manager dist-git that applies the upstream fix for this issue.

Dan or Cole, would one of you please review it and either apply and build it or else give me permission to do so? (I have provenpackager status, so I can take care of it).

I've done a scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=16290113

I tested it locally; it appears to resolve this issue for me. Paul, James: can you confirm as well?

(In reply to Stephen Gallagher from comment #15)
> I've done a scratch build at
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16290113
> 
> I tested it locally; it appears to resolve this issue for me. Paul, James:
> can you confirm as well?

Confirmed, working here after installing the scratch build.

I'm probably +1 blocker on this, I tend to consider virt-manager and boxes part of the 'official' virt stack. Definitely +1 FE.

Sorry for the delay, I'll do a build now

virt-manager-1.4.0-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-878c340781

virt-manager-1.4.0-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-878c340781

I can confirm that this update fixes the bug (I've provided karma on Bodhi).

This update is tested working for me as well using virt-install on a fedora 25 host to install a f25 guest.

Discussed during the 2016-11-07 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made as this is a violation of "The release must be able host virtual guest instances of the same release" in the case of using virt-manager, which is one of the two prime front ends for the 'Fedora virt stack'.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-11-07/f25-blocker-review.2016-11-07-17.01.txt

virt-manager-1.4.0-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.