RFC: Templates API changes for 'networks' attribute
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn. current implementation: 'networks' attribute expects list of virtual network names changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation) Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface> macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface> macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface> -- Regards, Suresh Babu Angadi
Hi Suresh, 1) I guess for virtual network do you mean type as "network" instead "direct"? virtual network(type=direct) 2) Just to be clear the network xml example given by you are not for libvirt network xml instead interface xml used in domain xml. 3) Just to addon example of interface xml for virtual network(type=network) (current implementation). <interface type='network' name='ethX'> <start mode='onboot'/> <source network='default'/> <model type='virtio'/> </interface> Thanks, Archana Singh On 08/09/2016 02:42 PM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direc mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
On 08/09/2016 03:55 PM, Archana Singh wrote:
Hi Suresh,
1) I guess for virtual network do you mean type as "network" instead "direct"?
virtual network(type=direct)
My bad,,yes its type="network" for virtual network
2) Just to be clear the network xml example given by you are not for libvirt network xml instead interface xml used in domain xml.
correct
3) Just to addon example of interface xml for virtual network(type=network) (current implementation).
<interface type='network' name='ethX'>
<start mode='onboot'/>
<source network='default'/>
<model type='virtio'/>
</interface>
thank you
Thanks,
Archana Singh
On 08/09/2016 02:42 PM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direc
correction - virtual network(type=network)
mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
-- Regards, Suresh Babu Angadi
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote:
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Regards, Suresh Babu Angadi
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote:
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template. May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
A lot of changes to be made. The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it. The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. Daniel On 08/10/2016 05:46 AM, Archana Singh wrote:
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote:
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template.
May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
A lot of changes to be made.
The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it.
The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Agree.
Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated.
Daniel
On 08/10/2016 05:46 AM, Archana Singh wrote:
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote:
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template.
May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network).
interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Regards, Suresh Babu Angadi
Hi All, Let me put the detailed summary !!! In case of platform s390x, any of the libvirt networks are not supported. The only way is attaching the physical interface macvtap or attaching ovs bridge directly to the guest at this point of time. *Expectation of the RFC is to attach macvtap and ovs directly to the guest with out libvirt API calls.* Example domain xml translations of macvtap and ovs (with out any libvirt calls): *OVS: * <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface> *Macvtap:* macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface> macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface> In order to achieve above functionality on s390x, recommend the following proposal to the templates and guest networking API’s (/templates and /vms/:name/ifaces): **Note : the same functionality can also exploited on other platforms too like on x86/ppc etc…* *1. Templates* A. Current : template.conf contains the following details for networks : [main] # List of networks separated by comma # Represents the virtual network interfaces to be assigned to guest #networks = default, Proposal : is to have dictionary based network details in the conf file similar to storage pools. [interfaces] # List of interfaces in the form of dictionary # Supports attaching virtual networks, macvtap and ovs bridge to the guest. # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ # source can be list network or interface or resource bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa [interfaces.0] #type=network #source=default #mode=NA For example to understand other possible types: [interfaces.1] #type=macvtap #source=eth0, eth1 #mode=bridge or vepa [interfaces.2] #type=ovs #source=ovsswitch1 #mode=NA B. API changes for the templates Current: network attributes for create/update of template networks (optional): list of networks will be assigned to the new VM. Proposal: networks (optional): list of dictionary of networks will be assigned to the new VM. type : ‘network’ | ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these interface will be attaching to guest directly. source : network or interface or resource bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’ *2. Virtual Machine Network Interfaces* *URI: */plugins/kimchi/vms/:name/ifaces Current: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network (optional): the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type. Proposal: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * source : the name of resource network or interface or resource bridge name * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’ *3. Virtual Machine Network Interface** **URI:* /plugins/kimchi/vms/:name/ifaces/:mac Current: GET: Retrieve the full description of the VM network interface * bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. Proposal: GET: Retrieve the full description of the VM network interface * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * source: the name of resource network or resource bridge or interface * type: It will be one of these types: 'network', ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’ Please feel free to suggest any other better ways of doing !!! Regards Chandra On 8/11/16 4:46 PM, Suresh Babu Angadi wrote:
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
A lot of changes to be made.
The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it.
The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Agree.
Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated.
Daniel
On 08/10/2016 05:46 AM, Archana Singh wrote:
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote: listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template.
May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network).
interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Chandra, Thanks for this detailed summary. I have a better idea of the problem and the proposal now. First a generic comment: Kimchi also supports a libvirt network called passthrough. Second, I think we may have a different approach here. I am seeing that the 'network' key isn't required in those APIs, they are optional. If we're going into the trouble of changing an existing API why not add a new optional parameter 'interface' to attach the interface into the VM without relying on libvirt networks? This way you have a clearer functionality difference in the API and it will be easier to code because you will not mess with existing code that relies on libvirt networks. And, in my opinion, it can be used not only by s390x but for everyone that, for any given reason, might want to attach directly an interface to the VM instead of relying in a libvirt network. Most of the work will be in adapting the existing UI to provide both options (with or without libvirt network) and show the user that they are mutually exclusive. Is the idea feasible? Making the 2 approaches coexist? Daniel On 08/12/2016 10:45 AM, Chandra Shekhar Reddy Potula wrote:
Hi All,
Let me put the detailed summary !!!
In case of platform s390x, any of the libvirt networks are not supported. The only way is attaching the physical interface macvtap or attaching ovs bridge directly to the guest at this point of time.
*Expectation of the RFC is to attach macvtap and ovs directly to the guest with out libvirt API calls.*
Example domain xml translations of macvtap and ovs (with out any libvirt calls):
*OVS: * <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
*Macvtap:* macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
In order to achieve above functionality on s390x, recommend the following proposal to the templates and guest networking API’s (/templates and /vms/:name/ifaces): **Note : the same functionality can also exploited on other platforms too like on x86/ppc etc…*
*1. Templates* A. Current : template.conf contains the following details for networks :
[main]
# List of networks separated by comma # Represents the virtual network interfaces to be assigned to guest #networks = default,
Proposal : is to have dictionary based network details in the conf file similar to storage pools.
[interfaces]
# List of interfaces in the form of dictionary # Supports attaching virtual networks, macvtap and ovs bridge to the guest. # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ # source can be list network or interface or resource bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
[interfaces.0] #type=network #source=default #mode=NA
For example to understand other possible types: [interfaces.1] #type=macvtap #source=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #source=ovsswitch1 #mode=NA
B. API changes for the templates
Current: network attributes for create/update of template networks (optional): list of networks will be assigned to the new VM.
Proposal: networks (optional): list of dictionary of networks will be assigned to the new VM. type : ‘network’ | ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these interface will be attaching to guest directly. source : network or interface or resource bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*2. Virtual Machine Network Interfaces* *URI: */plugins/kimchi/vms/:name/ifaces
Current: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network (optional): the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
Proposal: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * source : the name of resource network or interface or resource bridge name * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*3. Virtual Machine Network Interface** **URI:* /plugins/kimchi/vms/:name/ifaces/:mac
Current: GET: Retrieve the full description of the VM network interface * bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
Proposal: GET: Retrieve the full description of the VM network interface * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * source: the name of resource network or resource bridge or interface * type: It will be one of these types: 'network', ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please feel free to suggest any other better ways of doing !!!
Regards Chandra On 8/11/16 4:46 PM, Suresh Babu Angadi wrote:
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
A lot of changes to be made.
The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it.
The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Agree.
Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated.
Daniel
On 08/10/2016 05:46 AM, Archana Singh wrote:
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
I am worried not only by the API.json changes but also in the potential backend changes required. Do you have any prediction of how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote: listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template.
May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote: > Hi All, > To support, attaching a physical interface to guest as macvtap > or attaching ovs bridge to guest without creating libvirt > network, I propose following changes to 'networks' attribute of > templates josn. > > current implementation: > 'networks' attribute expects list of virtual network names > > changes: > 'networks': list of dictionary > type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network).
> interface: name of physical > interface(type=direct) or ovs (type=bridge) or virtual > network(type=direct) > mode(required if type=direct): bridge or vepa > > for macvtap: type is direct and mode can be bridge or vepa > for ovs: type is bridge and mode is not required > for virtual network: type=network(current implementation) > > Examples of network xml for attaching macvtap and ovs to guest > without libvirt: > OVS: > <interface type="bridge"> > <source bridge="vswitch0"/> > <virtualport type="openvswitch"/> > <model type="virtio"/> > </interface> > > macvtap with bridge mode: > <interface type="direct"> > <source dev="eth0" mode="bridge"/> > <model type="virtio"/> > </interface> > > macvtap with vepa mode: > <interface type="direct"> > <source dev="bond0" mode="vepa"/> > <model type="virtio"/> > </interface> >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Daniel, Thanks for prompt inputs !!! Please see my further inputs. Regards Chandra On 8/15/16 7:40 PM, Daniel Henrique Barboza wrote:
Hi Chandra,
Thanks for this detailed summary. I have a better idea of the problem and the proposal now.
First a generic comment: Kimchi also supports a libvirt network called passthrough.
Second, I think we may have a different approach here. I am seeing that the 'network' key isn't required in those APIs, they are optional. If we're going into the trouble of changing an existing API why not add a new optional parameter 'interface' to attach the interface into the VM without relying on libvirt networks?
We had thought about this option too but we were thinking in consolidating all the network attributes together. We were thinking too many attributes to deal with adding more of them. But I like your idea too.
This way you have a clearer functionality difference in the API and it will be easier to code because you will not mess with existing code that relies on libvirt networks. And, in my opinion, it can be used not only by s390x but for everyone that, for any given reason, might want to attach directly an interface to the VM instead of relying in a libvirt network.
Most of the work will be in adapting the existing UI to provide both options (with or without libvirt network) and show the user that they are mutually exclusive.
Is the idea feasible? Making the 2 approaches coexist?
See if Proposal 2 provided below looks good.
Daniel
On 08/12/2016 10:45 AM, Chandra Shekhar Reddy Potula wrote:
Hi All,
Let me put the detailed summary !!!
In case of platform s390x, any of the libvirt networks are not supported. The only way is attaching the physical interface macvtap or attaching ovs bridge directly to the guest at this point of time.
*Expectation of the RFC is to attach macvtap and ovs directly to the guest with out libvirt API calls.*
Example domain xml translations of macvtap and ovs (with out any libvirt calls):
*OVS: * <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
*Macvtap:* macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
In order to achieve above functionality on s390x, recommend the following proposal to the templates and guest networking API’s (/templates and /vms/:name/ifaces): **Note : the same functionality can also exploited on other platforms too like on x86/ppc etc…*
*1. Templates* A. Current : template.conf contains the following details for networks :
[main]
# List of networks separated by comma # Represents the virtual network interfaces to be assigned to guest #networks = default,
Proposal : is to have dictionary based network details in the conf file similar to storage pools.
[interfaces]
# List of interfaces in the form of dictionary # Supports attaching virtual networks, macvtap and ovs bridge to the guest. # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ # source can be list network or interface or resource bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
[interfaces.0] #type=network #source=default #mode=NA
For example to understand other possible types: [interfaces.1] #type=macvtap #source=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #source=ovsswitch1 #mode=NA
Proposal 2: to have existing attribute /networks/ as list of virtual network as it is, and have additional attribute /interfaces/ for direct network connections (no libvirt calls).
[main] # List of virtual/libvirt networks separated by comma # Represents the virtual/libvirt network interfaces to be assigned to guest , by default default virtual network attached. # On s390x if attribute /networks/ commented out then no virtual network will be attached by default. #networks = default Along with existing configuration additional attribute /interfaces/ for direct network interfaces [interfaces] # List of network interfaces in the form of dictionary # Supports attaching macvtap and ovs bridge to the guest. # type can be of ‘macvtap’ | ‘ovs’ # name can be of list network interface or ovs bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa Please note by default no network interface will be attached to guest/template. For example to understand other possible types: [interfaces.1] #type=macvtap #name=eth0, eth1 #mode=bridge or vepa [interfaces.2] #type=ovs #name=ovsswitch1 #mode=NA
B. API changes for the templates
Current: network attributes for create/update of template networks (optional): list of networks will be assigned to the new VM.
Proposal: networks (optional): list of dictionary of networks will be assigned to the new VM. type : ‘network’ | ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these interface will be attaching to guest directly. source : network or interface or resource bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: attribute /networks/ for get/create/update of template
* networks (optional): list of virtual/libvirt networks will be assigned to the new VM. By default, /default virtual network/ will not be attached in case of s390x. ** In addition to the attribute /networks/, template API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls) * interfaces (optional) : list of dictionary of network interfaces to be assigned to the guest. By specifying macvtap or ovs these interface will be attaching to guest directly. type : ‘macvtap’ | ‘ovs’ name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’ Please note by default no network interface will be attached to guest/template.
*2. Virtual Machine Network Interfaces* *URI: */plugins/kimchi/vms/:name/ifaces
Current: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network (optional): the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
Proposal: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * source : the name of resource network or interface or resource bridge name * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: *GET*:
* networks (optional): Retrieve a summarized list of all virtual network interfaces attached to a Virtual Machine. ** In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls) * interfaces (optional): list of dictionary of network interfaces to be assigned to the Virtual Machine. By specifying macvtap or ovs, these interfaces will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’ *POST*: attach a virtual network or direct interface to VM * model /(optional)/: model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network /(optional)/: the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type. In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls) * interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*3. Virtual Machine Network Interface** **URI:* /plugins/kimchi/vms/:name/ifaces/:mac
Current: GET: Retrieve the full description of the VM network interface * bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
Proposal: GET: Retrieve the full description of the VM network interface * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * source: the name of resource network or resource bridge or interface * type: It will be one of these types: 'network', ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: GET: Retrieve the full description of the VM network interface
* bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls) * interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’ *DELETE*: * * Deletion of network interfaces has to be supported along with virtual network deletions. *PUT*: * model /(optional)/: model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. This change is only on the persisted VM configuration. * network /(optional)/: the name of resource network, only be available when the interface type is network. This change is on the active VM instance and persisted VM configuration. In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls) * interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please feel free to suggest any other better ways of doing !!!
Regards Chandra On 8/11/16 4:46 PM, Suresh Babu Angadi wrote:
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
A lot of changes to be made.
The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it.
The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Agree.
Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated.
Daniel
On 08/10/2016 05:46 AM, Archana Singh wrote:
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote: > I am worried not only by the API.json changes but also in the > potential backend changes required. Do you have any prediction of > how far these changes might go? from backend, it would remain same for virtual network. For macvtap, validation of interface would be okay since interfaces listing is moved to gingerbase and kimchi is using it for networks hence same code can be utilized. For openvswitch, ginger code will have to be moved to gingerbase to enable kimchi to list host ovs interfaces.
On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template.
May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
> > On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote: >> Hi All, >> To support, attaching a physical interface to guest as macvtap >> or attaching ovs bridge to guest without creating libvirt >> network, I propose following changes to 'networks' attribute of >> templates josn. >> >> current implementation: >> 'networks' attribute expects list of virtual network names >> >> changes: >> 'networks': list of dictionary >> type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network).
>> interface: name of physical >> interface(type=direct) or ovs (type=bridge) or virtual >> network(type=direct) >> mode(required if type=direct): bridge or vepa >> >> for macvtap: type is direct and mode can be bridge or vepa >> for ovs: type is bridge and mode is not required >> for virtual network: type=network(current implementation) >> >> Examples of network xml for attaching macvtap and ovs to guest >> without libvirt: >> OVS: >> <interface type="bridge"> >> <source bridge="vswitch0"/> >> <virtualport type="openvswitch"/> >> <model type="virtio"/> >> </interface> >> >> macvtap with bridge mode: >> <interface type="direct"> >> <source dev="eth0" mode="bridge"/> >> <model type="virtio"/> >> </interface> >> >> macvtap with vepa mode: >> <interface type="direct"> >> <source dev="bond0" mode="vepa"/> >> <model type="virtio"/> >> </interface> >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Chandra, I like the option (2) you provided in all cases, because, as I've said, it's a way to add the new functionality without changing the existing API/code. If libvirt for s390x covers the gap and we decide that this new feature is now obsolete, it is easier to remove it too. Let's wait for Aline's feedback before deciding which API strategy we're going to use. Meanwhile I think you can start working in the backend modules that will add the interface XML to the VM XML (I consider this work to be independent of how the API will change). Daniel On 08/16/2016 10:33 AM, Chandra Shekhar Reddy Potula wrote:
Hi Daniel,
Thanks for prompt inputs !!!
Please see my further inputs.
Regards Chandra On 8/15/16 7:40 PM, Daniel Henrique Barboza wrote:
Hi Chandra,
Thanks for this detailed summary. I have a better idea of the problem and the proposal now.
First a generic comment: Kimchi also supports a libvirt network called passthrough.
Second, I think we may have a different approach here. I am seeing that the 'network' key isn't required in those APIs, they are optional. If we're going into the trouble of changing an existing API why not add a new optional parameter 'interface' to attach the interface into the VM without relying on libvirt networks?
We had thought about this option too but we were thinking in consolidating all the network attributes together. We were thinking too many attributes to deal with adding more of them. But I like your idea too.
This way you have a clearer functionality difference in the API and it will be easier to code because you will not mess with existing code that relies on libvirt networks. And, in my opinion, it can be used not only by s390x but for everyone that, for any given reason, might want to attach directly an interface to the VM instead of relying in a libvirt network.
Most of the work will be in adapting the existing UI to provide both options (with or without libvirt network) and show the user that they are mutually exclusive.
Is the idea feasible? Making the 2 approaches coexist?
See if Proposal 2 provided below looks good.
Daniel
On 08/12/2016 10:45 AM, Chandra Shekhar Reddy Potula wrote:
Hi All,
Let me put the detailed summary !!!
In case of platform s390x, any of the libvirt networks are not supported. The only way is attaching the physical interface macvtap or attaching ovs bridge directly to the guest at this point of time.
*Expectation of the RFC is to attach macvtap and ovs directly to the guest with out libvirt API calls.*
Example domain xml translations of macvtap and ovs (with out any libvirt calls):
*OVS: * <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
*Macvtap:* macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
In order to achieve above functionality on s390x, recommend the following proposal to the templates and guest networking API’s (/templates and /vms/:name/ifaces): **Note : the same functionality can also exploited on other platforms too like on x86/ppc etc…*
*1. Templates* A. Current : template.conf contains the following details for networks :
[main]
# List of networks separated by comma # Represents the virtual network interfaces to be assigned to guest #networks = default,
Proposal : is to have dictionary based network details in the conf file similar to storage pools.
[interfaces]
# List of interfaces in the form of dictionary # Supports attaching virtual networks, macvtap and ovs bridge to the guest. # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ # source can be list network or interface or resource bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
[interfaces.0] #type=network #source=default #mode=NA
For example to understand other possible types: [interfaces.1] #type=macvtap #source=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #source=ovsswitch1 #mode=NA
Proposal 2: to have existing attribute /networks/ as list of virtual network as it is, and have additional attribute /interfaces/ for direct network connections (no libvirt calls).
[main] # List of virtual/libvirt networks separated by comma # Represents the virtual/libvirt network interfaces to be assigned to guest , by default default virtual network attached. # On s390x if attribute /networks/ commented out then no virtual network will be attached by default. #networks = default
Along with existing configuration additional attribute /interfaces/ for direct network interfaces
[interfaces] # List of network interfaces in the form of dictionary # Supports attaching macvtap and ovs bridge to the guest. # type can be of ‘macvtap’ | ‘ovs’ # name can be of list network interface or ovs bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
Please note by default no network interface will be attached to guest/template.
For example to understand other possible types: [interfaces.1] #type=macvtap #name=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #name=ovsswitch1 #mode=NA
B. API changes for the templates
Current: network attributes for create/update of template networks (optional): list of networks will be assigned to the new VM.
Proposal: networks (optional): list of dictionary of networks will be assigned to the new VM. type : ‘network’ | ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these interface will be attaching to guest directly. source : network or interface or resource bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: attribute /networks/ for get/create/update of template
* networks (optional): list of virtual/libvirt networks will be assigned to the new VM. By default, /default virtual network/ will not be attached in case of s390x.
** In addition to the attribute /networks/, template API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interfaces (optional) : list of dictionary of network interfaces to be assigned to the guest. By specifying macvtap or ovs these interface will be attaching to guest directly.
type : ‘macvtap’ | ‘ovs’ name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please note by default no network interface will be attached to guest/template.
*2. Virtual Machine Network Interfaces* *URI: */plugins/kimchi/vms/:name/ifaces
Current: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network (optional): the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
Proposal: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * source : the name of resource network or interface or resource bridge name * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: *GET*:
* networks (optional): Retrieve a summarized list of all virtual network interfaces attached to a Virtual Machine.
** In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interfaces (optional): list of dictionary of network interfaces to be assigned to the Virtual Machine. By specifying macvtap or ovs, these interfaces will be attached to guest directly.
type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*POST*: attach a virtual network or direct interface to VM
* model /(optional)/: model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network /(optional)/: the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*3. Virtual Machine Network Interface** **URI:* /plugins/kimchi/vms/:name/ifaces/:mac
Current: GET: Retrieve the full description of the VM network interface * bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
Proposal: GET: Retrieve the full description of the VM network interface * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * source: the name of resource network or resource bridge or interface * type: It will be one of these types: 'network', ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: GET: Retrieve the full description of the VM network interface
* bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*DELETE*: * *
Deletion of network interfaces has to be supported along with virtual network deletions.
*PUT*:
* model /(optional)/: model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. This change is only on the persisted VM configuration. * network /(optional)/: the name of resource network, only be available when the interface type is network. This change is on the active VM instance and persisted VM configuration.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please feel free to suggest any other better ways of doing !!!
Regards Chandra On 8/11/16 4:46 PM, Suresh Babu Angadi wrote:
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
A lot of changes to be made.
The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it.
The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Agree.
Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated.
Daniel
On 08/10/2016 05:46 AM, Archana Singh wrote:
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote: > > > On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote: >> I am worried not only by the API.json changes but also in the >> potential backend changes required. Do you have any prediction of >> how far these changes might go? > from backend, it would remain same for virtual network. For > macvtap, validation of interface would be okay since interfaces > listing is moved to gingerbase and kimchi is using it for > networks hence same code can be utilized. For openvswitch, > ginger code will have to be moved to gingerbase to enable kimchi > to list host ovs interfaces. On high level I guess below needs to be done, and both point below are independent of each-other. 1) Listing of networks based on selected type. (This will mostly use to show list in UI, based on type). 2) Once network is selected/provided, an REST API call which will land to control and model. From control point of view it will be addition of parameters. And from model point of view, we need to add if and else to check type. And for virtual type, existing code implementation should work. And for other two type, we need add code for addition of these options in template params. And also code to generate corresponding xml based on type. It will be mostly on template/guest edit/create code and network add/remove from guest/template.
May be validation of network(s) to check if network(s) exist( for type macvtap and ovs) or not can be done as improvement to feature.
>> >> On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote: >>> Hi All, >>> To support, attaching a physical interface to guest as macvtap >>> or attaching ovs bridge to guest without creating libvirt >>> network, I propose following changes to 'networks' attribute >>> of templates josn. >>> >>> current implementation: >>> 'networks' attribute expects list of virtual network names >>> >>> changes: >>> 'networks': list of dictionary >>> type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network).
>>> interface: name of physical >>> interface(type=direct) or ovs (type=bridge) or virtual >>> network(type=direct) >>> mode(required if type=direct): bridge or vepa >>> >>> for macvtap: type is direct and mode can be bridge or vepa >>> for ovs: type is bridge and mode is not required >>> for virtual network: type=network(current implementation) >>> >>> Examples of network xml for attaching macvtap and ovs to guest >>> without libvirt: >>> OVS: >>> <interface type="bridge"> >>> <source bridge="vswitch0"/> >>> <virtualport type="openvswitch"/> >>> <model type="virtio"/> >>> </interface> >>> >>> macvtap with bridge mode: >>> <interface type="direct"> >>> <source dev="eth0" mode="bridge"/> >>> <model type="virtio"/> >>> </interface> >>> >>> macvtap with vepa mode: >>> <interface type="direct"> >>> <source dev="bond0" mode="vepa"/> >>> <model type="virtio"/> >>> </interface> >>> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi All, I am here with attaching the mockup screens for the proposed changes for s390x platform. Regards Chandra On 8/16/16 10:05 PM, Daniel Henrique Barboza wrote:
Hi Chandra,
I like the option (2) you provided in all cases, because, as I've said, it's a way to add the new functionality without changing the existing API/code. If libvirt for s390x covers the gap and we decide that this new feature is now obsolete, it is easier to remove it too.
Let's wait for Aline's feedback before deciding which API strategy we're going to use. Meanwhile I think you can start working in the backend modules that will add the interface XML to the VM XML (I consider this work to be independent of how the API will change).
Daniel
On 08/16/2016 10:33 AM, Chandra Shekhar Reddy Potula wrote:
Hi Daniel,
Thanks for prompt inputs !!!
Please see my further inputs.
Regards Chandra On 8/15/16 7:40 PM, Daniel Henrique Barboza wrote:
Hi Chandra,
Thanks for this detailed summary. I have a better idea of the problem and the proposal now.
First a generic comment: Kimchi also supports a libvirt network called passthrough.
Second, I think we may have a different approach here. I am seeing that the 'network' key isn't required in those APIs, they are optional. If we're going into the trouble of changing an existing API why not add a new optional parameter 'interface' to attach the interface into the VM without relying on libvirt networks?
We had thought about this option too but we were thinking in consolidating all the network attributes together. We were thinking too many attributes to deal with adding more of them. But I like your idea too.
This way you have a clearer functionality difference in the API and it will be easier to code because you will not mess with existing code that relies on libvirt networks. And, in my opinion, it can be used not only by s390x but for everyone that, for any given reason, might want to attach directly an interface to the VM instead of relying in a libvirt network.
Most of the work will be in adapting the existing UI to provide both options (with or without libvirt network) and show the user that they are mutually exclusive.
Is the idea feasible? Making the 2 approaches coexist?
See if Proposal 2 provided below looks good.
Daniel
On 08/12/2016 10:45 AM, Chandra Shekhar Reddy Potula wrote:
Hi All,
Let me put the detailed summary !!!
In case of platform s390x, any of the libvirt networks are not supported. The only way is attaching the physical interface macvtap or attaching ovs bridge directly to the guest at this point of time.
*Expectation of the RFC is to attach macvtap and ovs directly to the guest with out libvirt API calls.*
Example domain xml translations of macvtap and ovs (with out any libvirt calls):
*OVS: * <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
*Macvtap:* macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
In order to achieve above functionality on s390x, recommend the following proposal to the templates and guest networking API’s (/templates and /vms/:name/ifaces): **Note : the same functionality can also exploited on other platforms too like on x86/ppc etc…*
*1. Templates* A. Current : template.conf contains the following details for networks :
[main]
# List of networks separated by comma # Represents the virtual network interfaces to be assigned to guest #networks = default,
Proposal : is to have dictionary based network details in the conf file similar to storage pools.
[interfaces]
# List of interfaces in the form of dictionary # Supports attaching virtual networks, macvtap and ovs bridge to the guest. # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ # source can be list network or interface or resource bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
[interfaces.0] #type=network #source=default #mode=NA
For example to understand other possible types: [interfaces.1] #type=macvtap #source=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #source=ovsswitch1 #mode=NA
Proposal 2: to have existing attribute /networks/ as list of virtual network as it is, and have additional attribute /interfaces/ for direct network connections (no libvirt calls).
[main] # List of virtual/libvirt networks separated by comma # Represents the virtual/libvirt network interfaces to be assigned to guest , by default default virtual network attached. # On s390x if attribute /networks/ commented out then no virtual network will be attached by default. #networks = default
Along with existing configuration additional attribute /interfaces/ for direct network interfaces
[interfaces] # List of network interfaces in the form of dictionary # Supports attaching macvtap and ovs bridge to the guest. # type can be of ‘macvtap’ | ‘ovs’ # name can be of list network interface or ovs bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
Please note by default no network interface will be attached to guest/template.
For example to understand other possible types: [interfaces.1] #type=macvtap #name=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #name=ovsswitch1 #mode=NA
B. API changes for the templates
Current: network attributes for create/update of template networks (optional): list of networks will be assigned to the new VM.
Proposal: networks (optional): list of dictionary of networks will be assigned to the new VM. type : ‘network’ | ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these interface will be attaching to guest directly. source : network or interface or resource bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: attribute /networks/ for get/create/update of template
* networks (optional): list of virtual/libvirt networks will be assigned to the new VM. By default, /default virtual network/ will not be attached in case of s390x.
** In addition to the attribute /networks/, template API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interfaces (optional) : list of dictionary of network interfaces to be assigned to the guest. By specifying macvtap or ovs these interface will be attaching to guest directly.
type : ‘macvtap’ | ‘ovs’ name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please note by default no network interface will be attached to guest/template.
*2. Virtual Machine Network Interfaces* *URI: */plugins/kimchi/vms/:name/ifaces
Current: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network (optional): the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
Proposal: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * source : the name of resource network or interface or resource bridge name * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: *GET*:
* networks (optional): Retrieve a summarized list of all virtual network interfaces attached to a Virtual Machine.
** In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interfaces (optional): list of dictionary of network interfaces to be assigned to the Virtual Machine. By specifying macvtap or ovs, these interfaces will be attached to guest directly.
type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*POST*: attach a virtual network or direct interface to VM
* model /(optional)/: model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network /(optional)/: the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*3. Virtual Machine Network Interface** **URI:* /plugins/kimchi/vms/:name/ifaces/:mac
Current: GET: Retrieve the full description of the VM network interface * bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
Proposal: GET: Retrieve the full description of the VM network interface * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * source: the name of resource network or resource bridge or interface * type: It will be one of these types: 'network', ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: GET: Retrieve the full description of the VM network interface
* bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*DELETE*: * *
Deletion of network interfaces has to be supported along with virtual network deletions.
*PUT*:
* model /(optional)/: model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. This change is only on the persisted VM configuration. * network /(optional)/: the name of resource network, only be available when the interface type is network. This change is on the active VM instance and persisted VM configuration.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please feel free to suggest any other better ways of doing !!!
Regards Chandra On 8/11/16 4:46 PM, Suresh Babu Angadi wrote:
A lot of changes to be made.
The changes in Ginger -> Gingerbase regarding OVS bridges is the simplest to do. Gingerbase already has some OVS legacy functions from before Ginger developed the OVS bridges backend in the module netinfo.py. We can see if there's something there to list OVS interfaces (can't recall now) and, if not, we can add it.
The remaining Kimchi changes will need to either do in small chunks, avoiding changing the working code we have today, or all at once with UI changes included to avoid breaking the existing UI with the API change. I'll leave it up to you which approach to go, as long as we don't break the existing network support in Kimchi in the process. Agree.
Assuming that all this precautions are made, I approve this RFC. However, note that this is *my* opinion. I am not the official maintainer of this plug-in and it would be unwise to rely solely on it. It is safer to wait for Aline's opinion in this RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote: physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated.
Daniel
On 08/10/2016 05:46 AM, Archana Singh wrote: > > On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote: >> >> >> On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote: >>> I am worried not only by the API.json changes but also in the >>> potential backend changes required. Do you have any prediction of >>> how far these changes might go? >> from backend, it would remain same for virtual network. For >> macvtap, validation of interface would be okay since interfaces >> listing is moved to gingerbase and kimchi is using it for >> networks hence same code can be utilized. For openvswitch, >> ginger code will have to be moved to gingerbase to enable >> kimchi to list host ovs interfaces. > On high level I guess below needs to be done, and both point > below are independent of each-other. > 1) Listing of networks based on selected type. (This will mostly > use to show list in UI, based on type). > 2) Once network is selected/provided, an REST API call which > will land to control and model. From control point of view it > will be addition of parameters. And from model point of view, we > need to add if and else to check type. > And for virtual type, existing code implementation should work. > And for other two type, we need add code for addition of these > options in template params. And also code to generate > corresponding xml based on type. > It will be mostly on template/guest edit/create code and network > add/remove from guest/template. > > May be validation of network(s) to check if network(s) exist( > for type macvtap and ovs) or not can be done as improvement to > feature. > >>> >>> On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote: >>>> Hi All, >>>> To support, attaching a physical interface to guest as >>>> macvtap or attaching ovs bridge to guest without creating >>>> libvirt network, I propose following changes to 'networks' >>>> attribute of templates josn. >>>> >>>> current implementation: >>>> 'networks' attribute expects list of virtual network names >>>> >>>> changes: >>>> 'networks': list of dictionary >>>> type: can be direct, network or bridge
Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network).
>>>> interface: name of physical >>>> interface(type=direct) or ovs (type=bridge) or virtual >>>> network(type=direct) >>>> mode(required if type=direct): bridge or vepa >>>> >>>> for macvtap: type is direct and mode can be bridge or vepa >>>> for ovs: type is bridge and mode is not required >>>> for virtual network: type=network(current implementation) >>>> >>>> Examples of network xml for attaching macvtap and ovs to >>>> guest without libvirt: >>>> OVS: >>>> <interface type="bridge"> >>>> <source bridge="vswitch0"/> >>>> <virtualport type="openvswitch"/> >>>> <model type="virtio"/> >>>> </interface> >>>> >>>> macvtap with bridge mode: >>>> <interface type="direct"> >>>> <source dev="eth0" mode="bridge"/> >>>> <model type="virtio"/> >>>> </interface> >>>> >>>> macvtap with vepa mode: >>>> <interface type="direct"> >>>> <source dev="bond0" mode="vepa"/> >>>> <model type="virtio"/> >>>> </interface> >>>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Slightly modified version of the mockup screens for the proposed changes for s390x platform. Regards Chandra On 8/19/16 4:21 PM, Chandra Shekhar Reddy Potula wrote:
Hi All,
I am here with attaching the mockup screens for the proposed changes for s390x platform.
Regards
Chandra
On 8/16/16 10:05 PM, Daniel Henrique Barboza wrote:
Hi Chandra,
I like the option (2) you provided in all cases, because, as I've said, it's a way to add the new functionality without changing the existing API/code. If libvirt for s390x covers the gap and we decide that this new feature is now obsolete, it is easier to remove it too.
Let's wait for Aline's feedback before deciding which API strategy we're going to use. Meanwhile I think you can start working in the backend modules that will add the interface XML to the VM XML (I consider this work to be independent of how the API will change).
Daniel
On 08/16/2016 10:33 AM, Chandra Shekhar Reddy Potula wrote:
Hi Daniel,
Thanks for prompt inputs !!!
Please see my further inputs.
Regards Chandra On 8/15/16 7:40 PM, Daniel Henrique Barboza wrote:
Hi Chandra,
Thanks for this detailed summary. I have a better idea of the problem and the proposal now.
First a generic comment: Kimchi also supports a libvirt network called passthrough.
Second, I think we may have a different approach here. I am seeing that the 'network' key isn't required in those APIs, they are optional. If we're going into the trouble of changing an existing API why not add a new optional parameter 'interface' to attach the interface into the VM without relying on libvirt networks?
We had thought about this option too but we were thinking in consolidating all the network attributes together. We were thinking too many attributes to deal with adding more of them. But I like your idea too.
This way you have a clearer functionality difference in the API and it will be easier to code because you will not mess with existing code that relies on libvirt networks. And, in my opinion, it can be used not only by s390x but for everyone that, for any given reason, might want to attach directly an interface to the VM instead of relying in a libvirt network.
Most of the work will be in adapting the existing UI to provide both options (with or without libvirt network) and show the user that they are mutually exclusive.
Is the idea feasible? Making the 2 approaches coexist?
See if Proposal 2 provided below looks good.
Daniel
On 08/12/2016 10:45 AM, Chandra Shekhar Reddy Potula wrote:
Hi All,
Let me put the detailed summary !!!
In case of platform s390x, any of the libvirt networks are not supported. The only way is attaching the physical interface macvtap or attaching ovs bridge directly to the guest at this point of time.
*Expectation of the RFC is to attach macvtap and ovs directly to the guest with out libvirt API calls.*
Example domain xml translations of macvtap and ovs (with out any libvirt calls):
*OVS: * <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
*Macvtap:* macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
In order to achieve above functionality on s390x, recommend the following proposal to the templates and guest networking API’s (/templates and /vms/:name/ifaces): **Note : the same functionality can also exploited on other platforms too like on x86/ppc etc…*
*1. Templates* A. Current : template.conf contains the following details for networks :
[main]
# List of networks separated by comma # Represents the virtual network interfaces to be assigned to guest #networks = default,
Proposal : is to have dictionary based network details in the conf file similar to storage pools.
[interfaces]
# List of interfaces in the form of dictionary # Supports attaching virtual networks, macvtap and ovs bridge to the guest. # type can be of ‘network’ | ‘macvtap’ | ‘ovs’ # source can be list network or interface or resource bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
[interfaces.0] #type=network #source=default #mode=NA
For example to understand other possible types: [interfaces.1] #type=macvtap #source=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #source=ovsswitch1 #mode=NA
Proposal 2: to have existing attribute /networks/ as list of virtual network as it is, and have additional attribute /interfaces/ for direct network connections (no libvirt calls).
[main] # List of virtual/libvirt networks separated by comma # Represents the virtual/libvirt network interfaces to be assigned to guest , by default default virtual network attached. # On s390x if attribute /networks/ commented out then no virtual network will be attached by default. #networks = default
Along with existing configuration additional attribute /interfaces/ for direct network interfaces
[interfaces] # List of network interfaces in the form of dictionary # Supports attaching macvtap and ovs bridge to the guest. # type can be of ‘macvtap’ | ‘ovs’ # name can be of list network interface or ovs bridge name. Comma separated values allowed if they are of same type. # mode required only for macvtap. mode can be either bridge or vepa
Please note by default no network interface will be attached to guest/template.
For example to understand other possible types: [interfaces.1] #type=macvtap #name=eth0, eth1 #mode=bridge or vepa
[interfaces.2] #type=ovs #name=ovsswitch1 #mode=NA
B. API changes for the templates
Current: network attributes for create/update of template networks (optional): list of networks will be assigned to the new VM.
Proposal: networks (optional): list of dictionary of networks will be assigned to the new VM. type : ‘network’ | ‘macvtap’ | ‘ovs’. By specifying macvtap or ovs these interface will be attaching to guest directly. source : network or interface or resource bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: attribute /networks/ for get/create/update of template
* networks (optional): list of virtual/libvirt networks will be assigned to the new VM. By default, /default virtual network/ will not be attached in case of s390x.
** In addition to the attribute /networks/, template API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interfaces (optional) : list of dictionary of network interfaces to be assigned to the guest. By specifying macvtap or ovs these interface will be attaching to guest directly.
type : ‘macvtap’ | ‘ovs’ name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please note by default no network interface will be attached to guest/template.
*2. Virtual Machine Network Interfaces* *URI: */plugins/kimchi/vms/:name/ifaces
Current: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network (optional): the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
Proposal: POST: attach a network interface to VM * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * source : the name of resource network or interface or resource bridge name * type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: *GET*:
* networks (optional): Retrieve a summarized list of all virtual network interfaces attached to a Virtual Machine.
** In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interfaces (optional): list of dictionary of network interfaces to be assigned to the Virtual Machine. By specifying macvtap or ovs, these interfaces will be attached to guest directly.
type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*POST*: attach a virtual network or direct interface to VM
* model /(optional)/: model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network /(optional)/: the name of resource network, it is required when the interface type is network. * type: The type of VM network interface that libvirt supports. Now kimchi just supports 'network' type.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*3. Virtual Machine Network Interface** **URI:* /plugins/kimchi/vms/:name/ifaces/:mac
Current: GET: Retrieve the full description of the VM network interface * bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
Proposal: GET: Retrieve the full description of the VM network interface * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * source: the name of resource network or resource bridge or interface * type: It will be one of these types: 'network', ‘macvtap’, ‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'. * mode : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Proposal 2: GET: Retrieve the full description of the VM network interface
* bridge (optional): the name of resource bridge, only be available when the interface type is bridge. * mac: Media Access Control Address of the VM interface. * ips: A list of IP addresses associated with this MAC. * model (optional): model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. * network (optional): the name of resource network, only be available when the interface type is network. * type: The type of VM network interface that libvirt supports. It will be one of these types: 'network', 'bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast', 'server' and 'client'.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
*DELETE*: * *
Deletion of network interfaces has to be supported along with virtual network deletions.
*PUT*:
* model /(optional)/: model of emulated network interface card. It will be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. This change is only on the persisted VM configuration. * network /(optional)/: the name of resource network, only be available when the interface type is network. This change is on the active VM instance and persisted VM configuration.
In addition to the attribute /networks/, API can have attribute /interfaces /to deal with direct network interfaces (no libvirt calls)
* interface (optional): network interface to be assigned to the Virtual Machine. By specifying macvtap or ovs, this interface will be attached to guest directly. type : ‘macvtap’ | ‘ovs’. name : network interface or ovs bridge name mode(optional) : kimchi supports ’bridge’ or ‘vepa’. required only if type=‘macvtap’
Please feel free to suggest any other better ways of doing !!!
Regards Chandra On 8/11/16 4:46 PM, Suresh Babu Angadi wrote:
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote: > A lot of changes to be made. > > The changes in Ginger -> Gingerbase regarding OVS bridges is the > simplest > to do. Gingerbase already has some OVS legacy functions from > before Ginger > developed the OVS bridges backend in the module netinfo.py. We > can see if > there's something there to list OVS interfaces (can't recall > now) and, if not, we > can add it. > > The remaining Kimchi changes will need to either do in small > chunks, avoiding > changing the working code we have today, or all at once with UI > changes included > to avoid breaking the existing UI with the API change. I'll > leave it up to you which > approach to go, as long as we don't break the existing network > support in Kimchi > in the process. Agree. > > Assuming that all this precautions are made, I approve this RFC. > However, note that > this is *my* opinion. I am not the official maintainer of this > plug-in and it would > be unwise to rely solely on it. It is safer to wait for Aline's > opinion in this > RFC before taking any step toward the implementation. To support s390x architecture which doesn't support libvirt virtual networks as of today,, its necessary to allow attaching physical interface to guest. Hence would start implementing, however any changes/suggestions can be accommodated. > > > Daniel > > On 08/10/2016 05:46 AM, Archana Singh wrote: >> >> On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote: >>> >>> >>> On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote: >>>> I am worried not only by the API.json changes but also in the >>>> potential backend changes required. Do you have any >>>> prediction of >>>> how far these changes might go? >>> from backend, it would remain same for virtual network. For >>> macvtap, validation of interface would be okay since >>> interfaces listing is moved to gingerbase and kimchi is using >>> it for networks hence same code can be utilized. For >>> openvswitch, ginger code will have to be moved to gingerbase >>> to enable kimchi to list host ovs interfaces. >> On high level I guess below needs to be done, and both point >> below are independent of each-other. >> 1) Listing of networks based on selected type. (This will >> mostly use to show list in UI, based on type). >> 2) Once network is selected/provided, an REST API call which >> will land to control and model. From control point of view it >> will be addition of parameters. And from model point of view, >> we need to add if and else to check type. >> And for virtual type, existing code implementation should work. >> And for other two type, we need add code for addition of these >> options in template params. And also code to generate >> corresponding xml based on type. >> It will be mostly on template/guest edit/create code and >> network add/remove from guest/template. >> >> May be validation of network(s) to check if network(s) exist( >> for type macvtap and ovs) or not can be done as improvement to >> feature. >> >>>> >>>> On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote: >>>>> Hi All, >>>>> To support, attaching a physical interface to guest as >>>>> macvtap or attaching ovs bridge to guest without creating >>>>> libvirt network, I propose following changes to 'networks' >>>>> attribute of templates josn. >>>>> >>>>> current implementation: >>>>> 'networks' attribute expects list of virtual network names >>>>> >>>>> changes: >>>>> 'networks': list of dictionary >>>>> type: can be direct, network or bridge Small change in type, to be explicit, its good to have type as macvtap(instead of direct), ovs(instead of bridge) and virtualnetwork(instead of network). >>>>> interface: name of physical interface(type=direct) or ovs >>>>> (type=bridge) or virtual network(type=direct) >>>>> mode(required if type=direct): bridge or vepa >>>>> >>>>> for macvtap: type is direct and mode can be bridge or vepa >>>>> for ovs: type is bridge and mode is not required >>>>> for virtual network: type=network(current implementation) >>>>> >>>>> Examples of network xml for attaching macvtap and ovs to >>>>> guest without libvirt: >>>>> OVS: >>>>> <interface type="bridge"> >>>>> <source bridge="vswitch0"/> >>>>> <virtualport type="openvswitch"/> >>>>> <model type="virtio"/> >>>>> </interface> >>>>> >>>>> macvtap with bridge mode: >>>>> <interface type="direct"> >>>>> <source dev="eth0" mode="bridge"/> >>>>> <model type="virtio"/> >>>>> </interface> >>>>> >>>>> macvtap with vepa mode: >>>>> <interface type="direct"> >>>>> <source dev="bond0" mode="vepa"/> >>>>> <model type="virtio"/> >>>>> </interface> >>>>> >>>> >>>> _______________________________________________ >>>> Kimchi-devel mailing list >>>> Kimchi-devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>> >>> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi all, Such a big discussion but I think I got the idea. My proposal would follow the same approach I suggested for the storage pool issue. As we are close to the code freeze for 2.3 release I will recommend to change as less as possible the current design. Said that, I will say to have a different template.conf file for s390x system on which we will have the 'dirpath' instead of the 'pool' information and the 'interfaces' section instead of the 'networks' parameter. Exactly what Chandra has proposed: [interfaces] [interfaces.1] #type=macvtap #name=eth0, eth1 #mode=bridge or vepa Note that behavior/config will be only allowed for s390x system. For ppc and x86, we continue to use 'networks' and 'pool' information. My idea here is to support s390x according to its libvirt limitation without change the current design for ppc and x86. That way, we will need to change the templates API to insert a new and optional parameter 'interfaces' that will be valid only for s390x system. To add a new network to a guest (/vms/*name*/ifaces), I recommend to add 2 new and optional parameters: mode and source. And keep 'network' parameter for ppc and x86. So we would have: * model (optional): model of emulated network interface card. It can be one of these models: ne2k_pci, i82551, i82557b, i82559er, rtl8139, e1000, pcnet and virtio. When model is missing, libvirt will set 'rtl8139' as default value. * network: *Only for ppc and x86 systems*. Network name * source: *Only valid for s390x system*. Interface or resource bridge name * type: For s390x systems, the supported types are 'network', ‘macvtap’ | ‘ovs’ type. For ppc and x86, only 'network' is supported. * mode: *Only valid for s390x system*. Supported values ’bridge’ or ‘vepa’. required only if type=‘macvtap’ What do you think about it? Once we get it established we can open the support for ppc and x86. Regards, Aline Manera On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
Hi All, To support, attaching a physical interface to guest as macvtap or attaching ovs bridge to guest without creating libvirt network, I propose following changes to 'networks' attribute of templates josn.
current implementation: 'networks' attribute expects list of virtual network names
changes: 'networks': list of dictionary type: can be direct, network or bridge interface: name of physical interface(type=direct) or ovs (type=bridge) or virtual network(type=direct) mode(required if type=direct): bridge or vepa
for macvtap: type is direct and mode can be bridge or vepa for ovs: type is bridge and mode is not required for virtual network: type=network(current implementation)
Examples of network xml for attaching macvtap and ovs to guest without libvirt: OVS: <interface type="bridge"> <source bridge="vswitch0"/> <virtualport type="openvswitch"/> <model type="virtio"/> </interface>
macvtap with bridge mode: <interface type="direct"> <source dev="eth0" mode="bridge"/> <model type="virtio"/> </interface>
macvtap with vepa mode: <interface type="direct"> <source dev="bond0" mode="vepa"/> <model type="virtio"/> </interface>
participants (5)
-
Aline Manera -
Archana Singh -
Chandra Shekhar Reddy Potula -
Daniel Henrique Barboza -
Suresh Babu Angadi