Bug 1585991 - RFE: support qemu ppc64 powernv machine
Summary: RFE: support qemu ppc64 powernv machine
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: ppc64le
OS: Linux
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
Depends On:
Blocks: PPCTracker
TreeView+ depends on / blocked
Reported: 2018-06-05 09:05 UTC by Dan Horák
Modified: 2018-07-18 16:02 UTC (History)
13 users (show)

Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Dan Horák 2018-06-05 09:05:36 UTC
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
    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

Comment 1 Dan Horák 2018-06-05 09:13:50 UTC
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

Comment 2 Peter Krempa 2018-06-05 09:46:09 UTC
Looks like virt-manager creates wrong defaults for the VM. Reassigning.

Comment 3 Cole Robinson 2018-06-07 15:15:59 UTC
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">
    <type arch="ppc64" machine="powernv">hvm</type>
    <boot dev="hd"/>
  <clock offset="utc"/>

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

Comment 4 Dan Horák 2018-06-08 13:11:45 UTC
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.

Comment 5 Thomas Huth 2018-06-27 13:17:01 UTC
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).

Comment 6 Cedric Le Goater 2018-06-27 13:22:10 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.