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
File "/usr/share/virt-manager/virtinst/guest.py", line 498, in start_install
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)
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:
<type arch="ppc64" machine="powernv">hvm</type>
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.