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