3 Commits

Author	SHA1	Message	Date
Laine Stump	07450cd429	conf: add trustGuestRxFilters attribute to network and domain interface ... This new attribute will control whether or not libvirt will pay attention to guest notifications about changes to network device mac addresses and receive filters. The default for this is 'no' (for security reasons). If it is set to 'yes' *and* the specified device model and connection support it (currently only macvtap+virtio) then libvirt will watch for NIC_RX_FILTER_CHANGED events, and when it receives one, it will issue a query-rx-filter command, retrieve the result, and modify the host-side macvtap interface's mac address and unicast/multicast filters accordingly. The functionality behind this attribute will be in a later patch. This patch merely adds the attribute to the top-level of a domain's <interface> as well as to <network> and <portgroup>, and adds documentation and schema/xml2xml tests. Rather than adding even more test files, I've just added the net attribute in various applicable places of existing test files.	2014-10-06 11:49:10 -04:00
Laine Stump	4af3cbafdd	conf: support partially-specified <virtualport> in parser and formatter ... Until now, all attributes in a <virtualport> parameter list that were acceptable for a particular type, were also required. There were no optional attributes. One of the aims of supporting <virtualport> in libvirt's virtual networks and portgroups is to allow specifying the group-wide parameters in the network's virtualport, and merge that with the interface's virtualport, which will have the instance-specific info (i.e. the interfaceid or instanceid). Additionally, the guest's interface XML shouldn't need to know what type of network connection will be used prior to runtime - it could be openvswitch, 802.1Qbh, 802.1Qbg, or none of the above - but should still be able to specify instance-specific info just in case it turns out to be applicable. Finally, up to now, the parser for virtualport has always generated a random instanceid/interfaceid when appropriate, making it impossible to leave it blank (which is what's required for virtualports within a network/portprofile definition). This patch modifies the parser and formatter of the <virtualport> element in the following ways: * because most of the attributes in a virNetDevVPortProfile are fixed size binary data with no reserved values, there is no way to embed a "this value wasn't specified" sentinel into the existing data. To solve this problem, the new *_specified fields in the virNetDevVPortProfile object that were added in a previous patch of this series are now set when the corresponding attribute is present during the parse. * allow parsing/formatting a <virtualport> that has no type set. In this case, all fields are settable, but all are also optional. * add a GENERATE_MISSING_DEFAULTS flag to the parser - if this flag is set and an instanceid/interfaceid is expected but not provided, a random one will be generated. This was previously the default behavior, but is now done only for virtualports inside an <interface> definition, not for those in <network> or <portgroup>. * add a REQUIRE_ALL_ATTRIBUTES flag to the parser - if this flag is set the parser will call the new virNetDevVPortProfileCheckComplete() functions at the end of the parser to check for any missing attributes (based on type), and return failure if anything is missing. This used to be default behavior. Now it is only used for the virtualport defined inside an interface's <actual> element (by the time you've figured out the contents of <actual>, you should have all the necessary data to fill in the entire virtualport) * add a REQUIRE_TYPE flag to the parser - if this flag is set, the parser will return an error if the virtualport has no type attribute. This also was previously the default behavior, but isn't needed in the case of the virtualport for a type='network' interface (i.e. the exact type isn't yet known), or the virtualport of a portgroup (i.e. the portgroup just has modifiers for the network's virtualport, which *does* require a type) - in those cases, the check will be done at domain startup, once the final virtualport is assembled (this is handled in the next patch).	2012-08-14 15:47:50 -04:00
Laine Stump	40fd7073be	conf: support abstracted interface info in network XML ... The network XML is updated in the following ways: 1) The <forward> element can now contain a list of forward interfaces: <forward .... > <interface dev='eth10'/> <interface dev='eth11'/> <interface dev='eth12'/> <interface dev='eth13'/> </forward> The first of these takes the place of the dev attribute that is normally in <forward> - when defining a network you can specify either one, and on output both will be present. If you specify both on input, they must match. 2) In addition to forward modes of 'nat' and 'route', these new modes are supported: private, passthrough, vepa - when this network is referenced by a domain's interface, it will have the same effect as if the interface had been defined as type='direct', e.g.: <interface type='direct'> <source mode='${mode}' dev='${dev}> ... </interface> where ${mode} is one of the three new modes, and ${dev} is an interface selected from the list given in <forward>. bridge - if a <forward> dev (or multiple devs) is defined, and forward mode is 'bridge' this is just like the modes 'private', 'passthrough', and 'vepa' above. If there is no forward dev specified but a bridge name is given (e.g. "<bridge name='br0'/>"), then guest interfaces using this network will use libvirt's "host bridge" mode, equivalent to this: <interface type='bridge'> <source bridge='${bridge-name}'/> ... </interface> 3) A network can have multiple <portgroup> elements, which may be selected by the guest interface definition (by adding "portgroup='${name}'" in the <source> element along with the network name). Currently a portgroup can only contain a virtportprofile, but the intent is that other configuration items may be put there int the future (e.g. bandwidth config). When building a guest's interface, if the <interface> XML itself has no virtportprofile, and if the requested network has a portgroup with a name matching the name given in the <interface> (or if one of the network's portgroups is marked with the "default='yes'" attribute), the virtportprofile from that portgroup will be used by the interface. 4) A network can have a virtportprofile defined at the top level, which will be used by a guest interface when connecting in one of the 'direct' modes if the guest interface XML itself hasn't specified any virtportprofile, and if there are also no matching portgroups on the network.	2011-07-21 14:46:53 -04:00