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): qemu-system-arm-1.0.1-1 How reproducible: always 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>): <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE 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'> <name>vexpress</name> <uuid>260159b3-e738-9c3e-a1cf-9d5cd574501a</uuid> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu>1</vcpu> <os> <type arch='arm' machine='vexpress-a9'>hvm</type> <kernel>/home/kramer/vexpress/armhfp-vexpress-xfce-mmcblk0/boot/vmlinuz-3.4.2-3.fc17.armv7hl</kernel> <initrd>/home/kramer/vexpress/armhfp-vexpress-xfce-mmcblk0/boot/initramfs-3.4.2-3.fc17.armv7hl.img</initrd> <cmdline>console=ttyAMA0,115200n8 rw root=/dev/mmcblk0p2 rootwait physmap.enabled=0</cmdline> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-arm</emulator> <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'/> </disk> <controller type='scsi' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <interface type='user'> <mac address='52:54:00:88:23:a5'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> </domain>
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.
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*" qemu-common-1.2.0-11.fc18.x86_64 qemu-system-arm-1.2.0-11.fc18.x86_64 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).
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.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
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.
Closing CURRENTRELEASE for F18