Bug 863800

Summary: qemu-system-arm does not honour -no-acpi preventing usage with libvirt/virt-manager
Product: [Fedora] Fedora Reporter: Jurgen Kramer <gtmkramer>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 18CC: amit.shah, berrange, cfergeau, clalancette, crobinso, dwmw2, itamar, jforbes, jyang, knoel, laine, libvirt-maint, loganjerry, pbonzini, pbrobinson, rjones, scottt.tw, sergio.pasra, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-29 02:42:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418    

Description Jurgen Kramer 2012-10-07 14:12:35 UTC
Description of problem:
qemu-system-arm does not support the -no-acpi option preventing it from being used with libvirt/virt-manager

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create ARM VM
2. Add to libvirt (virsh define <name>)
3. Start: virsh start <name>
Actual results:
ARM VM does not start due to 'Option no-acpi not supported on this target' error.

Expected results:
ARM VM shoud just start (either qemu-system-arm should honour no-acpi or libvirt should not add this option for ARM targets).

Additional info:
virsh start vexpress
error: Failed to start domain vexpress
error: internal error process exited while connecting to monitor: Option no-acpi not supported for this target

vexpress.xml (generated with virsh domxml-from-native qemu-argv <file with qemu args>):

OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit vexpress
or other application using the libvirt API.

<domain type='qemu'>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
    <type arch='arm' machine='vexpress-a9'>hvm</type>
    <cmdline>console=ttyAMA0,115200n8 rw root=/dev/mmcblk0p2 rootwait physmap.enabled=0</cmdline>
    <boot dev='hd'/>
  <clock offset='utc'/>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/home/kramer/vexpress/Fedora-17-armhfp-vexpress-xfce-mmcblk0.img'/>
      <target dev='sd' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    <controller type='scsi' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    <interface type='user'>
      <mac address='52:54:00:88:23:a5'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>

Comment 1 Richard W.M. Jones 2012-10-07 16:34:10 UTC
I think the problem is more likely with libvirt
which shouldn't be passing this option if qemu-system-arm
doesn't recognize it.

Please recheck if this still occurs on Fedora 18.

Comment 2 Jurgen Kramer 2012-10-07 16:46:58 UTC
At least qemu-system-arm itself does not support -no-acpi on F18:

[root@localhost ~]# qemu-system-arm -no-acpi
Option no-acpi not supported for this target

[root@localhost ~]# rpm -qa "qemu*"

Only running F18 in a VM atm so I cannot check if libvirt for F18 is fixed (ie no longer passes no-acpi option to qemu-arm).

Comment 3 Daniel Berrangé 2012-10-08 10:30:06 UTC
The following commit to libvirt changed it so that -no-acpi is only used for x86/x86_64 guests.

commit 5e6ce1c936d242c82d56d249674c210078e4532d
Author: Prerna Saxena <prerna@linux.vnet.ibm.com>
Date:   Mon Nov 21 18:20:42 2011 +0530

    Clean up qemuBuildCommandLine to remove x86-specific
     assumptions from generic code.

It is in libvirt 0.9.9 or later, so this shouldn't be a problem in F18 anymore

Comment 4 Jurgen Kramer 2012-10-08 12:37:24 UTC
Unfortenunately the mentioned commit not fix the problem.
Libvirt in F17 is already at 0.9.11 (that commit is from November 2011).
So problem is not fixed.

Comment 5 Cole Robinson 2013-06-29 02:42:01 UTC