[Kimchi-devel] RFC: Templates API changes for 'networks' attribute
Chandra Shekhar Reddy Potula
chandra at linux.vnet.ibm.com
Fri Aug 19 10:51:58 UTC 2016
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 at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Kimchi-devel mailing list
>>>>>>> Kimchi-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kimchi-devel mailing list
>>>>>> Kimchi-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160819/b272faa0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Virtualization Mockups for s390x.pdf
Type: application/pdf
Size: 468954 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160819/b272faa0/attachment.pdf>
More information about the Kimchi-devel
mailing list