Bug 499223 - Add virt-install --virt-type option and make kvm the default
Add virt-install --virt-type option and make kvm the default
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: python-virtinst (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F12VirtTarget
  Show dependency treegraph
 
Reported: 2009-05-05 12:29 EDT by James Laska
Modified: 2013-09-02 02:35 EDT (History)
5 users (show)

See Also:
Fixed In Version: python-virtinst-0.500.0-1.fc12.noarch
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-15 06:29:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.