----- Original Message ----- > From: "David Jaša" <dj...@redhat.com> > To: vdsm-de...@fedorahosted.org, a...@ovirt.org > Sent: Monday, February 18, 2013 11:23:21 AM > Subject: Re: [vdsm] vdsm networking changes proposal > > Hi, > > Alon Bar-Lev píše v Ne 17. 02. 2013 v 15:57 -0500: > > Hello Antoni, > > > > Great work! > > I am very excited we are going this route, it is first of many to > > allow us to be run on different distributions. > > I apologize I got to this so late. > > > > Notes for the model, I am unsure if someone already noted. > > > > I think that the abstraction should be more than entity and > > properties. > > > > For example: > > > > nic is a network interface > > bridge is a network interface and ports network interfaces > > bound is a network interface and slave network interfaces > > vlan is a network interface and vlan id > > > > network interface can have: > > - name > > - ip config > > - state > > - mtu > > > > this way it would be easier to share common code that handle pure > > interfaces. > > > > I don't quite understand the 'Team' configurator, are you > > suggesting a provider for each technology? > > Team is a new implementation of bonding in Linux kernel IIRC. > > > > > bridge > > - iproute2 provider > > - ovs provider > > - ifcfg provider > > > > bond > > - iproute2 > > - team > > - ovs > > - ifcfg > > > > vlan > > - iproute2 > > - ovs > > - ifcfg > > > > So we can get a configuration of: > > bridge:iproute2 > > bond:team > > vlan:ovs > > > > ? > > > > I also would like us to explore a future alternative of the network > > configuration via crypto vpn directly from qemu to another qemu, > > the idea is to have a kerberos like key per layer3(or layer2) > > destination, while communication is encrypted at user space and > > sent to a flat network. The advantage of this is that we manage > > logical network and not physical network, while relaying on > > hardware to find the best route to destination. The question is > > how and if we can provide this via the suggestion abstraction. But > > maybe it is too soon to address this kind of future. > > Isn't it better to separate the two goals and persuade qemu > developers to implement TLS for migration connections?
Sure :) But someone/something will need to configure it... :) > > > > > For the open questions: > > > > 1. Yes, I think that mode should be non-persistence, persistence > > providers should emulate non-persistence operations by diff > > between what they have and the goal. > > > > 2. Once vdsm is installed, the mode it runs should be fixed. So the > > only question is what is the selected profile during host > > deployment. > > > > 3. I think that if we can avoid aliases it would be nice. > > > > 4. Keeping the least persistence information would be flexible. I > > would love to see a zero persistence mode available, for example > > if management interface is dhcp or manually configured. > > > > I am very fond of the iproute2 configuration, and don't mind if > > administrator configures the management interface manually. I > > think this can supersede the ifcfg quite easily in most cases. In > > these rare cases administrator use ovirt to modify the network > > interface we may consider delegating persistence to totally > > different model. But as far as I understand the problem is solely > > related to the management connectivity, so we can implement a > > simple bootstrap of non-persistence module to reconstruct the > > management network setup from vdsm configuration instead of > > persisting it to the distribution width configuration. > > > > Regards, > > Alon Bar-Lev > > > > ----- Original Message ----- > > > From: "Antoni Segura Puimedon" <asegu...@redhat.com> > > > To: a...@ovirt.org, vdsm-de...@fedorahosted.org > > > Sent: Friday, February 8, 2013 12:54:23 AM > > > Subject: vdsm networking changes proposal > > > > > > Hi fellow oVirters! > > > > > > The network team and a few others have toyed in the past with > > > several > > > important > > > changes like using open vSwitch, talking D-BUS to NM, making the > > > network > > > non-persistent, etc. > > > > > > It is with some of this changes in mind that we (special thanks > > > go to > > > Livnat > > > Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal > > > for > > > a new architecture for vdsm's networking part. This proposal is > > > intended to > > > make our software more adaptable to new components and use cases, > > > eliminate > > > distro dependancies as much as possible and improve the > > > responsiveness and > > > scalability of the networking operations. > > > > > > To do so, it proposes an object oriented representation of the > > > different > > > elements that come into play in our networking use cases. > > > > > > But enough of introduction, please go to the feature page that we > > > have put > > > together and help us with your feedback, questions proposals and > > > extensions. > > > > > > http://www.ovirt.org/Feature/NetworkReloaded > > > > > > > > > Best regards, > > > > > > Toni > > > _______________________________________________ > > > Arch mailing list > > > a...@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/arch > > > > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel@lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > -- > > David Jaša, RHCE > > SPICE QE based in Brno > GPG Key: 22C33E24 > Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel