Hi Kotton,<div><br></div><div>Thanks for these days help, currently i haven't any other questions.</div><div><br></div><div>Thanks again,</div><div>Kris</div><div><br><br><div class="gmail_quote">On Mon, Jun 18, 2012 at 1:52 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div bgcolor="#ffffff" text="#000000">
Hi,<br>
Please see inline.<br>
Thanks<br>
Gary<div class="im"><br>
<br>
On 06/18/2012 04:11 AM, Kris zhang wrote:
</div><blockquote type="cite">Hi Kotton,
<div><br>
</div><div class="im">
<div>Thanks for your detailed answer, and it's very clear, and i
still have some other questions:</div>
<div><br>
</div>
<div>1) Where i can find the database changes? please correct me
if no change in db.</div>
</div></blockquote>
<br>
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:<br>
<br>
- oVirt Engine will support one Quantum service (the instance
currently supports only 1 plugin)
<br>
- oVirt installation will have Quantum service as a
dependency
<br>
- All hosts in a cluster must have the same networking support.
This can be one of the following:
<br>
- Legacy oVirt networking
<br>
- Legacy oVirt networking for management and Quantum for VM
networking
<br>
- 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
<br>
- If a logical network is assigned to a Quantum cluster then
this network must be registered with Quantum (to get the UUID)
<br>
- All VM's running on this cluster will receive a port ID and
pass an attachment ID to the Quantum
<br>
- Limitations:
<br>
- No network statistics for logical quantum networks
<br>
<br>
I think that small secluded changes can help the integration - for
example:-<br>
- implement a REST client (used to communicate with Quantum
service)<br>
- update database to store relevant quantum ID's<br>
- improve VDMS support for Quantum code (have a plugin
architecture - so that different technologies can plug their code
into VDSM)<br>
- address HOST management<br>
- packaging<div class="im"><br>
<br>
<blockquote type="cite">
<div>2) If the engine server crashed, then how to rebuild the
network information which generated by ovirt.sh script in the
/tmp dir?</div>
</blockquote>
<br></div>
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. <br>
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.<div class="im"><br>
<blockquote type="cite">
<div><br>
</div>
<div>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?</div>
</blockquote>
<br></div>
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.<div><div class="h5"><br>
<blockquote type="cite">
<div><br>
</div>
<div>Best regards,</div>
<div>Kris</div>
<div><br>
</div>
<div><br>
<br>
<div class="gmail_quote">On Fri, Jun 15, 2012 at 2:11 PM, Gary
Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"> Hi Kris,<br>
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.<br>
Network management (1a):<br>
- user create a Quantum network<br>
- user will create a Quantum port and attachment<br>
VM Management (1b):<br>
- users creates a VM<br>
- assigned VM to one or more logical networks. Each
each assignment will receive the above quantum details<br>
VM flow:<br>
- VDSM creates the libvirt XML file<br>
- (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<br>
- in later versions of libvirt, libvirt will do
the create via the attachment id <br>
- VDSM will start the VM<br>
Network flow (2a and 3a):<br>
- 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<br>
Hope that I have answered your questions.<br>
Thanks<span><font color="#888888"><br>
Gary</font></span>
<div>
<div><br>
<br>
On 06/14/2012 10:49 AM, Kris zhang wrote:
<blockquote type="cite">
<div>Hi Kotton,</div>
<div><br>
</div>
<div>Thank your very much, and i still have a
question:</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>The ovs quantum agent code is in the <a href="http://bazaar.launchpad.net/%7Enetstack-core/quantum/essex/view/head:/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py" target="_blank">http://bazaar.launchpad.net/~netstack-core/quantum/essex/view/head:/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py</a></div>
<div><br>
</div>
<div><br>
</div>
<div><img src="https://mail.google.com/mail/u/0/?ui=2&ik=479f3a633f&view=att&th=137efc865da05b6b&attid=0.1&disp=emb&realattid=456f2e09b4c966a5_0.1.1&zw&atsh=1" alt="Inline image 1"><br>
</div>
<div><br>
</div>
<div>Please see above the image, and there are two
ways:</div>
<div><br>
</div>
<div>First way: 1a, 2a, 3a. <br>
</div>
<div>Second way: 1b, 2b</div>
<div><br>
</div>
<div>which way is used in POC?</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Kris</div>
<div><br>
</div>
<br>
<br>
<div class="gmail_quote">On Wed, Jun 13, 2012 at
5:48 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#ffffff" text="#000000">
<div> On 06/13/2012 11:57 AM, Kris zhang
wrote:
<blockquote type="cite">
<div>Thanks for you detail answer, and
please see the result of the command
quantum update_port,</div>
</blockquote>
</div>
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.<br>
The "user" is responsible for providing the
attachment ID. In the case of the ovirt.sh
script the ID is generated via uuidgen. <br>
Once you have generated a UUID for the
attachment you need to pass this to quantum
via the "quantum plug_iface". <br>
<div>
<blockquote type="cite">
<div><br>
</div>
<div><img src="https://mail.google.com/mail/u/0/?ui=2&ik=479f3a633f&view=att&th=137efc865da05b6b&attid=0.2&disp=emb&realattid=456f2e09b4c966a5_0.1.2&zw&atsh=1" alt="Inline image 1"><br>
</div>
<div><br>
</div>
<div>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?</div>
</blockquote>
<br>
</div>
Please see below:<br>
<br>
openstack@openstack:/tmp$ ./ovirt.sh network
create Q_net<br>
openstack@openstack:/tmp$ ./ovirt.sh port
create Q_net 12345678<br>
Updated Logical Port with ID:
f9f203ab-dab6-4b9c-8dcf-561bcc698c76<br>
on Virtual Network:
8c50db01-54ef-4688-a274-9ab3fcfafe7d<br>
for tenant: default<br>
Plugged interface
24bf26c4-f8eb-46cd-a168-b7a25e64d5b2<br>
into Logical Port:
f9f203ab-dab6-4b9c-8dcf-561bcc698c76<br>
on Virtual Network:
8c50db01-54ef-4688-a274-9ab3fcfafe7d<br>
for Tenant: default<br>
openstack@openstack:/tmp$ <br>
<br>
<br>
openstack@openstack:/tmp$ ll<br>
total 40<br>
drwxrwxrwt 4 root root 4096
2012-06-13 05:39 ./<br>
drwxr-xr-x 23 root root 4096
2012-05-26 06:39 ../<br>
-rw-rw-r-- 1 openstack openstack 6
2012-06-13 05:38 network.12345678<br>
-rw-rw-r-- 1 openstack openstack 37
2012-06-13 05:38 network.Q_net<br>
-rw-rw-r-- 1 openstack openstack 37
2012-06-13 05:38 network.Q_net.12345678.port<br>
-rw-rw-r-- 1 openstack openstack 37
2012-06-13 05:38
network.Q_net.12345678.port.attach<br>
-rwxrwxrwx 1 openstack openstack 2097
2012-06-13 05:07 ovirt.sh*<br>
-rw-rw-r-- 1 openstack openstack 1797
2012-06-13 05:38 ovirt.txt<br>
<br>
openstack@openstack:/tmp$ cat
network.Q_net.12345678.port.attach <br>
24bf26c4-f8eb-46cd-a168-b7a25e64d5b2<br>
openstack@openstack:/tmp$ <br>
<br>
Thanks<span><font color="#888888"><br>
Gary</font></span>
<div>
<div><br>
<blockquote type="cite">
<div><br>
</div>
<div>BR,</div>
<div>Kris</div>
<br>
<br>
<div class="gmail_quote">On Wed, Jun 13,
2012 at 2:02 PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"> Hi Kris,<br>
Please see my answers and
questions below.<br>
Thanks<br>
Gary
<div><br>
<br>
On 06/13/2012 07:31 AM, Kris
zhang wrote:
<blockquote type="cite">
<div>Hi Kotton,</div>
<div><br>
</div>
<div>In the file ovirt.sh,
there is a line:</div>
</blockquote>
<br>
</div>
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:<br>
1. Logical Network Management:<br>
Create:<br>
ovirt.sh network create
<name><br>
- the name is the name
of the logical network (in the POC
this is prefixed by "Q_"<br>
- this invokes the cli
to create a network called
<name><br>
- the UUID returned by
the quantum service will be save
in /tmp/network.<name><br>
- the above UUID is
read when this logical network is
used (this in the future will be
save in the oVirt data base)<br>
Delete:<br>
ovirt.sh network remove
<name><br>
- the name is the name
of the logical network (in the POC
this is prefixed by "Q_"<br>
- this invokes the cli
to delete a network called
<name><br>
- the file
/tmp/network.<name> is
deleted<br>
2. VM Port management<br>
Create:<br>
ovirt.sh port create
<net_name> <vmid><br>
- the network name and
the vm id are input (the VM id is
a key to be able to delete it all
:))<br>
- the script does the
following:<br>
- creates a port
on the network. saves the port id
in
/tmp/network.<name>.<vmid>.port<br>
- sets the state
of the port to ACTIVE<br>
- creates an
attachment ID (this is the line
that you had problems with). This
is saved in
/tmp/network.<name>.<vmid>.attachment<br>
- saves the
network name in a file
/tmp/network.<vmid><br>
- the UUID's are
read when the VM is started so
that they can be passed to VDSM<br>
Delete:<br>
ovirt.sh port remove
<vmid><br>
- using the vmid the
network name is read => enables
us to get all of the ID's to
delete port in quantum<br>
- cleans all of the
files<br>
The script is called from the
ovirt engine. Sorry for the long
winded explanation.
<div><br>
<br>
<blockquote type="cite">
<div>
<div>quantum update_port
default $NET_UUID
$PORT_UUID state=ACTIVE</div>
<div> uuidgen
>
/tmp/network.$3.$4.port.attach</div>
<div><span style="white-space:pre-wrap"><br>
</span>ATTACH_UUID=`cat
/tmp/network.$3.$4.port.attach`</div>
</div>
</blockquote>
<br>
</div>
In Quantum the attachment ID is
generated by the user. The code
above generates the attachment ID
for the port. <br>
<div>
<blockquote type="cite">
<div><br>
</div>
<div><br>
</div>
<div>But i run this command, i
found there is no any uuid
generated, so what's the
value of the ATTACH_UUID?</div>
</blockquote>
</div>
Do you run the script from the
shell or is this run via oVirt? <br>
There is a log of all of the
script command - can you please
look in /tmp/ovirt.txt - this may
give us some clues.<br>
You can run the script commands as
described above. This may also
help.<br>
Thanks<span><font color="#888888"><br>
Gary</font></span>
<div><br>
<blockquote type="cite">
<div>Best regards,</div>
<div>Kris</div>
<br>
<br>
<div class="gmail_quote">On
Tue, Jun 12, 2012 at 7:15
PM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 06/12/2012 12:36
PM, Itamar Heim wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> On 06/12/2012
11:47 AM, Gary
Kotton wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Hi Kris,<br>
Thanks for the
questions. Please
see my inline
answers. I have
also<br>
cc'ed the ovirt
arch mailing list.<br>
Thanks<br>
Gary<br>
<br>
On 06/12/2012
11:21 AM, Kris
zhang wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Hi
Gkotton,<br>
<br>
I have some
questions:<br>
<br>
1) In the file
"ovirt.sh", i
found the
command quantum
always use the<br>
tenant
"default", so if
the ovirt don't
support
multi-tenant?<br>
</blockquote>
oVirt does not
support multi
tenancy at the
moment. Maybe
there are<br>
people on the list
who can provide
more details about
this. The initial<br>
plan was to use
the "default"
tenant.<br>
</blockquote>
<br>
ovirt supports
multiple users and
an RBAC model for
permissions between
these users.<br>
what exactly are you
looking for?<br>
</blockquote>
</div>
</div>
Quantum support multi
tenancy. The integration
with oVirt was done with
the "default" tenant. This
is a different model to
that of oVirt.<br>
Thanks<span><font color="#888888"><br>
Gary<br>
</font></span></blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>