Daniel P. Berrange wrote:
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..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.
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.
Thats the situation for now.If you're enabling PV drivers, you don't care about specific QEMU nic types.
-- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com