[Kimchi-devel] RFC: Templates API changes for 'networks' attribute
Chandra Shekhar Reddy Potula
chandra at linux.vnet.ibm.com
Mon Aug 22 06:20:09 UTC 2016
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 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/20160822/a1ffda17/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Virtualization Mockups.pdf
Type: application/pdf
Size: 470842 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160822/a1ffda17/attachment.pdf>
More information about the Kimchi-devel
mailing list