[libvirt] Allowing <interface type="none"> for network interface definition

Gihan Munasinghe GMunasinghe at Xcalibre.co.uk
Tue Dec 2 23:37:31 UTC 2008


Daniel P. Berrange wrote:
> On Tue, Dec 02, 2008 at 09:24:24PM +0000, Gihan Munasinghe wrote:
>   
>
> The "type" attribute is used to specify how the network card is connected
> to the host networking. You're after something that changes what is 
> exposed tto the guest.  The XML format for network interfaces already has 
> support for a model element which accomplishes this. eg, for KVM we can
> select VirtIO network card with:
>
>     <interface type='bridge'>
>         <model type="virtio"/>
>         <source bridge='br0'/>
>         <mac address='00:16:3e:00:a5:57'/>
>     </interface>
>
>   
Hi Daniel

Thanks for the reply
by using type=none what I meant was asking qemu-dm not to make any 
configurations what so ever. so I am asking qemu-dm to not to present a 
network card to vm at all..
> This 'model' is not currently used in the Xen driver for libvirt, so
> we should implement it. A value of 'none' doesn't really make sense.
> For Xen >= 3.1.0, libvirt will no longer append type=ioemu by default.
> This lets XenD configure by rtl8139 nic, and PV driver back/front.
>
> So I think we just need to allow an explicit choice to override this
>
> A couple of choices, either follow XenD's naming
>
>    <model type="ioemu"/>
>    <model type="netback"/>
> Or take into account we might want to allow for full range of QEMU
> nic choices, even if XenD doesn't (yet) expose it
>
>    <model type="rtl8139"/>
>    <model type="e1000"/>
>    <model type="ne2k_pci"/>
>    <model type="netback"/>
>
> I think i tend towards the latter, since its more consistent with naming
> in QEMU driver.
>
> Daniel
>   

This is some code segments I took out from xend_internal. c

if (def->ifname != NULL &&
        !STRPREFIX(def->ifname, "vif"))
        virBufferVSprintf(buf, "(vifname '%s')", def->ifname);

    if (def->model != NULL)
        virBufferVSprintf(buf, "(model '%s')", def->model);


So the model tag is already send to xend, and used in xend as well 
check the following xend code 

for devuuid in vmConfig['vif_refs']:
            devinfo = vmConfig['devices'][devuuid][1]
            dtype = devinfo.get('type', 'ioemu')
            if dtype != 'ioemu':
                continue
            nics += 1
            mac = devinfo.get('mac')
            if mac is None:
                raise VmError("MAC address not specified or generated.")
            bridge = devinfo.get('bridge', 'xenbr0')
            model = devinfo.get('model', 'rtl8139')
            ret.append("-net")
            ret.append("nic,vlan=%d,macaddr=%s,model=%s" %
                       (nics, mac, model))
            ret.append("-net")
            ret.append("tap,vlan=%d,ifname=tap%d.%d,bridge=%s" %
                       (nics, self.vm.getDomid(), nics-1, bridge))

        if nics == 0:
            ret.append("-net")
            ret.append("none")

Therefore only way I can achieve -net none switch, is by sending a (type != ioemu ) tag. sending in a ( model ) tag will not give me what I want. So simply I just want to update my xenstore configuration but I am going to ask qemu not to load any network at all.. So as far as 
qemu is concerned the domain does not have any network.. -net none. That's what I thought of using something like <interface type="none">. Am I missing something here.. 

Just to let you know, This is what I changed on the level of xend_internal.c 

 if ((hvm) && (xendConfigVersion < 4) && (def->type!=VIR_DOMAIN_NET_TYPE_NONE))
        virBufferAddLit(buf, "(type ioemu)");
    else{
                //Only send type none if the <interface type="none" vm formats>
                virBufferAddLit(buf, "(type none)");
        }

I need to send a explicit (type none) or any ( type !ioemu) to get the desired outcome. Thought none would make sense as I don't want any network configured  

Thanks 
Gihan

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


More information about the libvir-list mailing list