Hi Suresh, Actually we are warning the user about a possible failure when creating bridged VLAN with NM enabled. The reason is that NM doesn't support such scenario. I don't think Kimchi tries to stop users from using other tools but, IMHO, it's a good approach to let them know when such tools don't work as expected under determined circumstances. Best regards! On 01-09-2015 03:02, Suresh Babu Angadi wrote: -- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM

Daniel, Ricardo I get your point. Network Manager does not support full features and not present in older versions before Fedora 20. It will be keep on updating to support more and more use cases. Just adding here few point from fedora link. Detailed description NetworkManager's existing support for bond interfaces covers a limited number of use-cases and can conflict with existing bonding configurations created by tools like libvirt. The purpose of this Fedora feature is to implement more flexible bonding infrastructure in NetworkManager to support an expanded number of use-cases and to be more cooperative with other users of bonding. Support will be added to NetworkManager to detect the existing configuration of a bond interface and its slaves and to seamless "take over" that connection without disrupting it. Even if the existing configuration is not backed by ifcfg files on-disk, NetworkManager will leave that configuration on the interface unless told to change it by the user via GUI or CLI tools. Additional bond interface configuration will be added to expand the use-cases and hardware that NetworkManager can configure (eg primary, use_carrier, xmit_hash_policy, etc). Given that libvirt is the way we proceed for network management in guest. My question here adding to Suresh is do we need to really warn the user about other tools like Network Manager? Tomorrow there can be other tools like cockpit , x , y which do the same task may not be completely. Then in that case we keep updating our warning? I feel we should restrict ourselves to kimchi/ginger and make sure the network management functionality we are implementing are in sync and do not disturb other tools. We should keep reading the configurations as long as they are standard irrespective of which tool is used for configuring. If we have write permissions we can very well modify those interfaces. If configurations are not valid we ignore them. ======================================================= Thanks, Abhiram Kulkarni, Staff Software Engineer, Z Firmware Development, IBM India Systems & Technology Lab, Bangalore, India. Phone: +91 80 28063288 “Be who you are and say what you feel, because those who mind don't matter, and those who matter don't mind.” ======================================================= From: Daniel Henrique Barboza <dhbarboza82(a)gmail.com&gt; To: kimchi-devel(a)ovirt.org Date: 09/01/2015 06:39 PM Subject: Re: [Kimchi-devel] [RFC] Issue #650 - Kimchi & Network Manager Sent by: kimchi-devel-bounces(a)ovirt.org On 09/01/2015 03:02 AM, Suresh Babu Angadi wrote: No. We are advising the user to exercise caution with NetworkManager in these scenarios. It is a known fact that NetworkManager started support native bridge and bonding only in F20*. This Kimchi feature must be supported on older distros such as RHEL 7.1 that has older NetworkManager versions that doesn't have this native support. This is why we have this warning. The user can proceed with the operation with NetworkManager on, but he's on his own. * https://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/sect-Re... _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel