[Openstack-operators] Routing deployments + Storage networks
Hi operators, I had a quick question for those operators who use a routed topology for their OpenStack deployments, whether routed spine-leaf or routed underlay providing L2 connectivity in tunnels; Where using one, would the storage network (e.g. Ceph public network) also be routed on the same fabric, or would separate fabric be employed here to reduce hops? Many thanks, Paul Browne -- *** Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pf...@cam.ac.uk Tel: 0044-1223-746548 *** ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Libvirt CPU map (host-model)
Hello Belmiro, We ran into this issue recently, similarly upgrading a RHEL7.3 OpenStack Platform Overcloud to RHEL7.4 and in the process upgrading libvirtd. For instances that were spawned prior to this upgrade, we see the CPU flags [1] , but for new instance workload the CPU flags [2]. Notably the CMT=disabled flag is present in [1] but absent in [2] This similarly prevents live migration of the older spawned instances, as the CMT=disabled flag is rejected. A RH bugzilla [3] was opened on the issue which attracted a lot of really good contributions from libvirt maintainers. The one sure-fire workaround we'd found is just to cold-boot the instance again, starting it under the new libvirtd. But from that BZ there is also a slightly more hack-ish workaround to hand-edit the running domain XML and clear the offending CMT flag (comment 12 on that BZ). Hope this helps some, Thanks, Paul Browne [1] https://pastebin.com/JshWi6i3 [2] https://pastebin.com/5b8cAanP [3] https://bugzilla.redhat.com/show_bug.cgi?id=1495171 On 9 October 2017 at 04:59, Belmiro Moreira < moreira.belmiro.email.li...@gmail.com> wrote: > Hi, > the CPU model that we expose to the guest VMs varies considering the > compute node use case. > We use "cpu_mode=host-passthrough" for the compute nodes that run batch > processing VMs and "cpu_mode=host-model" for the compute nodes for service > VMs. The reason to have "cpu_mode=host-model" is because we assumed that > new CPUs (in the libvirt map) will continue to support previous features > allowing for live migration when we need to move the VMs to a new CPU > generation. > > We recently upgraded from CentOS7.3 (libvirt 2.0.0) to CentOS7.4 (libvirt > 3.2.0) and noticed that now libvirt maps a slightly different CPU for the > guests. For example, still "Haswell no-TSX" but no mention to the feature > "cmt". This blocks suspended VMs to restore and live migrate. > > Has anyone experienced this same problem? > > We are thinking in few solutions but none of them are nice (downgrade > libvirt? hard reboot instances? ...) > > thanks, > Belmiro > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- *** Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pf...@cam.ac.uk Tel: 0044-1223-746548 *** ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Appending a security group to a Neutron port
Hello Operators, One of the operations I find myself doing quite often in our OpenStack is appending a new security group to a Neutron port (rather than a full instance) which already has several security groups defined on it. As far as I can tell (possibly wrongly!), there seems to be no easy way to do this. For a Neutron port with existing security groups A & B on it, with a new one to be added C, the closest operation via API calls from the older Neutron client would seem to be; neutron port-update --security-group A --security-group B --security-group C *Neutron Port UUID* , as there seems to be no in-built way to merely append a new security-group to a port's existing ones (a full list must be provided). Am I incorrect in thinking this? I would love to find out that that is the case! Currently I find myself doing a fair bit of JSON-munging of the existing security-groups on a port (in order to add a new one to the port without wiping out its existing security groups), so I'd love to know if any Operators also often do this operation and, if so, how they best go about it. Kind regards, Paul Browne -- *** Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pf...@cam.ac.uk Tel: 0044-1223-46548 *** ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Multiple floating IPs mapped to multiple vNICs (multi-homing)
Hello Saverio, Many thanks for the reply, I'll answer your queries below; On 01/12/16 12:49, Saverio Proto wrote: Hello, while the problem is in place, you should share the output of ip rule show ip route show table 1 It could be just a problem in your ruleset Of course, these are those outputs ; root@test1:~# ip rule show 0: from all lookup local 32764: from all to 10.0.16.11 lookup rt2 32765: from 10.0.16.11 lookup rt2 32766: from all lookup main 32767: from all lookup default root@test1:~# ip route show table 1 default via 10.0.16.1 dev eth1 10.0.16.0/24 dev eth1 scope link src 10.0.16.11 and, which one is your webserver ? can you tcpdump to make sure reply packets get out on the NIC with src address 10.0.16.11 ? Saverio The instance has its two vNICs with source addresses 10.0.0.11 & 10.0.16.11, and the web-server is listening on both. The HTTP packets do seem to be getting out from 10.0.16.11 as source, but are stopped elsewhere upstream. I've attached two pcaps showing HTTP reply packets, one from 10.0.0.11 (first vNIC; HTTP request and reply works to a remote client) and one from 10.0.16.11 (second vNIC; HTTP request is sent, reply not received by remote client). In the latter case, the server starts to make retransmissions to the remote client. Kind regards, Paul Browne 2016-12-01 13:08 GMT+01:00 Paul Browne <pf...@cam.ac.uk>: Hello Operators, For reasons not yet amenable to persuasion otherwise, a customer of our ML2+OVS classic implemented OpenStack would like to map two floating IPs pulled from two separate external network floating IP pools, to two different vNICs on his instances. The floating IP pools correspond to one pool routable from the external Internet and another, RFC1918 pool routable from internal University networks. The tenant private networks are arranged as two RFC1918 VXLANs, each with a router to one of the two external networks. 10.0.0.0/24 -> route to -> 128.232.226.0/23 10.0.16.0/24 -> route to -> 172.24.46.0/23 Mapping two floating IPs to instances isn't possible in Horizon, but is possible from command-line. This doesn't immediately work, however, as the return traffic from the instance needs to be sent back through the correct router gateway interface and not the instance default gateway. I'd initially thought this would be possible by placing a second routing table on the instances to handle the return traffic; debian@test1:/etc/iproute2$ less rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 1 rt2 debian@test1:/etc/network$ less interfaces # The loopback network interface auto lo iface lo inet loopback # The first vNIC, eth0 auto eth0 iface eth0 inet dhcp # The second vNIC, eth1 auto eth1 iface eth1 inet static address 10.0.16.11 netmask 255.255.255.0 post-up ip route add 10.0.16.0/24 dev eth1 src 10.0.16.11 table rt2 post-up ip route add default via 10.0.16.1 dev eth1 table rt2 post-up ip rule add from 10.0.16.11/32 table rt2 post-up ip rule add to 10.0.16.11/32 table rt2 And this works well for SSH and ICMP, but curiously not for HTTP traffic. Requests to a web-server listening on all vNICs are sent but replies not received when the requests are sent to the second mapped floating IP (HTTP requests and replies work as expected when sent to the first mapped floating IP). The requests are logged in both cases however, so traffic is making it to the instance in both cases. I'd say this is clearly an unusual (and possibly un-natural) arrangement, but I was wondering whether anyone else on Operators had come across a similar situation in trying to map floating IPs from two different external networks to an instance? Kind regards, Paul Browne -- ******* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pf...@cam.ac.uk Tel: 0044-1223-46548 *** ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- ******* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pf...@cam.ac.uk Tel: 0044-1223-46548 *** eth0.pcap Description: application/vnd.tcpdump.pcap eth1.pcap Description: application/vnd.tcpdump.pcap ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Multiple floating IPs mapped to multiple vNICs (multi-homing)
Hello Operators, For reasons not yet amenable to persuasion otherwise, a customer of our ML2+OVS classic implemented OpenStack would like to map two floating IPs pulled from two separate external network floating IP pools, to two different vNICs on his instances. The floating IP pools correspond to one pool routable from the external Internet and another, RFC1918 pool routable from internal University networks. The tenant private networks are arranged as two RFC1918 VXLANs, each with a router to one of the two external networks. 10.0.0.0/24 -> route to -> 128.232.226.0/23 10.0.16.0/24 -> route to -> 172.24.46.0/23 Mapping two floating IPs to instances isn't possible in Horizon, but is possible from command-line. This doesn't immediately work, however, as the return traffic from the instance needs to be sent back through the correct router gateway interface and not the instance default gateway. I'd initially thought this would be possible by placing a second routing table on the instances to handle the return traffic; debian@test1:/etc/iproute2$ less rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 1 rt2 debian@test1:/etc/network$ less interfaces # The loopback network interface auto lo iface lo inet loopback # The first vNIC, eth0 auto eth0 iface eth0 inet dhcp # The second vNIC, eth1 auto eth1 iface eth1 inet static address 10.0.16.11 netmask 255.255.255.0 post-up ip route add 10.0.16.0/24 dev eth1 src 10.0.16.11 table rt2 post-up ip route add default via 10.0.16.1 dev eth1 table rt2 post-up ip rule add from 10.0.16.11/32 table rt2 post-up ip rule add to 10.0.16.11/32 table rt2 And this works well for SSH and ICMP, but curiously not for HTTP traffic. Requests to a web-server listening on all vNICs are sent but replies not received when the requests are sent to the second mapped floating IP (HTTP requests and replies work as expected when sent to the first mapped floating IP). The requests are logged in both cases however, so traffic is making it to the instance in both cases. I'd say this is clearly an unusual (and possibly un-natural) arrangement, but I was wondering whether anyone else on Operators had come across a similar situation in trying to map floating IPs from two different external networks to an instance? Kind regards, Paul Browne -- *** Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pf...@cam.ac.uk Tel: 0044-1223-46548 *** ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
