[Engine-devel] oVirt and Quantum

Tue May 15 11:39:18 UTC 2012

On 05/15/2012 02:34 PM, Irena Berezovsky wrote:
> Please see my comments inline
>
> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: Tuesday, May 15, 2012 1:45 PM
> To: gkotton at redhat.com
> Cc: Irena Berezovsky; engine-devel at ovirt.org
> Subject: Re: [Engine-devel] oVirt and Quantum
>
> 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?
> [IB] I think it should be accessible via REST and SDK .
> I guess it should use admin credentials, but not sure.

REST doesn't support lookup by every property and the is search for 
vnics/ports.
so a modeling question.
I'm not sure i like the concept of providing an administrative user 
credentials to all hosts, or of managing a password change in this case.
not sure hosts should use the REST API, or another API intended for 
bi-directional communication with engine, secured in the same way the 
xml/rpc is secured.

>
>>> 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.
> [IB] If this assumption should be in place, maybe it worth to consider to invoke 'create port' and 'plug interface' Quantum calls from VDSM node and not from oVirt engine. This this  the model in OpenStack. Nova-compute invokes 'create port' and 'plug interface' Quantum calls.
> It is described in the following doc:
> http://wiki.openstack.org/QuantumAPIUseCases

I'm not sure i like that better.
would it be possible for engine to pre-provision the port on more than 
one host?

>
>
>>> 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-AC
>>> rPnMQbgj5wDLz4/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/qua
>>>> nt
>>>> 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
>