LibvirtVIFTypeXMLConfigs
Contents
- 1 Libvirt VIF Type XML configuration
- 1.1 Current configuration
- 1.1.1 Common configuration
- 1.1.2 VIF_TYPE_OVS
- 1.1.3 VIF_TYPE_IVS
- 1.1.4 VIF_TYPE_DVS
- 1.1.5 VIF_TYPE_IOVISOR
- 1.1.6 VIF_TYPE_BRIDGE
- 1.1.7 VIF_TYPE_802_QBG
- 1.1.8 VIF_TYPE_802_QBH
- 1.1.9 VIF_TYPE_HW_VEB
- 1.1.10 VIF_TYPE_MLNX_DIRECT
- 1.1.11 VIF_TYPE_MIDONET
- 1.1.12 VIF_TYPE_VHOSTUSER
- 1.1.13 VIF_TYPE_VROUTER
- 1.1.14 VIF_TYPE_OTHER
- 1.1.15 Proposed: VIF_TYPE_MACVTAP
- 1.2 Consolidated XML configs needed
- 1.1 Current configuration
Libvirt VIF Type XML configuration
This document outlines the way the LibvirtGenericVIFDriver configures networking in Liberty-1 development tree, and also looks at a few proposed new VIF types
Current configuration
Common configuration
A number of aspects of the guest interface configuration are common to all VIF types, though some types do have restrictions on valid values. For example. VIF_TYPE_VHOSTUSER requires a model of virtio.
<interface type="..."> <mac address="01:02:ab:de:03:04"/> <model type="virtio|e1000|...."/> <driver name="vhost|qemu"/> <bandwidth> ....QOS settings... </bandwidth> </interface>
VIF_TYPE_OVS
Primary method:
<interface type="bridge"> <source bridge="br0"/> <target dev="vnet0"/> <portprofile type="openvswitch"> <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f' profileid="something"/> </portprofie> </interface>
Or if firewall filtering is needed, it uses
<interface type="bridge"> <source bridge="br0"/> <target dev="vnet0"/> <filterref name="nwfilter"/> </interface>
VIF_TYPE_IVS
Either
<interface type="ethernet"> <target dev="vnet0"/> </interface>
Or if firewall filtering is needed, it uses
<interface type="bridge"> <source bridge="br0"/> <target dev="vnet0"/> </interface>
VIF_TYPE_DVS
VMWare specific, not used by libvirt
VIF_TYPE_IOVISOR
<interface type="ethernet"> <target dev="vnet0"/> </interface>
VIF_TYPE_BRIDGE
<interface type="bridge"> <source bridge="br0"/> <target dev="vnet0"/> <filterref name="nwfilter"/> </interface>
VIF_TYPE_802_QBG
<interface type="direct"> <source dev="eth0"> <portprofile type="802.1qbg"> <parameters managerid="11" typeid="1193047" typeidversion="2" instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"/> </portprofile> </interface>
VIF_TYPE_802_QBH
<interface type="direct"> <source dev="eth0" mode="vepa"> <portprofile type="802.1qbh"> <parameters profileid="manager"/> </portprofile> </interface>
VIF_TYPE_HW_VEB
<interface type="direct"> <source dev="eth0" mode="passthrough"> </interface>
Or
<interface type="hostdev"> <source dev="00:02:10.2"/> <vlan>3</vlan> </interface>
VIF_TYPE_MLNX_DIRECT
<interface type="direct"> <source dev="eth0" mode="passthrough"> </interface>
VIF_TYPE_MIDONET
<interface type="ethernet"> <target dev="vnet0"/> </interface>
VIF_TYPE_VHOSTUSER
<interface type="vhostuser"> <source type="unix" path="/some/sock" mode="0775"/> </interface>
VIF_TYPE_VROUTER
<interface type="ethernet"> <target dev="vnet0"/> </interface>
VIF_TYPE_OTHER
Dummy placeholder, not used by libvirt.
Proposed: VIF_TYPE_MACVTAP
<interface type='direct'> <source dev='eth0' mode=’vepa|bridge’/> </interface>
Consolidated XML configs needed
Based on what is implemented in existing VIF types and proposed VIF types, it is possible to consoldiate to a limited set of libvirt variants
In fact out of the 15 different VIF types, there are only ultimately 5 distinct libvirt guest configurations used
VIF_TYPE_BRIDGE
<interface type="bridge"> <source bridge="br0"/> <target dev="vnet0"/> <filterref name="nwfilter"/> <vportprofile> .... </portprofile> </interface>
VIF_TYPE_GENERIC
A standalone TAP dev, that is connected to host in unspecified manner
<interface type="ethernet"> <target dev="vnet0"/> </interface>
VIF_TYPE_VHOSTUSER
<interface type="vhostuser"> <source type="unix" path="/some/sock" mode="0775"/> </interface>
VIF_TYPE_PCI_ASSIGNED
<interface type="hostdev"> <source dev="00:02:10.2"/> <vlan>3</vlan> </interface>
VIF_TYPE_DIRECT
<interface type='direct'> <source dev='eth0' mode=’vepa|bridge|passthrough’/> <vportprofile> .... </portprofile> </interface>
As an alternative to specifying a 'mode' it might be desirable to have separate VIF types VIF_TYPE_VEPA, VIF_TYPE_PASSTHROUGH, VIF_TYPE_DEV_BRIDGE