Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Add virt-install --virt-type option and make kvm the default|
|Product:||[Fedora] Fedora||Reporter:||James Laska <jlaska>|
|Component:||python-virtinst||Assignee:||Daniel Berrange <berrange>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||berrange, crobinso, jturner, markmc, virt-maint|
|Fixed In Version:||python-virtinst-0.500.0-1.fc12.noarch||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-09-15 06:29:34 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description James Laska 2009-05-05 12:29:51 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): * python-virtinst-0.400.3-7.fc11.noarch How reproducible: * everytime 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" Actual results: # virsh dumpxml vguest1 | grep qemu <emulator>/usr/bin/qemu-system-x86_64</emulator> Expected results: # virsh dumpxml vguest1 | grep qemu <emulator>/usr/bin/qemu-kvm</emulator> Additional info: * As suggested by markmc, adding the following virt-install command-line options (as noted in the --help) will enable kvm hardware virtualization. " -v --accelerate "
Comment 1 Mark McLoughlin 2009-05-05 13:21:05 EDT
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
Comment 2 Daniel Berrange 2009-05-05 15:01:29 EDT
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 --virt-type=qemu|kqemu|kvm|xen|... which maps to the '<domain type='qemu|kqemu|...'> in XML.
Comment 3 James Laska 2009-05-05 15:11:39 EDT
(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 > > --virt-type=qemu|kqemu|kvm|xen|... > > 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' ... --virt-type=VIRT_TYPE ex: 'xenpv', 'qemu'
Comment 4 Daniel Berrange 2009-05-05 15:21:38 EDT
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).
Comment 5 Cole Robinson 2009-05-06 08:56:15 EDT
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.
Comment 6 Daniel Berrange 2009-05-06 09:07:23 EDT
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.
Comment 7 Cole Robinson 2009-05-06 09:19:17 EDT
Yeah, I see what you mean. I'll stick with the --virt-type options you proposed.
Comment 8 Cole Robinson 2009-06-15 14:18:43 EDT
--virt-type is now upstream: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/238f8cc1568f And --accelerate is now the default behavior: http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virtinst--devel/rev/bec888f2890f Moving to POST.
Comment 9 Mark McLoughlin 2009-09-15 06:29:34 EDT
This appears to be in rawhide now