Red Hat Bugzilla – Bug 499223
Add virt-install --virt-type option and make kvm the default
Last modified: 2013-09-02 02:35:18 EDT
Description of problem:
Using the same virt-install command from my previous F10 system results in a qemu guest (not a KVM guest). This bug is meant as a humble request to make "-v --accelerate" the default for virt-install.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ virt-install -n vguest1 -r 1024 --vcpus 2 --os-variant fedora11 -b br0 -l http://gromit.redhat.com/pub/fedora/linux/development/x86_64/os -f $DISKS --arch x86_64 --nographics -x "console=ttyS0 lang=en keymap=us ip=dhcp vnc"
# virsh dumpxml vguest1 | grep qemu
# virsh dumpxml vguest1 | grep qemu
* As suggested by markmc, adding the following virt-install command-line options (as noted in the --help) will enable kvm hardware virtualization.
" -v --accelerate "
Yeah, I got bitten by this today - forgot to use --accelerate and took a while to figure out what was wrong
I don't think anyone would complain about making it the default - it would be very rare that people *don't* want KVM used if it is available; perhaps you would need to add --noaccelerate, though
I should never have added the '--accelerate' option in the first place - its a dumb name, and dumb default :-)
I agree we should make it 'do the right thing' by default, ie pick KVM.
Adding --noaccelerate though would compound the flaw of the original arg.
Instead, we should add ability to request override, with a specific virt type, either by allowing --accelerate to take an arg, or creating a new option, eg
which maps to the '<domain type='qemu|kqemu|...'> in XML.
(In reply to comment #2)
> Instead, we should add ability to request override, with a specific virt type,
> either by allowing --accelerate to take an arg, or creating a new option, eg
> which maps to the '<domain type='qemu|kqemu|...'> in XML.
From a user perspective, that seems really intuitive. Not that it matters, but it maps well to how cobbler/koan configure virt systems. From 'cobbler system edit --help' ...
ex: 'xenpv', 'qemu'
Seems that cobbler is mixing up 2 different concepts in one arg there, that of virtualization type, and guest OS ABI type. 'xen' is the virt type, and this can support guests implementing the 'xen' OS ABI (aka xen paravirt) or 'hvm' OS ABI (aka xen fullyvirt). 'qemu' is the virt type, and this can also support guests implementing the 'xen' OS ABI (paravirt), or 'hvm' OS ABI (fullyvirt).
Actually, I think squishing --paravirt and --fullvirt into the --virt-type option is a good idea. True it doesn't map to the underlying concepts, but I think it would be much clearer just mapping them to --virt-type=xenpv|xenfv. This is essentially what we did for the redesigned New VM wizard in virt-manager.
Aside from that detail, I'm all for deprecating --accelerate and making its behavior the default, which I'll do upstream for the next release.
I really don't think that is a good idea, because it will unduly restrict virt-install's ability to use new capabilities exposed by libvirt drivers, and means you can't specify fullvirt vs paravirt, without also having to choose a specific virttype. As more Xen support is merged into upstream QEMU, you'll actually see the libvirt QEMU driver able to manage the Xen hypervisor itself, and the number of combinations of os type & virt type increase still further. For virt-manager I thin kit makes sense that you don't expose these concepts directly because its supposed to isolate people from fine details, but for virt-install I think it is better to give more direct control to people.
Yeah, I see what you mean. I'll stick with the --virt-type options you proposed.
--virt-type is now upstream:
And --accelerate is now the default behavior:
Moving to POST.
This appears to be in rawhide now