Re: [openstack-dev] How to get VXLAN Endpoint IP without agent
Though we can configure in Nova.conf file, but we have to make sure these tunnel interface ipaddress of every compute node and nova.conf will have the same configuration. But it is still painful to make sure that the ipaddress are configured properly. We want to come up with BP to avoid these manual configuration and as the interfaces are configured through DHCP server, Compute Node tunnel ipaddress will be stored in Neutron and retrieved. If anyone has deployed VXLAN setup with Neutron, Please share your experience on VXLAN “Local-IP” configuration of Compute Node. Regards, Balaji.P From: Ravi Chunduru [mailto:ravi...@gmail.com] Sent: Thursday, October 17, 2013 12:41 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] How to get VXLAN Endpoint IP without agent I guess the intention is to make VXLAN work with out quantum agent. It means you are using an external openflow controller to manage OVS switches. In such a case, there is a need to specifically get the compute node IP from the VM data interface network( and not the management or openstack network interface IP) I think of two solutions 1) There must be a onboarding process for each compute node that can indicate your controller of the compute's local_ip 2) Make sure OVS uses VM data interface network to connect to the controller. I don't prefer 2, as OVS mgmt traffic should not be on VM data network. For solution#1, its a pain to load compute local IP onto openflow controller but it can be automated using puppet etc., (I have verified nova database for compute - but it stores management network interface IP but not from data network- Makes sense as endpoints are on management network) Alternately, we can propose a blueprint to include an option in nova.conf on compute for local_ip as there is a need for consumption using VXLAN based overlay networks. Hope it helps. Thanks, -Ravi. On Tue, Oct 15, 2013 at 3:45 AM, B Veera-B37207 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, Vxlan endpoint ip is configured in ‘/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini’ as ‘local_ip’ While starting openvswitch agent the above local ip is populated in neutron database. Is there any way to get local_ip of compute node without any agent running? Thanks in advance. Regards, Veera. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Merge multiple OVS bridges ?
Are the below observations on Havana? From: Gopi Krishna B [mailto:gopi97...@gmail.com] Sent: Tuesday, October 22, 2013 12:52 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Merge multiple OVS bridges ? Hi Currently in Neutron the integration bridge (br-int) and other bridges configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being configured in Compute and Network nodes. What is the logic behind or advantages having 2 OVS bridges in the physical host? Can we have only one bridge for each physical NIC, similar to what linux bridge setup has. And configure/modify the flows such that VLAN conversion is appropriately setup for ingress and egress traffic within the single bridge. Thus also eliminating the veth pairs used to connect the bridges together. Is this a feasible proposal, and can it be worked on? -- Regards Gopi Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Distributed Virtual Router Discussion
+1 I would like to contribute for this BP. Regards, Balaji.P -Original Message- From: openst...@cdl.asgaard.org [mailto:openst...@cdl.asgaard.org] Sent: Wednesday, October 23, 2013 9:47 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Distributed Virtual Router Discussion On 22 Oct 2013, at 18:02, Brian Haley wrote: Hi Swami, I would like to participate as well. -Brian +1 On 10/21/2013 12:18 PM, Vasudevan, Swaminathan (PNB Roseville) wrote: Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.com mailto:swaminathan.vasude...@hp.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 李柯睿 Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc Current vCard here: http://www.asgaard.org/cdl/cdl.vcf ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports
Hi Kyle, This observation is with OVS Plugin. Regards, Balaji.P -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Friday, October 11, 2013 4:14 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports On Oct 8, 2013, at 4:01 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, Current OVS Agent is creating tunnel with dst_port as the port configured in INI file on Compute Node. If all the compute nodes on VXLAN network are configured for DEFAULT port it is fine. When any of the Compute Nodes are configured for CUSTOM udp port as VXLAN UDP Port, Then how does the tunnel will be established with remote IP. It is observed that the fan-out RPC message is not having the destination port information. Balaji, is this with the ML2 or OVS plugin? Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports
Hi Rohon, Thanks for confirmation. We will file a bug on this. Regards, Balaji.P -Original Message- From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com] Sent: Thursday, October 10, 2013 6:43 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports hi, good point Balaji, the dst_port is the port on which ovs is listening for vxlan packets, but I don't know what is the option in ovs-vsctl to set the remote port of the vxlan unicast tunnel interface. But it looks like a bug since you're right, tunnel_sync and tunnel_update RPC messages should handle the VXLAN udp port, additionnaly to the vxlan remote ip. Kyle is away for the moment, he should know the good option to set in ovs-vsctl to specify a remote port for a vxlan tunnel. But you should fill a bug for that, to track this issue. Thanks for playing with vxlan, and helping us to debug it! On Wed, Oct 9, 2013 at 6:55 AM, P Balaji-B37839 b37...@freescale.com wrote: Any comments on the below from community using OVS will be helpful. Regards, Balaji.P -Original Message- From: P Balaji-B37839 Sent: Tuesday, October 08, 2013 2:31 PM To: OpenStack Development Mailing List; Addepalli Srini-B22160 Subject: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports Hi, Current OVS Agent is creating tunnel with dst_port as the port configured in INI file on Compute Node. If all the compute nodes on VXLAN network are configured for DEFAULT port it is fine. When any of the Compute Nodes are configured for CUSTOM udp port as VXLAN UDP Port, Then how does the tunnel will be established with remote IP. It is observed that the fan-out RPC message is not having the destination port information. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports
Any comments on the below from community using OVS will be helpful. Regards, Balaji.P -Original Message- From: P Balaji-B37839 Sent: Tuesday, October 08, 2013 2:31 PM To: OpenStack Development Mailing List; Addepalli Srini-B22160 Subject: [openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports Hi, Current OVS Agent is creating tunnel with dst_port as the port configured in INI file on Compute Node. If all the compute nodes on VXLAN network are configured for DEFAULT port it is fine. When any of the Compute Nodes are configured for CUSTOM udp port as VXLAN UDP Port, Then how does the tunnel will be established with remote IP. It is observed that the fan-out RPC message is not having the destination port information. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] OVS Agent and VxLan UDP Ports
Hi, Current OVS Agent is creating tunnel with dst_port as the port configured in INI file on Compute Node. If all the compute nodes on VXLAN network are configured for DEFAULT port it is fine. When any of the Compute Nodes are configured for CUSTOM udp port as VXLAN UDP Port, Then how does the tunnel will be established with remote IP. It is observed that the fan-out RPC message is not having the destination port information. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Daniel, Thanks for comments and examples. As you already know that for any application running on Host platform can communicate with Guest through Virtio-Serial device. What we are looking at is the security provided by Apparmor is crucial so that the Host will not allow any software running in Guest can access outside of the directories/files dynamically added in the libvirt-qemue configuration file of apparmor. As this file is created dynamically from Libvirt XML file, We are thinking that if we can expose Virtio-serial device of Guest through Dashboard [Horizon], Then it will be good from host security perspective and as well it is upto the User to enable virtio-serial interface based on his requirements like Application software requirement in Guest. Appreciate your comments or suggestions on this. Regards, Balaji.P -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Thursday, September 26, 2013 1:41 PM To: P Balaji-B37839 Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver On Thu, Sep 26, 2013 at 03:05:16AM +, P Balaji-B37839 wrote: Hi Ravi, We did this as part of PoC few months back. Daniel can give us more comments on this as he is the lead for Libvirt support in Nova. Just adding the ability to expose virtio-serial devices to the guest doesn't do much. You need to have a credible story for what connects and deals with the host side of the device in Nova. For the QEMU guest agent, libvirt will own the host side and use it for various APIs it supports. For the SPICE agent, QEMU owns the host side and uses it to support functionality used by the SPICE client. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
On Mon, Sep 30, 2013 at 08:32:51AM +, P Balaji-B37839 wrote: Hi Daniel, Thanks for comments and examples. As you already know that for any application running on Host platform can communicate with Guest through Virtio-Serial device. What we are looking at is the security provided by Apparmor is crucial so that the Host will not allow any software running in Guest can access outside of the directories/files dynamically added in the libvirt-qemue configuration file of apparmor. As this file is created dynamically from Libvirt XML file, We are thinking that if we can expose Virtio-serial device of Guest through Dashboard [Horizon], Then it will be good from host security perspective and as well it is upto the User to enable virtio-serial interface based on his requirements like Application software requirement in Guest. This doesn't really answer my question. There are 2 commonly available agents (SPICE agent + QEMU guest agent) in the KVM world and we have support for those in Nova at least. There may be UI missing in Horizon to enable though. Any further agents would require some kind of software integration on the host with either qemu, libvirt or Nova itself. So any blueprint should specify what that new agent is, and how it will be integrated in the Nova compute host. [P Balaji-B37839] Correct. Nova has support for the commonly available agents as listed above. We are thinking about generic interface which can be used by any application software in Guest. More precisely, it will be like there won't be any agent in VM, Instead any Application Software can use this generic Virtio-Serial Interface to make use of communicating with Host. Using libvirt frame work might be best option, so that security aspects of exposing this interface can be taken care. Please comment. Regards, Balaji.P Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Daniel, Thanks for comments and examples. As you already know that for any application running on Host platform can communicate with Guest through Virtio-Serial device. What we are looking at is the security provided by Apparmor is crucial so that the Host will not allow any software running in Guest can access outside of the directories/files dynamically added in the libvirt-qemue configuration file of apparmor. As this file is created dynamically from Libvirt XML file, We are thinking that if we can expose Virtio-serial device of Guest through Dashboard [Horizon], Then it will be good from host security perspective and as well it is upto the User to enable virtio-serial interface based on his requirements like Application software requirement in Guest. This doesn't really answer my question. There are 2 commonly available agents (SPICE agent + QEMU guest agent) in the KVM world and we have support for those in Nova at least. There may be UI missing in Horizon to enable though. Any further agents would require some kind of software integration on the host with either qemu, libvirt or Nova itself. So any blueprint should specify what that new agent is, and how it will be integrated in the Nova compute host. [P Balaji-B37839] Correct. Nova has support for the commonly available agents as listed above. We are thinking about generic interface which can be used by any application software in Guest. More precisely, it will be like there won't be any agent in VM, Instead any Application Software can use this generic Virtio-Serial Interface to make use of communicating with Host. Using libvirt frame work might be best option, so that security aspects of exposing this interface can be taken care. Please fix your email client so that it properly indents text you are quoting with ' '. It makes it very hard to follow replies as your do it now. Communicating with *what* on the host ? [P Balaji-B37839] Here *what* refers to any daemon/agent which is proprietary based on the Application architecture inside Guest using the Virtio-Serial Interface created for VM. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt- manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk- vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Daniel, Not sure that I conveyed the use case of this in Nova clearly. Please find the below as few more data points on this. i) Host to Guest Communication feature is good to have through Nova-Libvirt. Using generic Virtio-Serial Interface for this will be a better option because the dynamic apparmor abstractions file created for libvirt-qemu will take care of security aspects of Host. ii) KVM Hypervisor using Libvirt needs VMCI [VMWare] kind of library which can support secure way of host-guest communication. Though this kind of library support in Libvirt is not available now, Using the existing Virtio-Serial Interface will be good to start with. iii) We want to make KVM hypervisor with Libvirt more flexible enough so that different Networking Vendors can make use of it based on their Network Application Software Architecture. iv)Though we can make use of Guest Agent, But it will add another daemon in Guest which is not optimal. Regards, Balaji.P -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Monday, September 30, 2013 5:21 PM To: P Balaji-B37839 Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver On Mon, Sep 30, 2013 at 11:31:58AM +, P Balaji-B37839 wrote: Hi Daniel, Thanks for comments and examples. As you already know that for any application running on Host platform can communicate with Guest through Virtio-Serial device. What we are looking at is the security provided by Apparmor is crucial so that the Host will not allow any software running in Guest can access outside of the directories/files dynamically added in the libvirt-qemue configuration file of apparmor. As this file is created dynamically from Libvirt XML file, We are thinking that if we can expose Virtio-serial device of Guest through Dashboard [Horizon], Then it will be good from host security perspective and as well it is upto the User to enable virtio-serial interface based on his requirements like Application software requirement in Guest. This doesn't really answer my question. There are 2 commonly available agents (SPICE agent + QEMU guest agent) in the KVM world and we have support for those in Nova at least. There may be UI missing in Horizon to enable though. Any further agents would require some kind of software integration on the host with either qemu, libvirt or Nova itself. So any blueprint should specify what that new agent is, and how it will be integrated in the Nova compute host. [P Balaji-B37839] Correct. Nova has support for the commonly available agents as listed above. We are thinking about generic interface which can be used by any application software in Guest. More precisely, it will be like there won't be any agent in VM, Instead any Application Software can use this generic Virtio-Serial Interface to make use of communicating with Host. Using libvirt frame work might be best option, so that security aspects of exposing this interface can be taken care. Please fix your email client so that it properly indents text you are quoting with ' '. It makes it very hard to follow replies as your do it now. Communicating with *what* on the host ? [P Balaji-B37839] Here *what* refers to any daemon/agent which is proprietary based on the Application architecture inside Guest using the Virtio-Serial Interface created for VM. I'm not convinced that we should be in the business of adding features to Nova for integration with arbitrary, closed source host components which we have no information about. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt- manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk- vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Ravi, Thanks for giving reference examples. Though I tried to give very generic use case without referring to Networking use cases. It is good that you referred to examples so that the community can understand the need for it. Regards, Balaji.P From: Ravi Chunduru [mailto:ravi...@gmail.com] Sent: Monday, September 30, 2013 10:16 PM To: OpenStack Development Mailing List; Palanisamy, Anand Cc: Sean Dague Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver Let me present an use case. Today Nova enables to launch guests of different types. For real deployments we would need appliances from various vendors to run as instances. Appliances can be Loadbalancer, Firewall, IPsec, Routers or UTM etc., These appliances can be tied up with Neutron Services and would need configuration from various services like FWaaS, LBaaS, VPNaaS etc., One way to configure these appliances from Neutron Agents is by opening up the so needed virtio unix channel socket and reach the configuration daemon in the appliance. Other approach is by having a separate network for management activities and having agent to communicate to a daemon in netns to reach out to appliance. For us, it means additional daemon in the second approach. In case of first approach it is similar to Vmware way of configuring appliance. Check this for reference http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1010806 Please look from Network appliance perspective to enable this featue. I welcome if you can suggest us if spicevm or generic qemu guest agent can help. If so, how the adaptability with vendors can be solved. Let me know if you need more information. Thanks, -Ravi. On Mon, Sep 30, 2013 at 8:05 AM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 09/30/2013 07:57 AM, Sean Dague wrote: On 09/30/2013 07:51 AM, Daniel P. Berrange wrote: snip I'm not convinced that we should be in the business of adding features to Nova for integration with arbitrary, closed source host components which we have no information about. +1 +2 -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Ravi and Daniel, Good that we all converged on the need for this support in Nova Libvirt Driver. We will collaborate together on this blueprint and make it upstream for IceHouse. Regards, Balaji.P -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Monday, September 30, 2013 11:52 PM To: OpenStack Development Mailing List Cc: Sean Dague Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver On Mon, Sep 30, 2013 at 09:46:02AM -0700, Ravi Chunduru wrote: Let me present an use case. Today Nova enables to launch guests of different types. For real deployments we would need appliances from various vendors to run as instances. Appliances can be Loadbalancer, Firewall, IPsec, Routers or UTM etc., These appliances can be tied up with Neutron Services and would need configuration from various services like FWaaS, LBaaS, VPNaaS etc., One way to configure these appliances from Neutron Agents is by opening up the so needed virtio unix channel socket and reach the configuration daemon in the appliance. Other approach is by having a separate network for management activities and having agent to communicate to a daemon in netns to reach out to appliance. Thanks, this is the kind of usage information I was asking for, wrt host integration. This shows the use case for virtio-serial is as a mechanism for integration between infrastructure pieces controlled by the cloud admin, not as something that is targetted towards end users of the cloud. I think we need to have a detailed blueprint for this, describing the use case(s) to be addressed and proposing some possible design(s). Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt- manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk- vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][libvirt] Virtio-Serial support for Nova libvirt driver
Hi, If anyone is already working on the below support for Nova, Please let us know. Regards, Balaji.P -Original Message- From: P Balaji-B37839 Sent: Tuesday, September 24, 2013 4:10 PM To: openstack-dev@lists.openstack.org Cc: Addepalli Srini-B22160; Mannidi Purandhar Sairam-B39209; Lingala Srikanth Kumar-B37208; Somanchi Trinath-B39208; B Veera-B37207 Subject: [openstack-dev][Nova] Virtio-Serial support for Nova libvirt driver Hi, Virtio-Serial interface support for Nova - Libvirt is not available now. Some VMs who wants to access the Host may need like running qemu-guest-agent or any proprietary software want to use this mode of communication with Host. Qemu-GA uses virtio-serial communication. We want to propose a blue-print on this for IceHouse Release. Anybody interested on this. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Wangpan, Thanks for Information and suggestions. We want to have generic virtio-serial interface for Libvirt and applications can use this irrespective of Qemu Guest Agent in VM. As suggested, Daniel can throw some light on this and help us. Regards, Balaji.P From: Wangpan [mailto:hzwang...@corp.netease.com] Sent: Wednesday, September 25, 2013 3:24 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver Hi all, I'm the owner of this bp https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support and Daniel Berrange gave me lots of help about implementing this bp, and the original idea of mine is the same as yours. So I think the opinion of Daniel will be very useful. 2013-09-25 Wangpan 发件人：balaji patnala patnala...@gmail.com 发送时间：2013-09-25 22:36 主题：Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver 收件人：OpenStack Development Mailing Listopenstack-dev@lists.openstack.org 抄送： Hi Haomai, Thanks for your interest on this. The code check-ins done against the below bp are more specific to Qemu Guest Agent. https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support Our requirement is to enable Virtio-Serial Interface to the applications running in VM. Do you have the same requirement? We will share the draft BP on this. Any comments on this approach will be helpful. Regards, Balaji.P On Tue, Sep 24, 2013 at 8:10 PM, Haomai Wang hao...@unitedstack.commailto:hao...@unitedstack.com wrote: On Sep 24, 2013, at 6:40 PM, P Balaji-B37839 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, Virtio-Serial interface support for Nova - Libvirt is not available now. Some VMs who wants to access the Host may need like running qemu-guest-agent or any proprietary software want to use this mode of communication with Host. Qemu-GA uses virtio-serial communication. We want to propose a blue-print on this for IceHouse Release. Anybody interested on this. Great! We have common interest and I hope we can promote it for IceHouse. BTW, do you have a initial plan or description about it. And I think this bp may invoke. https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Best regards, Haomai Wang, UnitedStack Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver
Hi Ravi, We did this as part of PoC few months back. Daniel can give us more comments on this as he is the lead for Libvirt support in Nova. Regards, Balaji.P From: Ravi Chunduru [mailto:ravi...@gmail.com] Sent: Thursday, September 26, 2013 12:35 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver I got this working after I made guest to behave as serial device and host side program as unix socket based client. Now all set to collaborate the BP with the use case. Thanks, -Ravi. On Wed, Sep 25, 2013 at 8:09 AM, Ravi Chunduru ravi...@gmail.commailto:ravi...@gmail.com wrote: I am working on this generic virtio-serial interface for appliances. To start with I experimented on existing Wangpan's added feature on hw_qemu_guest agent. I am preparing to propose a blueprint to modify it for generic use and open to collaborate. I could bring up VM with generic source path(say /tmp/appliance_port) and target name(appliance_port). But I see qemu listening on the unix socket in host as soon as I start the VM. If we want to have our server program on host listening, that should not happen. How do I overcome that? Thanks, -Ravi. On Wed, Sep 25, 2013 at 3:01 AM, P Balaji-B37839 b37...@freescale.commailto:b37...@freescale.com wrote: Hi Wangpan, Thanks for Information and suggestions. We want to have generic virtio-serial interface for Libvirt and applications can use this irrespective of Qemu Guest Agent in VM. As suggested, Daniel can throw some light on this and help us. Regards, Balaji.P From: Wangpan [mailto:hzwang...@corp.netease.commailto:hzwang...@corp.netease.com] Sent: Wednesday, September 25, 2013 3:24 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver Hi all, I'm the owner of this bp https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support and Daniel Berrange gave me lots of help about implementing this bp, and the original idea of mine is the same as yours. So I think the opinion of Daniel will be very useful. 2013-09-25 Wangpan 发件人：balaji patnala patnala...@gmail.commailto:patnala...@gmail.com 发送时间：2013-09-25 22tel:2013-09-25%C2%A022:36 主题：Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver 收件人：OpenStack Development Mailing Listopenstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 抄送： Hi Haomai, Thanks for your interest on this. The code check-ins done against the below bp are more specific to Qemu Guest Agent. https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support Our requirement is to enable Virtio-Serial Interface to the applications running in VM. Do you have the same requirement? We will share the draft BP on this. Any comments on this approach will be helpful. Regards, Balaji.P On Tue, Sep 24, 2013 at 8:10 PM, Haomai Wang hao...@unitedstack.commailto:hao...@unitedstack.com wrote: On Sep 24, 2013, at 6:40 PM, P Balaji-B37839 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, Virtio-Serial interface support for Nova - Libvirt is not available now. Some VMs who wants to access the Host may need like running qemu-guest-agent or any proprietary software want to use this mode of communication with Host. Qemu-GA uses virtio-serial communication. We want to propose a blue-print on this for IceHouse Release. Anybody interested on this. Great! We have common interest and I hope we can promote it for IceHouse. BTW, do you have a initial plan or description about it. And I think this bp may invoke. https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Best regards, Haomai Wang, UnitedStack Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Virtio-Serial support for Nova libvirt driver
Hi, Virtio-Serial interface support for Nova - Libvirt is not available now. Some VMs who wants to access the Host may need like running qemu-guest-agent or any proprietary software want to use this mode of communication with Host. Qemu-GA uses virtio-serial communication. We want to propose a blue-print on this for IceHouse Release. Anybody interested on this. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] New Plug-in development for Neutron
Thanks for Suggestions and Support on this. Regards, Balaji.P -Original Message- From: Alan Kavanagh [mailto:alan.kavan...@ericsson.com] Sent: Wednesday, September 11, 2013 1:48 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron +1 This is the best approach and one we discussed in Portland and a track most folks are developing plugins under ML2 /Alan -Original Message- From: Robert Kukura [mailto:rkuk...@redhat.com] Sent: September-10-13 12:27 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] New Plug-in development for Neutron On 09/10/2013 10:45 AM, Mark McClain wrote: I think Gary and Kyle have answered this very well; however I do have a few things to add. It is definitely too late for Havana, so Icehouse is next available release for new plugins. I can work with you offline to find you a core sponsor. One more thing: Rather than implementing and maintaining an entire new plugin, consider whether it might make sense to integrate as an ml2 MechanismDriver instead. The ml2 plugin's MechanismDrivers can interface with network devices or controllers, and can work in conjunction with the existing L2 agents if needed. See https://wiki.openstack.org/wiki/Neutron/ML2 for more info. -Bob mark On Sep 10, 2013, at 9:37 AM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: On Sep 10, 2013, at 4:05 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, We have gone through the below link for new plug-in development. https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neut ron_Plugin Just want to confirm that is it mandatory to be Core Neutron Developer for submitting a new plug-in.? It's not necessary for you to have a core developer from your company, but you will need an existing core developer to support your plugin upstream. When you file the blueprint, let us know and we'll work with you on this one Balaji. Thanks, Kyle How do we get a reviewer for this like Can we approach any Core Neutron developer for review our plugin? We are developing new plug-in for our product and want to make it upstream to Neutron Core. Any information on this will be helpful!. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] New Plug-in development for Neutron
Hi, We have gone through the below link for new plug-in development. https://wiki.openstack.org/wiki/NeutronDevelopment#Developing_a_Neutron_Plugin Just want to confirm that is it mandatory to be Core Neutron Developer for submitting a new plug-in.? How do we get a reviewer for this like Can we approach any Core Neutron developer for review our plugin? We are developing new plug-in for our product and want to make it upstream to Neutron Core. Any information on this will be helpful!. Regards, Balaji.P ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Resource URL support for more than two levels
Hi Mark, Do you suggest us to pause on this BP. Let us know if someone is already working on this. Regards, Balaji.P From: Mark McClain [mailto:mark.mccl...@dreamhost.com] Sent: Friday, August 30, 2013 5:41 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels Stay tuned. There are folks working on a proposed set of API framework changes. This will be something that we'll discuss as part of deciding the features in the Icehouse release. mark On Aug 29, 2013, at 10:08 AM, Justin Hammond justin.hamm...@rackspace.commailto:justin.hamm...@rackspace.com wrote: I find that kind of flexibility quite valuable for plugin developers. +1 to this. I'd like to be involved if possible with helping you with it. From: balaji patnala patnala...@gmail.commailto:patnala...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thu, 29 Aug 2013 11:02:33 +0530 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels Hi, When compared to Nova URL implementations, It is observed that the Neutron URL support cannot be used for more than TWO levels. Applications which want to add as PLUG-IN may be restricted with this. We want to add support for changes required for supporting more than TWO Levels of URL by adding the support changes required in Core Neutron Files. Any comments/interest in this.? Regards, Balaji.P On Tue, Aug 27, 2013 at 5:04 PM, B Veera-B37207 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, The current infrastructure provided in Quantum [Grizzly], while building Quantum API resource URL using the base function 'base.create_resource()' and RESOURCE_ATTRIBUTE_MAP/SUB_RESOURCE_ATTRIBUTE_MAP, supports only two level URI. Example: GET /lb/pools/pool_id/members/member_id Some applications may need more than two levels of URL support. Example: GET /lb/pools/pool_id/members/member_id/xyz/xyz_id If anybody is interested in this, we want to contribute for this as BP and make it upstream. Regards, Veera. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Resource URL support for more than two levels
Thanks Justin. Sure, we will take your help as it is required on this. We will prepare blue-print capturing all the details and will assign you as reviewer. Regards, Balaji.P From: Justin Hammond [mailto:justin.hamm...@rackspace.com] Sent: Thursday, August 29, 2013 7:39 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels I find that kind of flexibility quite valuable for plugin developers. +1 to this. I'd like to be involved if possible with helping you with it. From: balaji patnala patnala...@gmail.commailto:patnala...@gmail.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thu, 29 Aug 2013 11:02:33 +0530 To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org openst...@lists.openstack.orgmailto:openst...@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels Hi, When compared to Nova URL implementations, It is observed that the Neutron URL support cannot be used for more than TWO levels. Applications which want to add as PLUG-IN may be restricted with this. We want to add support for changes required for supporting more than TWO Levels of URL by adding the support changes required in Core Neutron Files. Any comments/interest in this.? Regards, Balaji.P On Tue, Aug 27, 2013 at 5:04 PM, B Veera-B37207 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, The current infrastructure provided in Quantum [Grizzly], while building Quantum API resource URL using the base function 'base.create_resource()' and RESOURCE_ATTRIBUTE_MAP/SUB_RESOURCE_ATTRIBUTE_MAP, supports only two level URI. Example: GET /lb/pools/pool_id/members/member_id Some applications may need more than two levels of URL support. Example: GET /lb/pools/pool_id/members/member_id/xyz/xyz_id If anybody is interested in this, we want to contribute for this as BP and make it upstream. Regards, Veera. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Why is network and subnet modeled separately?
Though we can add multiple subnets to the Network. We don't have an option to attach/select subnet to Network. It is observed that when all the IP Address are consumed from first subnet, then it starts using the next subnet available for the network. More flexibility in selecting subnet to Network will be a good thing to have. Any thoughts or use-case information for not giving an option to select subnet for a Network? Regards, Balaji.P From: Lorin Hochstein [mailto:lo...@nimbisservices.com] Sent: Thursday, August 15, 2013 1:43 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [neutron] Why is network and subnet modeled separately? Here's a neutron implementation question: why does neutron model network and subnet as separate entities? Or, to ask another way, are there are any practical use cases where you would *not* have a one-to-one relationship between neutron networks and neutron subnets in an OpenStack deployment? (e.g. one neutron network associated with multiple neutron subnets, or one neutron network associated with zero neutron subnets)? Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.comhttp://www.nimbisservices.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Network Information Sharing with OpenFlow Controller
Hi Kyle, Thanks for information. We want to follow different approach like non-intrusive approach. We will share more details on this later. Regards, Balaji.P -Original Message- From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com] Sent: Monday, August 05, 2013 7:34 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Neutron] Network Information Sharing with OpenFlow Controller On Aug 4, 2013, at 1:20 AM, P Balaji-B37839 b37...@freescale.com wrote: Hi, Anyone in the community is working on the OpenStack Controller and OpenFlow Controller Integration for Network and VM Information sharing. High level approach on this is attached to this mail as PPT. Idea is to share the Network and VM information to OpenFlow Controller for DC Network OpenFlow Switches. Based on this Network/VM information OpenFlow Controller can add flows to these OF-Switches based on the shared Network/Port Information. This use case is for Data Centre Networks where OpenStack Controller deployed for SDN Network. Any comments or thoughts on this are appreciated. Hi Balaji.P: There is already integration with Ryu [1] which has been upstream as a Quantum/Neutron plugin since Folsom. And we are currently working on integration with OpenDaylight [2] as well. Both of those are capable of being OpenFlow controllers. Can you explain how your design is different or could build upon either of those? Thanks, Kyle [1] https://github.com/osrg/ryu/wiki/OpenStack [2] http://www.opendaylight.org/ Regards, Balaji.P -Original Message- From: P Balaji-B37839 Sent: Friday, August 02, 2013 4:41 PM To: OpenStack Development Mailing List Cc: Addepalli Srini-B22160; B Veera-B37207; Mannidi Purandhar Sairam-B39209; Lingala Srikanth Kumar-B37208; Somanchi Trinath-B39208; Vetcha Sarat Babu-B37147 Subject: [openstack-dev] [Neutron] OpenStack Controller and OpenFlow Controller Network Information Sharing Hi, Please find that attachment to this mail as high level architecture of OpenStack and OpenFlow Controller Integration for Network/VM/Network Services Information sharing, We are planning to publish blue-print for this. Let us know your comments and suggestions. Regards, Balaji.P OSC-OFC-Integration.pptx___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposal to add new neutron-core members
+1 for Kyle and +1 for Armando Both are going to adding muscle to Neutron Core Team. Congrats Guys! On 07/23/2013 03:15 PM, Mark McClain wrote: All- I'd like to propose that Kyle Mestery and Armando Migliaccio be added to the Neutron core team. Both have been very active with valuable reviews and contributions to the Neutron community. Neutron core team members please respond with +1/0/-1. +1 for each! -Bob mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ~~~ Dan Wendlandt Nicira, Inc: www.nicira.comhttp://www.nicira.com twitter: danwendlandt ~~~ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
