Bug 457055 - Allow specifying disk bus and network interface model (e.g. for virtio)
Summary: Allow specifying disk bus and network interface model (e.g. for virtio)
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virtinst
Version: unspecified
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-29 13:50 UTC by Mark McLoughlin
Modified: 2010-03-16 17:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-03 17:58:36 UTC
Embargoed:


Attachments (Terms of Use)

Description Mark McLoughlin 2008-07-29 13:50:10 UTC
In order to allow creating a guest with virtio devices, we need support in
virtinst such that the guest xml goes from e.g.

    <disk type='file' device='disk'>
      <source file='...'/>
      <target dev='hda'/>
    </disk>

    <interface type='bridge'>
      <source bridge='...'/>
      <mac address='...'/>
    </interface>

to:

    <disk type='file' device='disk'>
      <source file='...'/>
      <target dev='vda' bus='virtio'/>
    </disk>

    <interface type='bridge'>
      <source bridge='...'/>
      <mac address='...'/>
      <model type='virtio'/>
    </interface>

Comment 1 Daniel Berrangé 2008-07-29 13:55:39 UTC
The choice of device type shouldn't be exposed to the user - we should
auto-select the most appropriate choice based on the OS type / variant details.
eg,  Fedora 10, or Ubuntu Hardy Heron shoudl automatically get given a virtio
network, FreeBSD can be given ne2k NIC (iirc it has problems with rtl8139) and
everything else can default to rtl8139.


Comment 2 Mark McLoughlin 2008-07-29 13:57:47 UTC
See ubuntu's patches at:

  https://bugs.launchpad.net/ubuntu/+source/virtinst/+bug/218574

General idea is that OS_TYPES is modified so that for e.g. F9 and later we'd
know to use virtio

Comment 3 Cole Robinson 2008-08-14 21:24:44 UTC
Okay I have this working at the moment, and hopefully a more general infrastructure for adding device defaults in the future.

Couple questions: 
 1) F9 supports virtio? Both disk and net?
 2) At least on my F9 box, using virtio networking and pxe throws an error:
    "No valid PXE rom found for network device"
    Known limitation? Just trying to determine if I should put a special
    case in virtinst for this.

Thanks

Comment 4 Mark McLoughlin 2008-08-15 06:44:55 UTC
(In reply to comment #3)
> Okay I have this working at the moment, and hopefully a more general
> infrastructure for adding device defaults in the future.
> 
> Couple questions: 
>  1) F9 supports virtio? Both disk and net?

Yep.

>  2) At least on my F9 box, using virtio networking and pxe throws an error:
>     "No valid PXE rom found for network device"
>     Known limitation? Just trying to determine if I should put a special
>     case in virtinst for this.

Yeah, I think PXE support is a recent addition on the *host* side. Haven't tried it myself.

Just passing qemu-kvm a kernel/initrd on the command line works fine with virtio.

Comment 5 Cole Robinson 2008-08-17 19:19:44 UTC
Okay, I've added this in upstream:

  f9 and f10 use virtio for disk and net devices
  ubuntu hardy uses it for just net (there's a note about
    lack disk virtio issues in their changelog)
  virtio is skipped for the first network device if using
    pxe. This is at least neccessary for f9, i'll test to
    see if virtio + pxe bombs on rawhide.

Couple related fixes as well:

  virt-install doesn't require both an os type and variant
    specified now, just a variant is sufficient. So to
    test this, only --os-variant fedora9 is needed.
  freebsd6/7 now defaults to using ne2k, as dan mentioned
  openbsd defaults to pcnet, which was mentioned on
    et-mgmt-tools a while back and some openbsd wiki
    pages I found.

Setting this to POST (or should I just close this since
Virtualization is for upstream bugs?)

Comment 6 Cole Robinson 2008-09-03 17:58:36 UTC
I'm closing this since it is fixed upstream.


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