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

Re: [Libvir] PATCH: Support NIC model selection for QEMU/KVM



On Wed, Oct 31, 2007 at 09:34:33AM -0400, Daniel Veillard wrote:
> 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 ...

Having thought about it, I think its reasonable to aply some variant of
this patch. Guest a question of how we want to present it as XML. Just to
present some variants...

   <interface type="bridge">
      <nic model="rtl8139"/>
      <source bridge="xenbr0"/>
      <target dev="vif1.0"/>
   </interface>

   <interface type="bridge" model="rtl8139">
      <source bridge="xenbr0"/>
      <target dev="vif1.0"/>
   </interface>

   <interface type="bridge">
      <model>rtl8139</model>
      <source bridge="xenbr0"/>
      <target dev="vif1.0"/>
   </interface>

   <interface type="bridge">
      <source bridge="xenbr0"/>
      <target dev="vif1.0" model="rtl8139"/>
   </interface>


I guess I'd lean towards the first variant, which was Jim's original
suggestion.

Of course for any of this to solve Jim's problem, we need virt-install
and / or  virt-manager to explicitly ask for the RTL8139 nic when
creating new guests, otherwise you're still at the mercy of the underlying
default NIC choice in QEMU/KVM/XEn which may or may not be RTL8139.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


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