Re: PATCH: Support NIC model selection for QEMU/KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 22, 2007 at 05:23:47PM -0400, Jim Paris wrote:
> Daniel P. Berrange wrote:
> > On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote:
> > > On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote:
> > > > Hi,
> > > > 
> > > > Sometime between kvm-36 and kvm-46 I ran into problems with the
> > > > default QEMU network card (ne2k-pci).  Switching it fixed the
> > > > problems, but libvirt doesn't support changing the NIC model.
> > > > These patches add support for:
> > > > 
> > > >   <interface>
> > > >     <nic model="rtl8139"/>
> > > >   </interface>
> > > > 
> > > > which becomes
> > > > 
> > > >   qemu -net nic,model=rtl8139,mac=...
> > > > 
> > > > By default, no model is appended to the qemu command line, as before.
> > > > Documentation update & some fixes are included too.
> > > 
> > >   Hum, 
> > > 
> > > I would really prefer if we were able to identify the issue and
> > > fix it transparently for the user (for example by detecting the
> > > kvm version if possible) rather than add an option in the permanent
> > > data file just to make stuff work. I hope this is possible, but
> > > can't really tell.
> > 
> > In Fedora/RHEL we simply switched  Xen, QEMU and KVM to all use rtl8139 by 
> > defualt since ne2k is crap.
> 
> Getting it fixed upstream might be best.  We could also just have
> libvirt always append "model=rtl8139", but I'd be concerned that we
> could break existing VMs for some users if we swap out the network
> card unexpectedly.  An upstream change would have the same problem.
> 
> Regardless of what the defaults are, I don't think exposing a knob
> that lets you control what NIC the guest sees is that much of a hack;
> describing the guest hardware is what the config xml is mostly for.

  Agreed. The specifics of the hardware configuration emulated for the
domain have their place in the XML file. But I'm not sure what other 
compatibility issues may arise if we applied such a patch.
  Also I hate seeing a patch rot in the list archive without proper process
but I don't feel like I understand all the issues at stake here to really
try to apply it myself ...
  What would we beak by applying this patch, and can this be fixed ?

Daniel, wondering ...

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]