On Wed, Oct 31, 2007 at 03:05:07PM +0000, Daniel P. Berrange wrote:
On Wed, Oct 31, 2007 at 09:34:33AM -0400, Daniel Veillard wrote:
> > 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>
[...]
I guess I'd lean towards the first variant, which was Jim's
original
suggestion.
yes, I prefer that one too
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.
Well at least <nic .../> can be added after creation to guarantee the
profile won't change if the default gets eventually changed.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/