<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi All,</p>
<p>Let me put the detailed summary !!! <br>
</p>
<p>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. <br>
</p>
<p><b>Expectation of the RFC is to attach macvtap and ovs directly
to the guest with out libvirt API calls.</b><br>
<br>
Example domain xml translations of macvtap and ovs (with out any
libvirt calls):<br>
<br>
<b>OVS: </b><br>
<interface type="bridge"> <br>
<source bridge="vswitch0"/> <br>
<virtualport type="openvswitch"/> <br>
<model type="virtio"/> <br>
</interface> <br>
<br>
<b>Macvtap:</b><br>
macvtap with bridge mode: <br>
<interface type="direct"> <br>
<source dev="eth0" mode="bridge"/> <br>
<model type="virtio"/> <br>
</interface> <br>
<br>
macvtap with vepa mode: <br>
<interface type="direct"> <br>
<source dev="bond0" mode="vepa"/> <br>
<model type="virtio"/> <br>
</interface> <br>
<br>
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):<br>
<b>*Note : the same functionality can also exploited on other
platforms too like on x86/ppc etc…</b><br>
<br>
<b>1. Templates</b><br>
A. Current : template.conf contains the following details for
networks :<br>
<br>
[main]</p>
<p>
# List of networks separated by comma
# Represents the virtual
network interfaces to be assigned to guest
#networks = default,<br>
<br>
Proposal : is to have dictionary based network details in the conf
file similar to storage pools.<br>
<br>
[interfaces]
</p>
<p># List of interfaces in the form of dictionary
# Supports
attaching virtual networks, macvtap and ovs bridge to the guest. <br>
# type can be of ‘network’ | ‘macvtap’ | ‘ovs’<br>
# source can be list network or interface or resource bridge name.
Comma separated values allowed if they are of same type.<br>
# mode required only for macvtap. mode can be either bridge or
vepa<br>
<br>
[interfaces.0]<br>
#type=network<br>
#source=default<br>
#mode=NA<br>
<br>
For example to understand other possible types:<br>
[interfaces.1]<br>
#type=macvtap<br>
#source=eth0, eth1<br>
#mode=bridge or vepa<br>
<br>
[interfaces.2]<br>
#type=ovs<br>
#source=ovsswitch1<br>
#mode=NA<br>
<br>
B. API changes for the templates<br>
<br>
Current: network attributes for create/update of template<br>
networks (optional): list of networks will be assigned to the new
VM.<br>
<br>
Proposal:<br>
networks (optional): list of dictionary of networks will be
assigned to the new VM.<br>
type : ‘network’ | ‘macvtap’ |
‘ovs’. By specifying macvtap or ovs these interface will be
attaching to guest directly.<br>
source : network or interface or
resource bridge name<br>
mode(optional) : kimchi supports
’bridge’ or ‘vepa’. required only if type=‘macvtap’<br>
<br>
<br>
<b>2. Virtual Machine Network Interfaces</b><br>
<b>URI: </b>/plugins/kimchi/vms/:name/ifaces<br>
<br>
Current:<br>
POST: attach a network interface to VM<br>
* 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.<br>
* network (optional): the name of resource network, it is required
when the interface type is network.<br>
* type: The type of VM network interface that libvirt supports.
Now kimchi just supports 'network' type.<br>
<br>
Proposal:<br>
POST: attach a network interface to VM<br>
* 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.<br>
* source : the name of resource network or interface or resource
bridge name<br>
* type: kimchi supports 'network' | ‘macvtap’ | ‘ovs’ type.<br>
* mode : kimchi supports ’bridge’ or ‘vepa’. required only if
type=‘macvtap’<br>
<br>
<b>3. Virtual Machine Network Interface</b><b><br>
</b><b>URI:</b> /plugins/kimchi/vms/:name/ifaces/:mac<br>
<br>
Current:<br>
GET: Retrieve the full description of the VM network interface<br>
* bridge (optional): the name of resource bridge, only be
available when the interface type is bridge.<br>
* mac: Media Access Control Address of the VM interface.<br>
* ips: A list of IP addresses associated with this MAC.<br>
* 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.<br>
* network (optional): the name of resource network, only be
available when the interface type is network.<br>
* 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'.<br>
<br>
Proposal: <br>
GET: Retrieve the full description of the VM network interface<br>
* mac: Media Access Control Address of the VM interface.<br>
* ips: A list of IP addresses associated with this MAC.<br>
* 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.<br>
* source: the name of resource network or resource bridge or
interface<br>
* type: It will be one of these types: 'network', ‘macvtap’,
‘ovs’, ’bridge', 'user','ethernet', 'direct', 'hostdev', 'mcast',
'server' and 'client'.<br>
* mode : kimchi supports ’bridge’ or ‘vepa’. required only if
type=‘macvtap’</p>
<p>Please feel free to suggest any other better ways of doing !!!<br>
</p>
Regards<br>
Chandra<br>
<div class="moz-cite-prefix">On 8/11/16 4:46 PM, Suresh Babu Angadi
wrote:<br>
</div>
<blockquote cite="mid:57AC5E8C.4000300@linux.vnet.ibm.com"
type="cite">
<br>
<br>
On 08/10/2016 11:56 PM, Daniel Henrique Barboza wrote:
<br>
<blockquote type="cite">A lot of changes to be made.
<br>
<br>
The changes in Ginger -> Gingerbase regarding OVS bridges is
the simplest
<br>
to do. Gingerbase already has some OVS legacy functions from
before Ginger
<br>
developed the OVS bridges backend in the module netinfo.py. We
can see if
<br>
there's something there to list OVS interfaces (can't recall
now) and, if not, we
<br>
can add it.
<br>
<br>
The remaining Kimchi changes will need to either do in small
chunks, avoiding
<br>
changing the working code we have today, or all at once with UI
changes included
<br>
to avoid breaking the existing UI with the API change. I'll
leave it up to you which
<br>
approach to go, as long as we don't break the existing network
support in Kimchi
<br>
in the process.
<br>
</blockquote>
Agree.
<br>
<blockquote type="cite">
<br>
Assuming that all this precautions are made, I approve this RFC.
However, note that
<br>
this is *my* opinion. I am not the official maintainer of this
plug-in and it would
<br>
be unwise to rely solely on it. It is safer to wait for Aline's
opinion in this
<br>
RFC before taking any step toward the implementation.
<br>
</blockquote>
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.
<br>
<blockquote type="cite">
<br>
<br>
Daniel
<br>
<br>
On 08/10/2016 05:46 AM, Archana Singh wrote:
<br>
<blockquote type="cite">
<br>
On 08/10/2016 12:23 PM, Suresh Babu Angadi wrote:
<br>
<blockquote type="cite">
<br>
<br>
On 08/10/2016 12:24 AM, Daniel Henrique Barboza wrote:
<br>
<blockquote type="cite">I am worried not only by the
API.json changes but also in the
<br>
potential backend changes required. Do you have any
prediction of
<br>
how far these changes might go?
<br>
</blockquote>
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.
<br>
</blockquote>
On high level I guess below needs to be done, and both point
below are independent of each-other.
<br>
1) Listing of networks based on selected type. (This will
mostly use to show list in UI, based on type).
<br>
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.
<br>
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.
<br>
It will be mostly on template/guest edit/create code and
network add/remove from guest/template.
<br>
<br>
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.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
On 08/09/2016 06:12 AM, Suresh Babu Angadi wrote:
<br>
<blockquote type="cite">Hi All,
<br>
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.
<br>
<br>
current implementation:
<br>
'networks' attribute expects list of virtual network
names
<br>
<br>
changes:
<br>
'networks': list of dictionary
<br>
type: can be direct, network or bridge
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
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).
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"> interface: name of
physical interface(type=direct) or ovs (type=bridge) or
virtual network(type=direct)
<br>
mode(required if type=direct): bridge or
vepa
<br>
<br>
for macvtap: type is direct and mode can be bridge or
vepa
<br>
for ovs: type is bridge and mode is not required
<br>
for virtual network: type=network(current
implementation)
<br>
<br>
Examples of network xml for attaching macvtap and ovs to
guest without libvirt:
<br>
OVS:
<br>
<interface type="bridge">
<br>
<source bridge="vswitch0"/>
<br>
<virtualport type="openvswitch"/>
<br>
<model type="virtio"/>
<br>
</interface>
<br>
<br>
macvtap with bridge mode:
<br>
<interface type="direct">
<br>
<source dev="eth0" mode="bridge"/>
<br>
<model type="virtio"/>
<br>
</interface>
<br>
<br>
macvtap with vepa mode:
<br>
<interface type="direct">
<br>
<source dev="bond0" mode="vepa"/>
<br>
<model type="virtio"/>
<br>
</interface>
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Kimchi-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>