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 -=|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list