[oVirt][Quantum] question about quantum CLI

Gary Kotton gkotton at redhat.com
Fri Jun 15 06:11:39 UTC 2012


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 
> <http://bazaar.launchpad.net/%7Enetstack-core/quantum/essex/view/head:/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py>
>
>
> 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 <gkotton at redhat.com 
> <mailto:gkotton at redhat.com>> 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".
>>
>>     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 at openstack:/tmp$ ./ovirt.sh network create Q_net
>     openstack at 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 at openstack:/tmp$
>
>
>     openstack at 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 at openstack:/tmp$ cat network.Q_net.12345678.port.attach
>     24bf26c4-f8eb-46cd-a168-b7a25e64d5b2
>     openstack at openstack:/tmp$
>
>     Thanks
>     Gary
>
>>
>>     BR,
>>     Kris
>>
>>
>>     On Wed, Jun 13, 2012 at 2:02 PM, Gary Kotton <gkotton at redhat.com
>>     <mailto:gkotton at redhat.com>> 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
>>>         <gkotton at redhat.com <mailto:gkotton at redhat.com>> 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
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120615/f2689600/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 172132 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120615/f2689600/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 53568 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/arch/attachments/20120615/f2689600/attachment-0001.png>


More information about the Arch mailing list