[Engine-devel] oVirt and Quantum

Tue May 15 10:44:39 UTC 2012

On 05/03/2012 03:18 PM, Gary Kotton wrote:
> Hi,
> Thanks for the input. Please see my inline comments.
> Thanks
> Gary
>
> On 05/03/2012 12:02 PM, Irena Berezovsky wrote:
>> Gary,
>> Thank you for a very detailed proposal.
>> I would like to address several issues of the proposed Quantum-oVirt
>> integration.
>>
>> 1. User Interface:
>> Network Management
>> I suggest to consider Logical Network Management to indicate if the
>> Network should be managed by Quantum or not. This may lead to
>> different options that user can specify via UI. It can have a Network
>> Type attribute. Maybe it is a place to consider custom properties
>> piggy-backing.
> This is an interesting point. I am not sure that the user should be
> exposed to this. My intentions when writing the integration notes were
> to try and keep things simple for the user. There are a number of options:
> - Uniform cluster support - If the UI for the cluster could provide an
> interface for the network properties then it would be great. If each
> Host in the cluster has the same characteristics then one configuration
> could be used for each host - for example the NIC of the integration
> bridge in the case of OVS plugin.
> - Non uniform cluster support - in this case each Host will need to be
> configured separately. Live migration could be challenging - this can
> and should be done only between hosts with the same networking
> characteristics.

at least today, a cluster best definition is a live migration domain. so 
if live migration is not supported between different plugins or 
with/without qunatum - definition of plugin should be at cluster level 
and required from all hosts.

>> Host management
>> As long as the proposed API is used for viewing interface it's OK. It
>> just should not be required by user to go over each Host and define
>> each interface with type of Fabric he should manage. Maybe it should
>> be some defaults on Cluster level (will work for Homogenous cluster).
> Addressed above.
>>
>> 2. Back End
>> Network Creation:
>> If not every Host in the cluster has Quantum supporting interface, it
>> should be forbidden to apply VM migrate operation to such Host. This
>> probably should be indicated properly via UI and Backed should not
>> start the migrate process.
> I also think that this is addressed above.
>> VM Creation:
>> To be able to extend the basic Quantum API and add some QoS/Port
>> Profile attributes to the port ( like in Cisco plugin). There should
>> be some way in oVirt to map between port uuid (+ network)and VM id.
> This is addressed in the wiki. For each VM the oVirt engine should keep
> the relevant UUID's.
> "Each of the above is represented by a UUID. oVirt should save all of
> the UUID's with the relevant artifacts that make use of the information,
> namely the logical network and the virtual machines. The usage of these
> will be discussed below."
> I could describe this more explicitly.

ovirt engine keeps it. how would one query by it though? what api and 
credentials would they be using to do so?

>> VM Migrate:
>> Even though it's just an initial suggestion, I think that VM migration
>> use case should be elaborated also for 'else' cases. What happens if
>> target Host does not support Quantum? What happens if target host
>> fails to run VM? Another issue is a lack of calls to Quantum. For my
>> understanding (but I can be wrong) in OpenStack it will issue unplug
>> and plug attachment calls.
> I agree. The goal here should be VM uptime and connectivity. If the
> "network" connectivity can be support but in a limited fashion then
> great - the migration can take place - this should nonetheless only be
> done when there is no other option. The live migration algorithm may
> have to be tweaked to support this.

we do not assume involvement in engine in live migration today other 
than issuing a 'migrate' command to source host, or host needing 
information from engine to perform the live migration.
there must be a very good reason to break this assumption.

>> 3. VDSM
>> Host Management: Any suggestion /plans to define a way to write and
>> deploy a Vif plug Driver ( a complimentary part to the Quantum Agent)?
> In Quantum the spirit of things is to keep the driver as thin as
> possible. The Quantum agent that runs on the VDSM host should do most of
> the work. It would be best if VDSM could provide a "plugin" mechanism
> that support the following:
> 1. deviceNameGet - this is due to the fact that the agent knows the
> device name - in the case of ovs and linux bridge this is done by using
> the first 11 characters of the attachment UUID. Other plugins may
> operate in a different manner.
> 2. vifAdd - this will be called with the MAC address, the VM UUID and
> maybe additional information
> 3. vifDelete
>
>> Regards,
>> Irena
>> -----Original Message-----
>> From: engine-devel-bounces at ovirt.org
>> [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Gary Kotton
>> Sent: Monday, April 30, 2012 2:56 PM
>> To: dlaor at redhat.com
>> Cc: engine-devel at ovirt.org; users at ovirt.org
>> Subject: Re: [Engine-devel] oVirt and Quantum
>>
>> On 04/30/2012 10:39 AM, Dor Laor wrote:
>>> Gary, would it be possible to compare the current major api verbs
>>> offered by Quantum vs the ones offered by oVirt?
>> Please look at
>> https://docs.google.com/presentation/d/1cLW88tPw-8z_ANXU2WC8gd4U2k-ACrPnMQbgj5wDLz4/edit#slide=id.p
>>
>> This gives a high level explanation of Quantum and the flows. In short
>> both Quantum and oVirt enable the creation of logical networks. By
>> design Quantum hides the network details from the user. In oVirt the
>> user is able to configure the tags etc. We are in the process of
>> addressing this.
>>
>>> It would be nice to review the length/feature-rich of each and also
>>> the ease of use.
>> In addition to linux bridge (which is what oVirt uses today), Quantum
>> supports Open vSwitch, RYU and Cisco UCS - these are not supported by
>> oVirt at the moment. The RYU and Open vSwitch support OpenFlow
>>> In addition, what would be the todo items in order to get OVS working
>>> w/ oVirt?
>> Actually not much. In fact this is currently supported with the
>> Quantum integration. There are two parts:
>> 1. The VM vNic management (implemented):
>> i. Create a tap device that has "ethernet" as the the network device
>> ii. Set the device us UP
>> ii. Attach to the integration bridge and configure tags etc. (The
>> Quantum agent does this part)
>>
>> 2. The host management (to be implemented):
>> i. oVirt Engine and VDSM need to indicate which physical network
>> interfaces will use the integration bridge. This can be one or more
>> NICS or a bond (in Quantum this is part of a configuration file). We
>> need to think of a nice way to show this in the GUI.
>> ii. The logic in oVirt engine that "decides" if a Host is "Non
>> Operational" needs to be updated.
>>> Example for Quantum:
>>> http://docs.openstack.org/incubation/openstack-network/developer/quant
>>> um-api-1.0/content/Show_port_Details.html#d6e777
>>>
>>> Cheers,
>>> Dor
>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel