9:41 p.m.
Hi All,
This is a summary of the first quantum-oVirt integration meeting.
In the meeting Garry Kotton started presenting his proposal for the
integration, for more details on his proposal look in -
http://www.ovirt.org/wiki/Quantum_and_oVirt
We did not cover much of the wiki as some question arose:
* What is the end goal of the integration? is it to replace the current
network configuration implementation in oVirt by quantum or have them
side by side.
- we need to remember non-VM networks (like storage and migration networks)
* Will oVirt use multiple quantum instances, one per technology, or will
oVirt use a single quantum instance that should support multiple
plug-ins (not supported in Quantum ATM)
* We'll oVirt support a mix of different technologies in a DC, Cluster,
host?
- Can we assume homogeneous clusters for the sake of simplicity (in a
single cluster we'll support either open Vswitch or UCSM or ..)
- Logical Network is defined in the scope of a data center, that means
we need to maintain layer 2 connectivity and within a cluster we need to
guarantee VM live migration (does libvirt abstract it for us?)
other notes -
* The UUIDs that are returned by Quantum will be managed by oVirt and
for a single network implemented in two different technologies in
quantum oVirt will be responsible to sync the different IDs.
* The integration should be as seamless as possible to the user of oVirt
* support of existing VLAN in quantum should be introduces in quantum in
a 3-4 weeks time-frame
Comments are welcomed, I'll schedule a follow up next week.
Thanks, Livnat
9:01 a.m.
Hi,
Thanks for the time yesterday. Please see my inline comments.
Please feel free to contact me if you have any additional questions.
Thanks
Gary
On 06/06/2012 09:41 PM, Livnat Peer wrote:
Hi All,
This is a summary of the first quantum-oVirt integration meeting.
In the meeting Garry Kotton started presenting his proposal for the
integration, for more details on his proposal look in -
http://www.ovirt.org/wiki/Quantum_and_oVirt
We did not cover much of the wiki as some question arose:
* What is the end goal of the integration? is it to replace the current
network configuration implementation in oVirt by quantum or have them
side by side.
I think that the first phase should enable them to work together.
That
is, the user can have host that run traditional VDSM networking and host
that run a specific Quantum agent. In addition to this. I think that the
user should also have the flexibility to choose which network interfaces
run Quantum or traditional VDSM.
In short the answer is "side by side".
- we need to remember non-VM networks (like storage and migration
networks)
The crystallizes the point above, management and storage can continue to
use the existing VDSM networking and the VM networks can start to use
Quantum.
* Will oVirt use multiple quantum instances, one per technology, or
will
oVirt use a single quantum instance that should support multiple
plug-ins (not supported in Quantum ATM)
oVirt should use one Quantum instance.
Today I will draw up a blueprint
for Quantum to have a "Rosetta Plugin", that is a plugin that can
support a number of different networking technologies.
* We'll oVirt support a mix of different technologies in a DC,
Cluster,
host?
I think that the only limitation should be to run one Quantum agent per
host.
- Can we assume homogeneous clusters for the sake of simplicity (in
a
single cluster we'll support either open Vswitch or UCSM or ..)
I do not think
that we should go for a simple solution, but we should
strive for a proper solution. I see no reason to prevent or limit this.
I feel that this would be a hard limitation for oVirt users. A example
to show this limitation is the addition of a host to the existing
cluster that has new networking capabilities that are supported by a
different Quantum plugin.
oVirt must be aware of the capabilities of each host to indicate to the
user that certain operations may not be possible, or may cause the
virtual machine to behave differently (performance degradation for
example), if they have decided to work in this manner - for example live
live migration.
- Logical Network is defined in the scope of a data center, that
means
we need to maintain layer 2 connectivity and within a cluster we need to
guarantee VM live migration (does libvirt abstract it for us?)
Once again, oVirt
should be aware of the host characteristics. This will
not only be the hardware but also the software running on the host. This
will enable oVirt to indicate to the user what is and what is not possible.
other notes -
* The UUIDs that are returned by Quantum will be managed by oVirt and
for a single network implemented in two different technologies in
quantum oVirt will be responsible to sync the different IDs.
This is not relevant
as oVirt will work with only one Quantum server -
that is, each logical network will have only one UUID.
* The integration should be as seamless as possible to the user of
oVirt
+1
* support of existing VLAN in quantum should be introduces in quantum
in
a 3-4 weeks time-frame
This is scheduled for Folsom-2
(https://launchpad.net/quantum/+milestone/folsom-2). I do not see any
blockers at the moment to prevent the start of integration.
Comments are welcomed, I'll schedule a follow up next week.
I will try and
prepare some diagrams that will maybe help us with the
next talk. I'll post these as soon as they are ready.
Thanks, Livnat
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:10 p.m.
----- Original Message -----
Hi,
Thanks for the time yesterday. Please see my inline comments.
Please feel free to contact me if you have any additional questions.
Thanks
Gary
On 06/06/2012 09:41 PM, Livnat Peer wrote:
> Hi All,
>
> This is a summary of the first quantum-oVirt integration meeting.
>
> In the meeting Garry Kotton started presenting his proposal for the
> integration, for more details on his proposal look in -
> http://www.ovirt.org/wiki/Quantum_and_oVirt
>
> We did not cover much of the wiki as some question arose:
>
> * What is the end goal of the integration? is it to replace the
> current
> network configuration implementation in oVirt by quantum or have
> them
> side by side.
I think that the first phase should enable them to work together.
That
is, the user can have host that run traditional VDSM networking and
host
that run a specific Quantum agent. In addition to this. I think that
the
user should also have the flexibility to choose which network
interfaces
run Quantum or traditional VDSM.
In short the answer is "side by side".
I think that quantum is just a
mean to an end and assuming it works properly it should be "an implementation
detail" completely transparent to the user so that all networks should be managed by
quantum only. If this is the case we should have a procedure to migrate all networking to
quantum during ovirt upgrade and thereafter use quantum solely.
To stress the point, it is an unnecessary added complexity for the user to be aware of
quantum.
> - we need to remember non-VM networks (like storage and
migration
> networks)
The crystallizes the point above, management and storage can continue
to
use the existing VDSM networking and the VM networks can start to use
Quantum.
On the same token I think we should aim for quantum to eventually own all
network configuration regardless of the purpose and usage of the logical network (e.g. VM
or non-VM).
> * Will oVirt use multiple quantum instances, one per technology,
or
> will
> oVirt use a single quantum instance that should support multiple
> plug-ins (not supported in Quantum ATM)
oVirt should use one Quantum instance. Today I will draw up a
blueprint
for Quantum to have a "Rosetta Plugin", that is a plugin that can
support a number of different networking technologies.
> * We'll oVirt support a mix of different technologies in a DC,
> Cluster,
> host?
I think that the only limitation should be to run one Quantum agent
per
host.
> - Can we assume homogeneous clusters for the sake of simplicity (in
> a
> single cluster we'll support either open Vswitch or UCSM or ..)
I do not think that we should go for a simple solution, but we should
strive for a proper solution. I see no reason to prevent or limit
this.
I feel that this would be a hard limitation for oVirt users. A
example
to show this limitation is the addition of a host to the existing
cluster that has new networking capabilities that are supported by a
different Quantum plugin.
oVirt must be aware of the capabilities of each host to indicate to
the
user that certain operations may not be possible, or may cause the
virtual machine to behave differently (performance degradation for
example), if they have decided to work in this manner - for example
live
live migration.
agree. Assuming we have the "Rosetta Plugin" it will
greatly simplify accomplishing the heterogeneous cluster approach.
> - Logical Network is defined in the scope of a data center,
that
> means
> we need to maintain layer 2 connectivity and within a cluster we
> need to
> guarantee VM live migration (does libvirt abstract it for us?)
Once again, oVirt should be aware of the host characteristics. This
will
not only be the hardware but also the software running on the host.
This
will enable oVirt to indicate to the user what is and what is not
possible.
>
> other notes -
>
> * The UUIDs that are returned by Quantum will be managed by oVirt
> and
> for a single network implemented in two different technologies in
> quantum oVirt will be responsible to sync the different IDs.
This is not relevant as oVirt will work with only one Quantum server
-
that is, each logical network will have only one UUID.
> * The integration should be as seamless as possible to the user of
> oVirt
+1
> * support of existing VLAN in quantum should be introduces in
> quantum in
> a 3-4 weeks time-frame
This is scheduled for Folsom-2
(https://launchpad.net/quantum/+milestone/folsom-2). I do not see any
blockers at the moment to prevent the start of integration.
>
>
> Comments are welcomed, I'll schedule a follow up next week.
I will try and prepare some diagrams that will maybe help us with the
next talk. I'll post these as soon as they are ready.
> Thanks, Livnat
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4550
days inactive
4551
days old
2 comments
3 participants
participants (3)
-
Gary Kotton -
Livnat Peer -
Roni Luxenberg