I just posted a proposal for implementing this functionality upstream.

https://www.redhat.com/archives/libvir-list/2011-April/msg00591.html

I notice that this RFE doesn't mention openvswitch at all. Wouldn't that offer all you need, and even more, if there was a plugin for configuring openvswitch in libvirt?

(In reply to comment #5)
> I notice that this RFE doesn't mention openvswitch at all. Wouldn't that offer
> all you need, and even more, if there was a plugin for configuring openvswitch
> in libvirt?

In order to keep the discussion in one place (and to make sure there is full participation, since not everyone on the list is following this bug), I've replied to this question in the mailing list thread given in Comment 4. Please post followups to the mailing list thread.

(the summary is that openvswitch cannot be considered an alternative to the proposed code, but that code will likely make it easier to add support for openvswitch to libvirt)

I just posted a reply to Oved's latest mail on this topic where I propose what the new host network and guest interface XMLM will look like. Please take a look and see if it fits all the requirements:

https://www.redhat.com/archives/libvir-list/2011-April/msg01269.html

Here is the latest proposal for how this will work:

 https://www.redhat.com/archives/libvir-list/2011-June/msg00471.html

Please comment appropriately in followup messages on the mailing list.

A series of patches providing this functionality has been posted upstream:

 https://www.redhat.com/archives/libvir-list/2011-July/msg00149.html

It is functionally complete, and has gone through rudimentary testing.

A series of patches to support this has been pushed upstream, and will be in the next libvirt upstream release:

commit 6fe5fde2922405176fbe9315971ab818193af0e0
Author: Laine Stump <laine>
Date:   Tue Jul 19 22:08:15 2011 -0400

    util: define MAX
    
commit a3d95b550bf6a1fa032d7cc70352c88685670bac
Author: Laine Stump <laine>
Date:   Wed Jun 29 00:38:10 2011 -0400

    conf: put virtPortProfile struct / functions in a common location
    
commit 524655eea2500196a98af20be3edfa198f870e85
Author: Laine Stump <laine>
Date:   Mon Jul 18 18:44:38 2011 -0400

    conf: virDomainNetDef points to (rather than contains) virtPortProfile
    
commit 07f4136993c3cce619ff92f4687171a335f6bf51
Author: Laine Stump <laine>
Date:   Sun Jun 26 04:09:00 2011 -0400

    conf: support abstracted interface info in domain interface XML
    
commit 40fd7073befbd6e8ed2b6935898079bb2ff874dd
Author: Laine Stump <laine>
Date:   Tue Jul 19 23:01:09 2011 -0400

    conf: support abstracted interface info in network XML

commit b48e81bf945314d491b0919144dee8565d3d446f
Author: Laine Stump <laine>
Date:   Thu Jun 30 17:05:07 2011 -0400

    network: separate Start/Shutdown functions for new network types
    

commit 03caa988a6a1497a012205796f78b2005edc09cf
Author: Laine Stump <laine>
Date:   Sun Jul 3 21:57:45 2011 -0400

    qemu: use virDomainNetGetActual*() functions where appropriate
    
commit e9949a586a9a2e6642d6394f85bd58955740b69d
Author: Laine Stump <laine>
Date:   Wed Jul 20 00:06:45 2011 -0400

    qemu: use virDomainNetGetActual*() in qemuDomainXMLToNative
    
commit 04711a0f32ac2e9c44081911295b436b2c0a11cf
Author: Laine Stump <laine>
Date:   Mon Jul 4 02:27:12 2011 -0400

    network: internal API functions to manage assignment of physdev to guest

This error sounds like you don't have a vepa-capable switch connected to the ethernet. If you don't, then this error is expected, and you can't test vepa mode. If that's the case, then you can mark this bug verified because you've tested everything you are able to test, and all of the tests passed.

If you *do* have a vepa-capable switch, first see if you can successfully start a domain using this <interface> definition instead:

    <interface type='direct'>
      <mac address='52:54:00:1b:6f:e5'/>
      <source dev='eth0' mode='vepa'/>
      <virtualport type='802.1Qbg'>
        <parameters managerid='13' typeid='3193047' typeidversion='4'
instanceid='70bf45f9-01a8-f5ee-3c0f-e25a0a2e44a6'/>
      </virtualport>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
    </interface>

If that fails, then either there's something wrong with your virtualport element, or there is a bug that's unrelated to the new code added for this feature.

If it succeeds, then there may be something wrong with the new logical switch code in libvirt (because it effectively creates the above interface definition out of the <interface> and <network> definitions you provided in the failing case above).

(In reply to comment #18)
> This error sounds like you don't have a vepa-capable switch connected to the
> ethernet. If you don't, then this error is expected, and you can't test vepa
> mode. If that's the case, then you can mark this bug verified because you've
> tested everything you are able to test, and all of the tests passed.
> 
> If you *do* have a vepa-capable switch, first see if you can successfully start
> a domain using this <interface> definition instead:
> 
>     <interface type='direct'>
>       <mac address='52:54:00:1b:6f:e5'/>
>       <source dev='eth0' mode='vepa'/>
>       <virtualport type='802.1Qbg'>
>         <parameters managerid='13' typeid='3193047' typeidversion='4'
> instanceid='70bf45f9-01a8-f5ee-3c0f-e25a0a2e44a6'/>
>       </virtualport>
>       <model type='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
> function='0x0'/>
>     </interface>
> 
> If that fails, then either there's something wrong with your virtualport
> element, or there is a bug that's unrelated to the new code added for this
> feature.
> 
> If it succeeds, then there may be something wrong with the new logical switch
> code in libvirt (because it effectively creates the above interface definition
> out of the <interface> and <network> definitions you provided in the failing
> case above).

for the switch is not vepa-capable, so I change the bug to verified status.

The documentation in upstream commit 073ef15c876a8257a077b8b3aa054da2d6ca2ef9
also  need to be pulled in for this bug,

Daniel

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When bridged and direct connections are used, the network interface definition of guests managed by libvirt can have host-specific information embedded in the guest config; for example in direct mode, the name of the physical device being used, or in bridge mode the name of the bridge device. In order to make migrations between non-identical hosts possible, this RFE provides a method of removing the host-specific items in the guest's network interface config, placing it in a libvirt virtual network definition instead. The guest can then simply reference the network to use by name, avoiding the necessity to put host-specific info in the guest config. At run-time libvirt will look up the guest definition for the current host, and use that information (which may be different for each host) to setup the guest's network connectivity.

Note that, in addition to making migration possible, this RFE allows setting up "pools" of physical interfaces for use in direct mode - rather than the config for each guest needing to specify a particular device (which must then be reserved for that guest even when it's not running), the guest just references a network - libvirt will then locate an unused (or the least used, depending on which is appropriate) interface, and use that interface instead.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1513.html