[libvirt] [PATCH ] (type ioem) adding qemu nic configuration option in to libvirt (XEN)

Gihan Munasinghe GMunasinghe at Xcalibre.co.uk
Thu Dec 4 22:33:28 UTC 2008


Daniel P. Berrange wrote:
> On Thu, Dec 04, 2008 at 09:50:01PM +0000, Gihan Munasinghe wrote:
>   
>> <interface type='bridge' qemu='false'>
>>     
>
> This is not suitable because it is adding attributes that are
> specific to the Xen hypervisor.
>
>   
Why can not this be used with any other hypervisor.  The situation that 
I am concerned here is I want my network to be configured but I don't 
want qemu not to have a emulated nic. That is a user level requirement 
rather than a hypervisor specific requirement..

If name qemu is the problem. We can name it to be "emulate = false" be 
more generic, so this way regardless of the hypervisor we are asking not 
to emulate a nic. and if "emulate = true" with a < model  type='whatever 
model type wanted '> tag . we are asking the whatever hypervisor to 
emulate a nic with a given model.
>>      <mac address='00:16:3e:00:a5:01'/>
>>      <source bridge='eth0'/>
>>      <target dev='vif1.0'/>
>> </interface>
>>     
>
> As I mentioned before this should be handled with the existing
> XML <model> element.
>
>
>   ...no model element...  -> Default QEMU nic + Paravirt Driver backend
>   <model type='e1000'/>  -> Only QEMU's e1000 nic
>   <model type='rtl8139'/>  -> Only QEMU's rtl8139 nic
>   <model type='ne2k_pci'/>  -> Only QEMU's ne2k nic
>   <model type='xen'/>       -> Only Paravirt driver backend
>
>   

The problem with using the model tag is in xend, level (type ioem) is 
different from (model e1000). In any case the (model e1000) to work with 
in XEN you have to send (type ioem) tag asking it to emulate the nic model

What we need to send not to configure a qemu -net bock is something 
called ( type none) not ( model  none ) or (model xen) xend. So what you 
are suggesting is that if we see a < model type='xen' >  treat it a 
different way so that it will send (type none) to XEND. ?
> This doesn't allow us to have the PV driver + an explicit
> choice of QEMU nics, but I don't think that's important.
>   
> If you're enabling PV drivers, you don't care about specific
> QEMU nic types.
>   
Thats the situation for now.

Gihan
>
> Daniel
>   


-- 
Gihan Munasinghe
R&D Team Leader
XCalibre Communications Ltd.
www.flexiscale.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20081204/f3510d20/attachment-0001.htm>


More information about the libvir-list mailing list