7:18 a.m.
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.
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.
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.
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(a)ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of
Gary Kotton
Sent: Monday, April 30, 2012 2:56 PM
To: dlaor(a)redhat.com
Cc: engine-devel(a)ovirt.org; users(a)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-ACrPnM...
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel