On 12/09/12 12:51, Alon Bar-Lev wrote:
----- Original Message -----
From: "David Jaša" <djasa@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, September 11, 2012 2:47:56 PM Subject: Re: [Engine-devel] network subnet
Livnat Peer píše v Út 11. 09. 2012 v 09:21 +0300:
On 30/08/12 23:11, Alon Bar-Lev wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, August 30, 2012 10:16:05 PM Subject: Re: [Engine-devel] network subnet
On 30/08/12 21:39, Alon Bar-Lev wrote:
----- Original Message ----- > From: "Livnat Peer" <lpeer@redhat.com> > To: engine-devel@ovirt.org > Sent: Thursday, August 30, 2012 3:22:29 PM > Subject: [Engine-devel] network subnet > > Hi All, > > Today when a user wants to define a network subnet mask, he > does > it > when > he attaches the network to a host NIC. > > I was wondering if there is a reason not to define the network > subnet > on > the logical network entity (Data center level). > > Thanks, Livnat
Hello,
I am sorry, maybe I do not understand... the IP scheme enforces the use of address mask in order to properly route packets.
of course. My proposal is related to our user usage of the system. Today ovirt user, who wants to define a network subnet, has to type the subnet per host (per network), I think the user should only define it once on the logical network entity in the Data Center. Propagating the value to all hosts is needed but it should be our internal implementation detail.
Network mask is used in any case, I guess it can be dropped from configuration in favour of using the address class as mask, is that what you suggest?
No, hope the above paragraph made it more clear.
Hello,
Then you assume that a logical network, which is actually layer 2 network in our implementation, has layer 3 characteristics, right?
In our current implementation "data center logical network" is pure layer 2 segment aka layer 2 broadcast domain.
One can use the same logical network for multiple layer 3 segments, which is totally valid and consistent with standard physical layer 2 setup.
Unless I am missing something crucial, I would suggest to keep the consistent physical->virtual mapping, unless we emulate layer 3 switching. Layer 2 does not have layer 3 characteristics.
Regards, Alon.
Generally I agree with what you wrote.
I would like to open for discussion the definition mentioned above that a logical network is a layer 2 broadcast domain.
We have 2 types of logical networks, VM networks and 'other' (host functionality?) networks.
When talking about VM networks, I think the definition above is accurate, the guests using the network should get a layer 2 broadcast domain. It can be implemented over a single (physical) layer 2 domain or it can be implemented over multiple (physical) layer 2 domains using technologies like tunneling or vxlan.
When talking about other networks like storage, display, migration, etc. we are actually discussing a network which represent a common functionality the hosts are using but I am not sure guaranteeing a layer 2 broadcast domain is interesting for such network.
IMHO the requirements for the "logical networks" could be differentiated depending on their function: * management: engine must reach each host on L3 * storage: each host can reach the storage on L3 (FCP or IP) * VM network: all VNICs in one are in L2 broadcast domain by default * migration: mutual reachability of hosts on L3 * display: reachability on from clients that in turn could make
Note that engine or hosts can not really test if display network is working in conditions like split-horizon DNS.
David
Going forward I expect we'll associate layer 3 services with logical networks. For example DHCP, DNS, LB etc.
Any thoughts/comments on the above are welcomed.
I agree that we should distinguish between terms.
"Layer 2 Segment" which is what you connect "Network Element" to.
Now I understand the we have "XXX Group", I guess this is what you refer as "Storage Network" for example?
Most of these groups only need network reachability so the term "Network" in this sense is somewhat confusing.
But I may got this wrong.
You got it exactly right, I'm not sure we should create a network for such groups. Anyway it is just a set of initial thoughts, I need to build a more formal proposal what to do with this and I'll send it to the list. Thanks for your inputs. Livnat
Alon. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel