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]
<mailto:[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
<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 <[email protected]
<mailto:[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".
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] <mailto:[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] <mailto:[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
