[openstack-dev] DVR and l2 population
Hi, As I understand it l2 population is not a requirement but it's strongly recommended. https://review.openstack.org/#/c/165311/ validates that OVS agent is configured with l2_population enabled when DVR is enabled. Now that DVR supports VLAN do we want to take back this validation ? Itzik __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] DVR and l2_population
Thanks Armando. Another question: Every compute node that hosts instances with floating IPs has an IP from the external network pool. If the SNAT is done by the Network Node what is the reason for the compute node to have an external IP? BR, Itzik On 02/11/2015 08:13 PM, Armando M. wrote: L2pop is a requirement. With the existing agent-based architecture, L2pop is used to update the FDB tables on the compute hosts to make east/west traffic possible whenever a new port is created or existing one is updated. Cheers, Armando On 10 February 2015 at 23:07, Itzik Brown itz...@redhat.com mailto:itz...@redhat.com wrote: Hi, In the Networking guide [1] there is a requirement for l2 population both as a mechanism driver and in OVS agent when enabling DVR. Is this is a requirement and if so what is the reason? Thanks, Itzik [1] http://docs.openstack.org/networking-guide/content/ha-dvr.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][sriov] PciDeviceRequestFailed error
Hi, I think it's better to ask this question at ask.openstack.org or the openstack mailing list. BR, Itzik On 12/04/2014 12:26 PM, Akilesh K wrote: Hi, I am using neutron-plugin-sriov-agent. I have configured pci_whitelist in nova.conf I have configured ml2_conf_sriov.ini. But when I launch instance I get the exception in subject. On further checking with the help of some forum messages, I discovered that pci_stats are empty. mysql select hypervisor_hostname,pci_stats from compute_nodes; +-+---+ | hypervisor_hostname | pci_stats | +-+---+ | openstack | []| +-+---+ 1 row in set (0.00 sec) Further to this I found that PciDeviceStats.pools is an empty list too. Can anyone tell me what I am missing. Thank you, Ageeleshwar K ___ 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] SRIOV failures error-
Hi,
Seems like you don't have available devices for allocation.
What's the output of:
#echo 'use nova;select hypervisor_hostname,pci_stats from
compute_nodes;' | mysql -u root
Itzik
On 12/02/2014 08:21 AM, Murali B wrote:
Hi
we are trying to bring-up the SRIOV on set-up.
facing the below error when we tried create the vm.
*
Still during creating instance ERROR appears .
PciDeviceRequestFailed: PCI device request ({'requests':
[InstancePCIRequest(alias_name=None,count=1,is_new=False,request_id=58584ee1-8a41-4979-9905-4d18a3df3425,spec=[{physical_network='physnet1'}])],
'code': 500}equests)s failed*
followed the steps from the
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
Please help us to get rid this error. let us know if any configuration
is required at hardware in order to work properly.
Thanks
-Murali
___
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] FWaaS/Security groups Not blocking ongoing traffic
Hi, When building a firewall with a rule to block a specific Traffic - the current traffic is not blocked. For example: Running a Ping to an instance and then building a firewall with a rule to block ICMP to this instance doesn't have affect while the ping command is still running. Exiting the command and then trying pinging the Instance again shows the desired result - i.e. the traffic is blocked. It also the case when using security groups to block traffic. Is this the desired outcome or is it a bug? Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic
- Original Message - From: Carl Baldwin c...@ecbaldwin.net To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, October 27, 2014 5:27:57 PM Subject: Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier spasqu...@mirantis.com wrote: Hello Itzik, This has been discussed lately on this ML. Please see https://bugs.launchpad.net/neutron/+bug/1335375. This is a good example that any create, update, or delete of a SG rule can expose this issue. This bug only mentions delete. I'll update the bug to increase the scope beyond just deletes because it really is the same conntrack issue at the root of the problem. Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Carl, FWaaS has the same issues as well. What do you suggest - open a new bug or updating the current one? Thanks, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][NFV] VIF_VHOSTUSER
On 8/30/2014 11:22 PM, Ian Wells wrote: The problem here is that you've removed the vif_driver option and now you're preventing the inclusion of named VIF types into the generic driver, which means that rather than adding a package to an installation to add support for a VIF driver it's now necessary to change the Nova code (and repackage it, or - ew - patch it in place after installation). I understand where you're coming from but unfortunately the two changes together make things very awkward. Granted that vif_driver needed to go away - it was the wrong level of code and the actual value was coming from the wrong place anyway (nova config and not Neutron) - but it's been removed without a suitable substitute. It's a little late for a feature for Juno, but I think we need to write something discovers VIF types installed on the system. That way you can add a new VIF type to Nova by deploying a package (and perhaps naming it in config as an available selection to offer to Neutron) *without* changing the Nova tree itself. In the meantime, I recommend you consult with the Neutron cores and see if you can make an exception for the VHOSTUSER driver for the current timescale. -- Ian. I Agree with Ian. My understanding from a conversation a month ago was that there would be an alternative to the deprecated config option. As far as I understand now there is no such alternative in Juno and in case that one has an out of the tree VIF Driver he'll be left out with a broken solution. What do you say about an option of reverting the change? Anyway It might be a good idea to discuss propositions to address this issue towards Kilo summit. BR, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Configuring libivrt VIF driver
On 27/08/2014 17:06, Daniel P. Berrange wrote: On Tue, Aug 26, 2014 at 05:02:10PM +0300, Itzik Brown wrote: Hi, Following the conversation [1]: My understanding was that the way to use out of the tree vif_driver is to set vif_driver option in nova.conf until there is a better way to support such cases but the commit [2] removed this option. Can someone clarify the current status (i.e. what is the current way to do it ) in Juno? For Juno the vif_driver option still exists can be used. It is only deleted in the Kilo release. The recommendation is that people working on new VIF drivers should do so on a branch of the Nova repo, so that the can modify the libvirt VIF driver code to support their needs, rather than try to write a completely isolated out of tree impl. This is an approach that will need to be taken regardless in order to submit the VIF driver for review and merge to Nova. Regards, Daniel Sorry for taking the newbie approach here but can you explain me how to do it in Juno? I see that vif_driver is pointing to LibvirtGenericVIFDriver [1]but not to a config option. [1] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py BR, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Configuring libivrt VIF driver
Hi, Following the conversation [1]: My understanding was that the way to use out of the tree vif_driver is to set vif_driver option in nova.conf until there is a better way to support such cases but the commit [2] removed this option. Can someone clarify the current status (i.e. what is the current way to do it ) in Juno? [1] https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg30177.html [2] https://github.com/openstack/nova/commit/7561c8ded211d53e8745d1420a73b82bd0fc35cf https://github.com/openstack/nova/commit/7561c8ded211d53e8745d1420a73b82bd0fc35cf- (libvirt: remove vif_driver config parameter) Thanks, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Configuring libivrt VIF driver
Hi, I see that the option to specify vif_driver in nova.conf for libvirt is deprecated for Juno release. What is the way to use an external VIF driver (i.e. that is out of the tree)? Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] alembic migration not working? specifically in regards to ml2_port_bindings table
Hi, Have you looked at https://github.com/openstack/neutron/blob/master/neutron/db/migration/README ? Itzik On 08/04/2014 23:41, Paul Ward wrote: Is anyone else out there seeing failures that appear to be because alembic is not upgrading db tables in neutron? I'm seeing, on an upgrade, that ml2_port_bindings is not being updated to remove column cap_port_filter or add columns vnic_type, profile, or vif_details, I'm also seeing the subnets table not getting updated with the ipv6_ra_mode column. I'm not intimately familiar with alembic so I'm not really sure what is supposed to kick off the upgrade/downgrade or if the following revision chains are ok. Does merely starting neutron-server initiate the upgrade? In perusing some of the ml2_port_bindings alembic files, I came up with these revision chains: 32a65f71af51 (where ml2_port_bindings was first created) ^ 14f24494ca31 (this is creating some arista tables... I don't know why it's a down_revision for ml2_port_bindings table creation above) 157a5d299379 (adds profile column to ml2_port_bindings table apparently not called in my environment's upgrade) ^ 50d5ba354c23 (adds vif_details column to ml2_port_bindings table and removes cap_port_filter colume from ml2_port_bindings table apparently not called in my environment's upgrade) ^ 27cc183af192 (first file to add a column, vnic_type, to ml2_port_bindings apparently not called in my environment's upgrade) ^ 4ca36cfc898c (creates table neutron_nsx_router_mappings... don't see how this is related to ml2_port_bindings other than similar foreign key constraints) Notice the chains do not connect with each other. It seems to me that 27cc183af192 should actually call out 32a65f71af51 as the down_revision as 32a65f71af51 is where the ml2_port_bindings table was first created. 4ca36cfc898c just deals with the neutron_nsx_router_mappings table... I don't see how that's related to ml2_port_bindings table other than having some similar foreign key constraints. Thanks in advance! ___ 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] Request for review - Change Ic98db496: Adding VIF Driver to support Mellanox Plugin
Hi, I have a patch waiting for review. https://review.openstack.org/#/c/35189/ - Adding VIF Driver to support Mellanox Plugin. I'll appreciate any comment/review. Thanks, Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Mellanox VIF Driver
On 05/07/2013 17:02, Daniel P. Berrange wrote: On Thu, Jul 04, 2013 at 11:53:45AM +0300, Itzik Brown wrote: Hi, We released a code for a VIF Driver that will work with Mellanox Quantum Plugin. Mellanox plugin provisions Virtual Networks via embedded HCA switching functionality (SR-IOV capability of Network adapter). The code is here: https://review.openstack.org/#/c/35189/ We allocate and assign probed SR-IOV VF (Virtual Function) as a Para virtualized Interface of the instance. We need to: 1)Allocate device of probed VF 2)Give a name to the device in the XML that will allow us to supprot live migration. We have utility for managing embedded switch that allows VF assignment and configuration. We chose to use the vif['dev_name'] as a basis for the name of the device. This allow us to use different devices on different hosts when doing a migration. When doing plug/unplug we are using a utility to allocate the device and change it's name to the logical one. My concern / question on the review is about where the allocation of the device name is done. Currently you have it done on the Nova side, by calling out the the utility tools. This ties the Nova VIF code to the specific impl of the Mellanox driver in Neutron. This means it is not appropriate to use a generic vif_type=direct, but really need to ue a vif_type=mellanox. The other option, would be if you could do the device name allocation on the Neutron side, in response to the Nova API call to allocate a VIF port on the network. If this is possible, then all the Mellanox specific code would be in Neutron, and the Nova code would be entirely generic, meaning that use of a generic vif_type=direct would be acceptable. I favour the latter architectural split, since it de-couples Nova Neutron to a greater extent. I'm not sure if is actually possible to implement it that way, since I'm not familiar with your Neuton plugin design. If it isn't possible, then you'll need to change your patch to use a vif_type=mellanox name instead This is basically it. It's a temporary solution until there will be a solution that will address all the issues regarding SR-IOV. Boris Pavlovic is doing work regarding SR-IOV and we plan to help/adopt this effort. We want to ask for your opinion regarding the way we chose. Daniel Daniel, Thanks for your comments. We'll go with vif_type=mlnx_direct for now since it's easier to implement for now. In the Medium/Long term we want to use interface type='network ( as started in https://review.openstack.org/#/c/29048/). We have some issues we need to address with this solution: 1)How the creation of the network pool is done. 2)The scheduler should be aware of the number of available devices for each network pool. 3)For configuration of things like VLAN there is a need to know which device is allocated to each vNIC , preferably before the instance is started. Itzik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
