Hi Kotton, Thanks for these days help, currently i haven't any other questions.
Thanks again, Kris On Mon, Jun 18, 2012 at 1:52 PM, Gary Kotton <[email protected]> wrote: > ** > Hi, > Please see inline. > Thanks > Gary > > > On 06/18/2012 04:11 AM, Kris zhang wrote: > > Hi Kotton, > > Thanks for your detailed answer, and it's very clear, and i still have > some other questions: > > 1) Where i can find the database changes? please correct me if no change > in db. > > > At the moment in oVirt there are no database changes. The code that you > are looking at is a POC. We (the community) still need to address the > database changes.I think that prior to adding the database changes we > should first add a REST client that can communicate with the Quantum > service (at the moment this is done via the Quantum CLI). I have a short > list of items that need to be addressed for a a basic Quantum integration > (this will at least give us the infrastructure to build on in the future). > I think that for the first phase we should support the following: > > - oVirt Engine will support one Quantum service (the instance > currently supports only 1 plugin) > - oVirt installation will have Quantum service as a dependency > - All hosts in a cluster must have the same networking support. This > can be one of the following: > - Legacy oVirt networking > - Legacy oVirt networking for management and Quantum for VM > networking > - When a VDSM host is registered (IP, password etc), one of the above > methods will registered. If this Quantum, then the relevant configuration > data will be sent to VDSM. Agent packages will exist on VDSM > - If a logical network is assigned to a Quantum cluster then this > network must be registered with Quantum (to get the UUID) > - All VM's running on this cluster will receive a port ID and pass an > attachment ID to the Quantum > - Limitations: > - No network statistics for logical quantum networks > > I think that small secluded changes can help the integration - for > example:- > - implement a REST client (used to communicate with Quantum service) > - update database to store relevant quantum ID's > - improve VDMS support for Quantum code (have a plugin architecture - > so that different technologies can plug their code into VDSM) > - address HOST management > - packaging > > > > 2) If the engine server crashed, then how to rebuild the network > information which generated by ovirt.sh script in the /tmp dir? > > > Please note that this is a POC. All of the data generated by the script is > persistent - that is, it is stored in the /tmp directory. I am not really > sure that I understand your question. If oVirt engine crashes then the user > will not be able to deploy VM's. If the Quantum service crashes then the > user should not be able to configure Quantum networks or attach ports etc. > If the quantum service crashes or is unreachable by VDSM then a newly > deployed VM may not be able to "attach" to the Quantum network. This can be > averted by having the following - on oVirt engine there should be a process > that monitors the status of the Quantum service. If this is down then it > should restart it. This can and should be discussed in more detail. > > > In addition, originally i think the quantum port create is no any > relationship with vm create, and only be linked when a VIF of a VM attach > into a port. But your design is different, so there is no port creation in > the web UI, right? > > > My thinking is that when a VNIC of a VM is linked to a Quantum network > then the Quantum port should be created. After some discussion I understand > that the oVirt VNIC has a UUID - this can now be used as the attachment ID. > In my opinion the Quantum interface should be limited to the host > management. The rest should be "hidden" from the user. > > > Best regards, > Kris > > > > On Fri, Jun 15, 2012 at 2:11 PM, Gary Kotton <[email protected]> wrote: > >> Hi Kris, >> You have asked a very interesting and good question. Please see the >> answers an explanations below. Both flow are used. The "a" flows (1a2a and >> 3a) are for the network management. The "b" flows (1b and 2b) are for the >> VM management. >> Network management (1a): >> - user create a Quantum network >> - user will create a Quantum port and attachment >> VM Management (1b): >> - users creates a VM >> - assigned VM to one or more logical networks. Each each assignment >> will receive the above quantum details >> VM flow: >> - VDSM creates the libvirt XML file >> - (2b) if libvirt version is 0.9.10 or earlier then VDSM will >> have to create the tap device (via attachment ID) and will set it with type >> 'ethernet' in the libvirt file (this is what was done in the POC). In >> addition this it need to notify OVS of the VM ID on the port >> - in later versions of libvirt, libvirt will do the create via >> the attachment id >> - VDSM will start the VM >> Network flow (2a and 3a): >> - The Quantum agent polls the Quantum plugin for network changes. If >> the agent detects a tap device that is part of a network then it will >> configure the characteristics of this tap device on the OVS. In the case of >> the POC it will be the VLAN tag of the network >> Hope that I have answered your questions. >> Thanks >> Gary >> >> >> On 06/14/2012 10:49 AM, Kris zhang wrote: >> >> Hi Kotton, >> >> Thank your very much, and i still have a question: >> >> There is a quantum.py file in the gkotton-vdsm_quantum-78427ca.zip. I >> saw there are some methods (For example: vifAddOpenVswitch() ) to call >> ovs-vsctl command, that means vdsm will control the ovs, not through ovs >> quantum agent? >> >> The ovs quantum agent code is in the >> http://bazaar.launchpad.net/~netstack-core/quantum/essex/view/head:/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py >> >> >> [image: Inline image 1] >> >> Please see above the image, and there are two ways: >> >> First way: 1a, 2a, 3a. >> Second way: 1b, 2b >> >> which way is used in POC? >> >> Best regards, >> Kris >> >> >> >> On Wed, Jun 13, 2012 at 5:48 PM, Gary Kotton <[email protected]> wrote: >> >>> On 06/13/2012 11:57 AM, Kris zhang wrote: >>> >>> Thanks for you detail answer, and please see the result of the command >>> quantum update_port, >>> >>> The command "quantum update_port" sets the state of the port. In the >>> case of the ovirt.sh script this sets the port in ACTIVE state. >>> The "user" is responsible for providing the attachment ID. In the case >>> of the ovirt.sh script the ID is generated via uuidgen. >>> Once you have generated a UUID for the attachment you need to pass this >>> to quantum via the "quantum plug_iface". >>> >>> >>> [image: Inline image 1] >>> >>> I run this script from the shell, and you can see there is no an >>> attachment UUID created. Can you show me your testing result? >>> >>> >>> Please see below: >>> >>> openstack@openstack:/tmp$ ./ovirt.sh network create Q_net >>> openstack@openstack:/tmp$ ./ovirt.sh port create Q_net 12345678 >>> Updated Logical Port with ID: f9f203ab-dab6-4b9c-8dcf-561bcc698c76 >>> on Virtual Network: 8c50db01-54ef-4688-a274-9ab3fcfafe7d >>> for tenant: default >>> Plugged interface 24bf26c4-f8eb-46cd-a168-b7a25e64d5b2 >>> into Logical Port: f9f203ab-dab6-4b9c-8dcf-561bcc698c76 >>> on Virtual Network: 8c50db01-54ef-4688-a274-9ab3fcfafe7d >>> for Tenant: default >>> openstack@openstack:/tmp$ >>> >>> >>> openstack@openstack:/tmp$ ll >>> total 40 >>> drwxrwxrwt 4 root root 4096 2012-06-13 05:39 ./ >>> drwxr-xr-x 23 root root 4096 2012-05-26 06:39 ../ >>> -rw-rw-r-- 1 openstack openstack 6 2012-06-13 05:38 network.12345678 >>> -rw-rw-r-- 1 openstack openstack 37 2012-06-13 05:38 network.Q_net >>> -rw-rw-r-- 1 openstack openstack 37 2012-06-13 05:38 >>> network.Q_net.12345678.port >>> -rw-rw-r-- 1 openstack openstack 37 2012-06-13 05:38 >>> network.Q_net.12345678.port.attach >>> -rwxrwxrwx 1 openstack openstack 2097 2012-06-13 05:07 ovirt.sh* >>> -rw-rw-r-- 1 openstack openstack 1797 2012-06-13 05:38 ovirt.txt >>> >>> openstack@openstack:/tmp$ cat network.Q_net.12345678.port.attach >>> 24bf26c4-f8eb-46cd-a168-b7a25e64d5b2 >>> openstack@openstack:/tmp$ >>> >>> Thanks >>> Gary >>> >>> >>> BR, >>> Kris >>> >>> >>> On Wed, Jun 13, 2012 at 2:02 PM, Gary Kotton <[email protected]> wrote: >>> >>>> Hi Kris, >>>> Please see my answers and questions below. >>>> Thanks >>>> Gary >>>> >>>> >>>> On 06/13/2012 07:31 AM, Kris zhang wrote: >>>> >>>> Hi Kotton, >>>> >>>> In the file ovirt.sh, there is a line: >>>> >>>> >>>> A bit of background regarding the script. The purpose of the POC was >>>> to show that Quantum can be run in oVirt. It would have been ideal to write >>>> a REST client that could interface with the Quantum service. Due to the >>>> fact that I was not familiar with the oVirt code I felt that a quicker and >>>> more productive means was to invoke a bash script from the oVirt engine >>>> code. The script would invoke the quantum cli (this is a client that >>>> configures the quantum server). In addition to this I did not want to make >>>> any changes to the database schema. The result was a script that does the >>>> following: >>>> 1. Logical Network Management: >>>> Create: >>>> ovirt.sh network create <name> >>>> - the name is the name of the logical network (in the POC >>>> this is prefixed by "Q_" >>>> - this invokes the cli to create a network called <name> >>>> - the UUID returned by the quantum service will be save in >>>> /tmp/network.<name> >>>> - the above UUID is read when this logical network is used >>>> (this in the future will be save in the oVirt data base) >>>> Delete: >>>> ovirt.sh network remove <name> >>>> - the name is the name of the logical network (in the POC >>>> this is prefixed by "Q_" >>>> - this invokes the cli to delete a network called <name> >>>> - the file /tmp/network.<name> is deleted >>>> 2. VM Port management >>>> Create: >>>> ovirt.sh port create <net_name> <vmid> >>>> - the network name and the vm id are input (the VM id is a >>>> key to be able to delete it all :)) >>>> - the script does the following: >>>> - creates a port on the network. saves the port id in >>>> /tmp/network.<name>.<vmid>.port >>>> - sets the state of the port to ACTIVE >>>> - creates an attachment ID (this is the line that you >>>> had problems with). This is saved in /tmp/network.<name>.<vmid>.attachment >>>> - saves the network name in a file /tmp/network.<vmid> >>>> - the UUID's are read when the VM is started so that >>>> they can be passed to VDSM >>>> Delete: >>>> ovirt.sh port remove <vmid> >>>> - using the vmid the network name is read => enables us to >>>> get all of the ID's to delete port in quantum >>>> - cleans all of the files >>>> The script is called from the ovirt engine. Sorry for the long winded >>>> explanation. >>>> >>>> >>>> quantum update_port default $NET_UUID $PORT_UUID state=ACTIVE >>>> uuidgen > /tmp/network.$3.$4.port.attach >>>> >>>> ATTACH_UUID=`cat /tmp/network.$3.$4.port.attach` >>>> >>>> >>>> In Quantum the attachment ID is generated by the user. The code above >>>> generates the attachment ID for the port. >>>> >>>> >>>> >>>> But i run this command, i found there is no any uuid generated, so >>>> what's the value of the ATTACH_UUID? >>>> >>>> Do you run the script from the shell or is this run via oVirt? >>>> There is a log of all of the script command - can you please look in >>>> /tmp/ovirt.txt - this may give us some clues. >>>> You can run the script commands as described above. This may also help. >>>> Thanks >>>> Gary >>>> >>>> Best regards, >>>> Kris >>>> >>>> >>>> On Tue, Jun 12, 2012 at 7:15 PM, Gary Kotton <[email protected]>wrote: >>>> >>>>> On 06/12/2012 12:36 PM, Itamar Heim wrote: >>>>> >>>>>> On 06/12/2012 11:47 AM, Gary Kotton wrote: >>>>>> >>>>>>> Hi Kris, >>>>>>> Thanks for the questions. Please see my inline answers. I have also >>>>>>> cc'ed the ovirt arch mailing list. >>>>>>> Thanks >>>>>>> Gary >>>>>>> >>>>>>> On 06/12/2012 11:21 AM, Kris zhang wrote: >>>>>>> >>>>>>>> Hi Gkotton, >>>>>>>> >>>>>>>> I have some questions: >>>>>>>> >>>>>>>> 1) In the file "ovirt.sh", i found the command quantum always use >>>>>>>> the >>>>>>>> tenant "default", so if the ovirt don't support multi-tenant? >>>>>>>> >>>>>>> oVirt does not support multi tenancy at the moment. Maybe there are >>>>>>> people on the list who can provide more details about this. The >>>>>>> initial >>>>>>> plan was to use the "default" tenant. >>>>>>> >>>>>> >>>>>> ovirt supports multiple users and an RBAC model for permissions >>>>>> between these users. >>>>>> what exactly are you looking for? >>>>>> >>>>> Quantum support multi tenancy. The integration with oVirt was done >>>>> with the "default" tenant. This is a different model to that of oVirt. >>>>> Thanks >>>>> Gary >>>>> >>>> >>>> >>>> >>> >>> >> >> > >
_______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
