>> Sadly that is not true. For instance on Ubuntu Precise >> it's invoked as qemu-system-x86_64 by at least one >> management application known to me. > > Well change it to call qemu-kvm then :) > Also what happens if you install qemu as well? > Does it conflict? I'm not an Ubuntu maintainer but AFAIK qemu-kvm is deprecated. It may only be there to support upgrades. We still need to support migration from qemu running on Precise to qemu running on Trusty. The trusty instance may not have qemu-kvm installed. If we were looking at argv[0], we'd really want to look at it on the /sending/ machine. Forcing qemu to be involved as qemu-kvm solely on the basis some users might want to migrate a VM in from a previous version does not sound practical. >> I'm not quite sure why you say "legacy management >> applications". > > Because any non legacy one can be patched. Well this is where we diverge. I think the distro needs a way to change the default behaviour, i.e. so the existing command line will do something different. >> This applies to /any/ management application. >> Unless we're going to burden every management application >> with this problem, we need to fix it. >> >> Just as a reminder, the ./configure value defaults to >> off, which means there is no change in current behaviour. > > Yes but this still perpetuates the mess. > > If you prefer using -M pc-1.0, add a new property > and teach management to set it. > > But no silent compile-time behind the scenes changes please. OK, how about we keep the aliases, and make pc-1.0 default to the pc-1.0-qemu-git. We then add a command line option to make pc-1.0 mean pc-1.0-qemu-kvm, with that obviously defaulting to off. Then distros can then put the option in /etc/qemu/target-x86_64.conf or whatever. -- Alex Bligh -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list