On Mon, Dec 05, 2011 at 02:00:52PM -0500, Laine Stump wrote: > On 12/05/2011 06:37 AM, Daniel P. Berrange wrote: > >On Tue, Nov 29, 2011 at 08:29:35PM -0500, Laine Stump wrote: > >>On 11/29/2011 02:53 PM, Daniel P. Berrange wrote: > >>>On Tue, Nov 29, 2011 at 03:46:13PM +0000, Shradha Shah wrote: > >>>>Interface Pools and Passthrough mode: > >>>> > >>>>Current Method: > >>>>The passthrough mode uses a macvtap a direct connection to connect each guest to the network. The physical interface to be used is picked from among those listed in<interface> sub elements of the<forward> element. > >>>> > >>>>The current specification for<forward> extends to allow 0 or more<interface> sub-elements: > >>>>Example: > >>>><forward mode='passthrough' dev='eth10'/> > >>>><interface dev='eth10'/> > >>>><interface dev='eth12'/> > >>>><interface dev='eth18'/> > >>>><interface dev='eth20'/> > >>>></forward> > >>>> > >>>>However with an ethernet card with 64 VF's or more, the above method gets tedious on the system. > >>>Ignoring the ABI issue, I'm concerned that as we get PFs with an increasingly > >>>large number of VFs, we may well *not* want to associate all VFs with a single > >>>virtual network definition. eg, we might wna to put 32 VFs in one network and > >>>32 VFs in another network. Or if we have 2 PFs, we might want to interleave > >>>VFs from several PFs across virtual networks. If all we can do is list the > >>>PF in the XML, we loose significant flexibility in how VFs are assigned. > >>My first concern too when I saw the patch was the semantic change > >>(but also the loss of flexibility), which is obviously a no-go. It's > >>a convenient capability to have though, so it would be nice to get > >>it in somehow. What if we allowed including all the VFs associated > >>with a PF by adding an extra attribute? e.g.: > >> > >><interface dev='eth10' type='sriov'/> > >This feels a little bit wrong to me. > > > >>(or whatever is more appropriate in place of "sriov"). Or possibly a > >>different element type could be used: > >> > >><pf dev='eth10'/> > >I like this idea, because it is providing additional useful info, > >rather than changing existing elements, so it is maximally > >compatible. > > > >>(didn't want to spend time thinking of a better name than "pf"...). > >> > >>At the time the network is created, this would cause libvirt to get > >>the list of all VFs for the given PF and put them into the pool. > >>This could be used instead of, or in combination with, the existing > >><interface dev='eth1'/> form. Thus the existing semantics would be > >>preserved, the flexibility of specifying individual devices would be > >>retained, and the desired convenience of adding all VFs of a PF with > >>a single line would be added. > >IIUC, what you're suggesting is the following behaviour: > > > > * Explicit interface list. App inputs: > > > > <forward mode='passthrough'> > > <interface dev='eth10'/> > > <interface dev='eth11'/> > > <interface dev='eth12'/> > > <interface dev='eth13'/> > > </forward> > > > > libvirt does not change XML > > > > * Automatically interface list from PF. App inputs: > > > > <forward mode='passthrough'> > > <pf dev='eth0'/> > > </forward> > > > > libvirt expands XML to be > > > > <forward mode='passthrough'> > > <pf dev='eth0'/> > > <interface dev='eth10'/> > > <interface dev='eth11'/> > > <interface dev='eth12'/> > > <interface dev='eth13'/> > > </forward> > > > >This is good because all previous info is still intact > > > I actually hadn't thought of modifying the XML and displaying it in > net-dumpxml or (netdumpxml --inactive), which is what I think you > may be implying here. This would have the advantage of making a > management application's job easier when displaying status > (available interfaces, etc), but could lead to confusion when a > host's hardware was changed (since there would be no detectable > difference between dev elements that were entered by hand, and those > that were automatically derived from a pf element). Also, it would > end up cluttering up the config file again, which is part of what > this is trying to avoid (although eliminating the need to type in > all N vf names is the primary concern). > > Unless we come up with a way of differentiating between > auto-generated <interface> elements (including keeping track of the > parent <pf>) and those entered by hand, I think the XML itself > shouldn't be changed, but only the contents of the interface pool in > memory. As with domains, every network has both an active and inactive XML config. When the network is not running, we should only be showing the user provided <interface> elements. Only once you start the network, do we automatically fill in <interface> elements based on <pf>. So if we add a flag for virNetworkGetXMLDesc() like VIR_NETWORK_XML_INACTIVE, then you can distinguish by comparing the live XML to the inactive XML. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list