Description of problem: Creating a VM with "ppc64" architecture and "powernv" machine type in virt-manager fails with a traceback. Can't finish installation: 'unsupported configuration: IDE controllers are unsupported for this QEMU binary or machine type' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 2545, in _do_async_install guest.start_install(meter=meter) File "/usr/share/virt-manager/virtinst/guest.py", line 498, in start_install doboot, transient) File "/usr/share/virt-manager/virtinst/guest.py", line 434, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3640, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: unsupported configuration: IDE controllers are unsupported for this QEMU binary or machine type Version-Release number of selected component (if applicable): libvirt-4.3.0-1.fc28.ppc64le (from fedora virt preview copr repo) but virt-manager-1.4.3-2.fc26.noarch (and virt-manager-1.6.0-0.1.git3bc7ff24c.fc28.noarch too) is remote (on x86_64) How reproducible: Steps to Reproduce: 1. add new VM with ppc64/powernv type
after swapping the IDE disk to virtio based one and removal of IDE CD-ROM (using the "Edit config before installation" option it gets a bit further, now complains about incorrect CPU type
Looks like virt-manager creates wrong defaults for the VM. Reassigning.
I can't find any real examples of working powernv qemu command lines that virt-manager is going to realistically support. Dan is this something you expect to work? Even with a minimal config: <domain type="qemu"> <name>fedora-unknown-ppc64</name> <uuid>3f936d40-b22c-4a27-b174-ee5198325e8b</uuid> <memory>2097152</memory> <currentMemory>2097152</currentMemory> <vcpu>1</vcpu> <os> <type arch="ppc64" machine="powernv">hvm</type> <boot dev="hd"/> </os> <clock offset="utc"/> <devices> <emulator>/usr/bin/qemu-system-ppc64</emulator> </devices> </domain> Libvirt tries to add memballoon, usb, pci, which fails since there's no pci bus for this machine type. Explicitly model='none' on those devices, I still get this: error: Failed to start domain fedora-unknown-ppc64 error: internal error: process exited while connecting to monitor: 2018-06-07T15:13:52.863105Z qemu-system-ppc64: error creating device tree: (fdt_property_string(fdt, "system-id", buf)): FDT_ERR_BADMAGIC
Good question, /me now wonders if it's supposed to work with a virtio disk image and a network device at all, instead of being useful only for skiboot testing. But I've found http://www.kaod.org/openpower/qemu/ which makes me a a little optimistic, but likely we are not there yet.
As far as I know, the powernv machine in upstream QEMU is still quite incomplete. I just asked Greg on IRC, and he pointed me to try https://github.com/legoater/qemu/commits/powernv-3.0 which should be more advanced, e.g. there is a PCI controller now (see https://github.com/legoater/qemu/commit/208a08b03f31bfa7c6).
The PowerNV QEMU machine does not have a PCI host bridge controller model. So adding any storage or net devices will just fail. If you want to give it a try, the tree https://github.com/legoater/qemu has a model for the PHB3 (POWER8 PCI controller). This is currently under discussion and, possibly, it will be merged in 3.1.
I think we can close this bz, I have made qemu 4.2 + powernv patchset available in https://copr.fedorainfracloud.org/coprs/sharkcz/talos/. It's a drop-in replacement for qemu from the virt-preview repo.