<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hi Livnat,<br>
<br>
Many thanks for your reply! Please see my inline comments.<br>
<br>
On 08/05/2012 01:06 AM, Livnat Peer wrote:
<blockquote cite="mid:501D5694.7090103@redhat.com" type="cite">
<pre wrap="">On 01/08/12 15:59, Mark Wu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Sorry for cross-posting!
I would like to inquiry about the roadmap of host network management in
oVirt in order to
make sure the ideas to be worked on are welcomed by community.
I did some initial investigation on the following topics. I am not very
familiar with them, so the information may contain some inaccuracies or
errors.
</pre>
</blockquote>
<pre wrap="">
Hi Mark,
My name is Livnat Peer, I'm focused on Networking in oVirt.
I am wondering if there is an interest for a monthly meeting on
networking in oVirt. I think we can discuss the current status in
networking features/bugs and the road map for future oVirt versions.</pre>
</blockquote>
Sure, I am glad to join. Thanks for your invitation. <br>
<blockquote cite="mid:501D5694.7090103@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">netcf:
It provides cross-platform network configuration library/tool by
converting the XML definition of an interface into local config file.
It's already used by libvirt to manage host network interfaces.It
supports all network entities including bridge, vlan, bond, nic. And it
also supports configuration rollback. The benefit for vdsm is making
host network stack configuration easy to port to other distros.
Problems found:
It doesn't restore interface live state during config transaction
now. There's a feature request submit for it.
There're some advanced settings not supported in netcf, like
'NM_CONTROLLED' and some less used bonding options.
It doesn't provide python binding officially. But we can use libvirt
API to integrate it into vdsm. It shouldn't have any impact on engine side.
</pre>
</blockquote>
<pre wrap="">
Making it easy to consume vdsm in other distros has great value for the
ovirt project, I don't see a reason why not to do that.
I think we should start with mapping the gaps of the functionality
currently used by vdsm and see what is missing for us to use netcf.</pre>
</blockquote>
I am going to implement a prototype for it. Probably, we can find
more what's missing in netcf during the prototype development.<br>
<blockquote cite="mid:501D5694.7090103@redhat.com" type="cite">
<pre wrap="">
I think there was a proposal to use Network Manager in Fedora that also
was supposed to work with netcf but I don't have more details on that,
danken - do you recall something more specific?
BTW - Can you please send the link to the feature request for netcf to
support restore?
</pre>
</blockquote>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Here's the feature request, and I have added you to the cc list :)<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=737149">https://bugzilla.redhat.com/show_bug.cgi?id=737149</a>
<blockquote cite="mid:501D5694.7090103@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
IEEE 802.1Qbg(VEPA)
It can offload network switching from server to external physical
switch. It makes all VMs' traffic visible to physical switch, and
therefore the existing switch functions (firewall, QoS etc) can be
applied to VM immediately. The offload also frees up the server resource
used by switching.
Now libvirt supports it by using macvtap as vif and working with
lldpad, which registers vif's mac/vlan information to the physical
switch. We can just add a 'virtualport' element to an interface XML
definition to add a VEPA interface. Probably, to support it in oVirt we
still need configure lldpad and query available VSI types for
virtualport profile.
</pre>
</blockquote>
<pre wrap="">
when discussing the modeling of 802.1Qbg we should also look into
802.1Qbh, the modeling of the two should have a lot in common.
We looked into modeling the above two in the past but did not get a
chance to actually work on it yet.
When adding support for a new technology in ovirt, especially in the
modeling phase I think it is important to understand how ovirt users are
going to use this technology and how the engine and vdsm together are
going to provide a complete solution for our users.
</pre>
</blockquote>
Make sense. We need collect more customer use case of them before
modelling it.<br>
<blockquote cite="mid:501D5694.7090103@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
quantum
Both the plugins openvswitch and linuxbridge stores abstract network
entities (network, port) in database and create bridge/vlan via the tool
ip/brctl or ovs-vsctl on demand. Only one bridge is created on one
server and one vlan is created for each virtual network. That means that
only one nic can be configured for vm network. It doesn't configure nic
or bond even if openvswitch also supports bond. Both of traditional
network stack configuration and quantum will be supported oVirt for
different purpose, right?
</pre>
</blockquote>
<pre wrap="">
We had some discussions on integration with Quntum which included a few
upstream calls to discuss the gaps we have in order to use quantum in
ovirt. We had Gary that is working on quantum in these sessions and the
link to the summary of our work so far was sent earlier on this thread.
Other than the above I maintain a wiki page with all the gaps we are
aware of for networking in Ovirt -
<a class="moz-txt-link-freetext" href="http://wiki.ovirt.org/wiki/Networking">http://wiki.ovirt.org/wiki/Networking</a>
There you can see that there was a proposal to use Network-Manager in VDSM.
I see that Fabian split the page to features and technologies, thanks
Fabian :)
Livnat
</pre>
</blockquote>
<blockquote cite="mid:501D5694.7090103@redhat.com" type="cite">
<blockquote type="cite">
<pre wrap=""> Any comments? Thanks!
_______________________________________________
Arch mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Arch@ovirt.org">Arch@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/arch">http://lists.ovirt.org/mailman/listinfo/arch</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>