If I create a new VM on an x86_64 host using virt-manager and select i686 as the arch for the guest, the guest still ends up being created as an x86_64 guest. virt-manager-0.7.0-4.fc11.x86_64 python-virtinst-0.400.3-7.fc11.noarch libvirt-0.6.2-3.fc11.x86_64 Basically, just choose i686 from the arch drop down, create the guest and observe that the guest is configured as: <domain type='kvm'> <name>rawhide-2009-05-04-i386</name> <currentMemory>1048576</currentMemory> <memory>1048576</memory> <uuid>348f2ee2-84e2-aea0-f58f-4e322a1109ad</uuid> <os> <type arch='x86_64'>hvm</type> <kernel>/home/markmc/.virtinst/boot/virtinst-vmlinuz.jjkcj2</kernel> <initrd>/home/markmc/.virtinst/boot/virtinst-initrd.img.zVt9nC</initrd> <cmdline>method=http://ftp.heanet.ie/mirrors/fedora/linux/development/i386/os/</cmdline> </os> <features> <acpi/><apic/><pae/> </features> <clock offset="utc"/> <on_poweroff>destroy</on_poweroff> <on_reboot>destroy</on_reboot> <on_crash>destroy</on_crash> <vcpu>2</vcpu> <devices> <emulator>/usr/bin/qemu-kvm</emulator> ... Looking at the code, vmmCreate.arch_changed() does nothing - at a glance it looks like we should be calling change_caps() and passing the arch to CapabilitiesParser.guest_lookup() ?
Yep, it was indeed doing nothing :) I must have forgotten to wire that up. Fix is exactly what you described: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/c299f80bbc9f Moving to POST.
Pushing an update to updates-test with Cole's fix for this; please add a comment to bodhi if you test this * Thu May 21 2009 Mark McLoughlin <markmc> - 0.7.0-5.fc11 - Fix 'opertaing' typo in 'New VM' dialog (#495128) - Allow details window to resize again (#491683) - Handle collecting username for vnc authentication (#499589) - Actually handle arch config when creating a VM (#499145) - Log libvirt capabilities at startup to aid debugging (#500337)
virt-manager-0.7.0-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/virt-manager-0.7.0-5.fc11
virt-manager-0.7.0-5.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update virt-manager'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-5410
*** Bug 502669 has been marked as a duplicate of this bug. ***
I updated to virt-manager-0.7.0-5.fc11 and now when trying to create a ppc machine, it fails because it specifies '-M g3bw' to qemu-system-ppc when the option should be '-M g3beige' or nothing because g3beige is apparently the default. From the log: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-system-ppc -S -M g3bw -m 1024 -smp 1 -name sawhorse -uuid d88aa53c-db68-4091-56df-1a8010e8c4e7 -monitor pty -pidfile /var/run/libvirt/qemu//sawhorse.pid -no-reboot -boot d -drive file=/var/lib/libvirt/images/sawhorse-3.img,if=ide,index=0 -drive file=/tmp/Fedora-9-ppc-DVD.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:11:c0:91,vlan=0 -net tap,fd=22,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 Supported machines are: g3beige Heathrow based PowerMAC (default) mac99 Mac99 based PowerMAC prep PowerPC PREP platform ref405ep ref405ep taihu taihu bamboo bamboo mpc8544ds mpc8544ds
The only place I could find a reference to g3bw was in /usr/share/libvirt/schemas/domain.rng but after I changed it to g3beige there, restarted libvirtd, and tried again, it didn't fix it. Same error.
The 'g3bw' machine value is hardcoded into libvirt source unfortunately. Please file this issue separately against libvirt, as the virt-manager issue is fixed. Thanks.
virt-manager-0.7.0-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.