| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-11 | |||
| 12:35:10 | admin0 | numa reasons | |
| 12:35:10 | admin0 | numa reasons | |
| 12:35:32 | sean-k-mooney | are tehy multi numa guest or singel numa | |
| 12:35:32 | sean-k-mooney | are tehy multi numa guest or singel numa | |
| 12:36:11 | sean-k-mooney | i assume the vm has 2 numa nodes and you want one form each numa node? | |
| 12:36:11 | sean-k-mooney | i assume the vm has 2 numa nodes and you want one form each numa node? | |
| 12:36:34 | sean-k-mooney | so you want to spread the allcoation across host numa nodes? | |
| 12:36:34 | sean-k-mooney | so you want to spread the allcoation across host numa nodes? | |
| 12:37:00 | admin0 | right | |
| 12:37:00 | admin0 | right | |
| 13:02:29 | sean-k-mooney | admin0: we currentl do not have a feature to enable that and if you did it today it woudl reduce your performance | |
| 13:02:29 | sean-k-mooney | admin0: we currentl do not have a feature to enable that and if you did it today it woudl reduce your performance | |
| 13:03:35 | sean-k-mooney | we have a downstream backlog item https://bugzilla.redhat.com/show_bug.cgi?id=1762119 which would allow use to create a pcie root complex per virtual guest numa node | |
| 13:03:35 | openstack | bugzilla.redhat.com bug 1762119 in openstack-nova "[RFE] Create a virtual PCI root complex per guest NUMA node when using q35" [High,New] - Assigned to nova-maint | |
| 13:03:35 | sean-k-mooney | we have a downstream backlog item https://bugzilla.redhat.com/show_bug.cgi?id=1762119 which would allow use to create a pcie root complex per virtual guest numa node | |
| 13:03:35 | openstack | bugzilla.redhat.com bug 1762119 in openstack-nova "[RFE] Create a virtual PCI root complex per guest NUMA node when using q35" [High,New] - Assigned to nova-maint | |
| 13:04:15 | sean-k-mooney | but without that today all pci device are effectivly assocated with the guest virtual numa node 0 | |
| 13:04:15 | sean-k-mooney | but without that today all pci device are effectivly assocated with the guest virtual numa node 0 | |
| 13:04:36 | sean-k-mooney | so you would have corss numa traffic if you enabeld it today | |
| 13:04:36 | sean-k-mooney | so you would have corss numa traffic if you enabeld it today | |
| 13:05:57 | sean-k-mooney | admin0: if we create a virtual PCI root complex per guest NUMA node that will allow use to optimise the virtual toplogy but its a large change | |
| 13:05:58 | sean-k-mooney | admin0: if we create a virtual PCI root complex per guest NUMA node that will allow use to optimise the virtual toplogy but its a large change | |
| 13:06:24 | sean-k-mooney | nova would have to fully generate the virtual pci topology and assign pci addres to each device | |
| 13:06:24 | sean-k-mooney | nova would have to fully generate the virtual pci topology and assign pci addres to each device | |
| 13:06:59 | sean-k-mooney | its not imposiable to do and we hope to do it eventually but its of similar complexity to cpu pinning | |
| 13:07:00 | sean-k-mooney | its not imposiable to do and we hope to do it eventually but its of similar complexity to cpu pinning | |
| 13:08:06 | admin0 | sean-k-mooney, thank you for the info | |
| 13:08:07 | admin0 | sean-k-mooney, thank you for the info | |
| 13:18:36 | sean-k-mooney | gibi: by the way for the vdpa move ops are you oke with a specless blueprint or would you like a mini spec? | |
| 13:18:36 | sean-k-mooney | gibi: by the way for the vdpa move ops are you oke with a specless blueprint or would you like a mini spec? | |
| 13:19:13 | sean-k-mooney | im working on the pci in placement spec draft first in either case but cant recall if what we said in the ptg | |
| 13:19:13 | sean-k-mooney | im working on the pci in placement spec draft first in either case but cant recall if what we said in the ptg | |
| 13:20:15 | sean-k-mooney | ah we just said "do the life cycle operations except suspend and live migrate" but did not say how we would track | |
| 13:20:16 | sean-k-mooney | ah we just said "do the life cycle operations except suspend and live migrate" but did not say how we would track | |
| 13:31:34 | ignaziocassano | Hello Everyone, I got issues on GARP during live migrations on Rocky and Stein with centos 7. I applyed some patches to force legacy port binding. Now I am igrating on train and I got same issues. Any help please ? | |
| 13:31:34 | ignaziocassano | Hello Everyone, I got issues on GARP during live migrations on Rocky and Stein with centos 7. I applyed some patches to force legacy port binding. Now I am igrating on train and I got same issues. Any help please ? | |
| 13:36:21 | openstackgerrit | Tobias Urdin proposed openstack/nova master: Stop leaking ceph df cmd in RBD utils https://review.opendev.org/c/openstack/nova/+/789374 | |
| 13:37:01 | sean-k-mooney | there is not much more we can do really. | |
| 13:37:01 | sean-k-mooney | there is not much more we can do really. | |
| 13:37:15 | ignaziocassano | Tobias, did you solve your problems on train for live migration ? | |
| 13:37:15 | ignaziocassano | Tobias, did you solve your problems on train for live migration ? | |
| 13:38:50 | sean-k-mooney | ignaziocassano: remind me again are you using ml2/ovs with iptables | |
| 13:38:50 | sean-k-mooney | ignaziocassano: remind me again are you using ml2/ovs with iptables | |
| 13:39:33 | sean-k-mooney | or are you suing the ovs firewall dirver or ovn? | |
| 13:39:33 | sean-k-mooney | or are you suing the ovs firewall dirver or ovn? | |
| 13:40:14 | ignaziocassano | my configuration is firewall_driver = iptables_hybrid and I am not usinn ovn | |
| 13:40:14 | ignaziocassano | my configuration is firewall_driver = iptables_hybrid and I am not usinn ovn | |
| 13:42:44 | ignaziocassano | I applyed neutron patch for evacuate and nova patches but it does not solve | |
| 13:42:44 | ignaziocassano | I applyed neutron patch for evacuate and nova patches but it does not solve | |
| 13:43:28 | ignaziocassano | https://review.opendev.org/c/openstack/neutron/+/640258/ | |
| 13:43:28 | ignaziocassano | https://review.opendev.org/c/openstack/neutron/+/640258/ | |
| 13:43:29 | ignaziocassano | https://review.opendev.org/c/openstack/neutron/+/753314/ | |
| 13:43:29 | ignaziocassano | https://review.opendev.org/c/openstack/neutron/+/766277/ | |
| 13:43:29 | ignaziocassano | https://review.opendev.org/c/openstack/neutron/+/753314/ | |
| 13:43:29 | ignaziocassano | https://review.opendev.org/c/openstack/neutron/+/766277/ | |
| 13:43:30 | ignaziocassano | https://review.opendev.org/c/openstack/nova/+/742180/12 | |
| 13:43:30 | ignaziocassano | https://review.opendev.org/c/openstack/nova/+/742180/12 | |
| 13:43:31 | ignaziocassano | https://review.opendev.org/c/openstack/nova/+/747454/4 | |
| 13:43:31 | ignaziocassano | https://review.opendev.org/c/openstack/nova/+/747454/4 | |
| 13:44:54 | sean-k-mooney | so for ovs with iptables we were already pluging the port into ovs in prelive migrate | |
| 13:44:54 | sean-k-mooney | so for ovs with iptables we were already pluging the port into ovs in prelive migrate | |
| 13:45:08 | sean-k-mooney | and by that i mean creating the ovs port in the ovs db | |
| 13:45:08 | sean-k-mooney | and by that i mean creating the ovs port in the ovs db | |
| 13:45:50 | sean-k-mooney | so with https://review.opendev.org/c/openstack/neutron/+/640258/ and https://review.opendev.org/c/openstack/neutron/+/753314/ | |
| 13:45:50 | sean-k-mooney | so with https://review.opendev.org/c/openstack/neutron/+/640258/ and https://review.opendev.org/c/openstack/neutron/+/753314/ | |
| 13:46:14 | sean-k-mooney | actully you dont need either of those pathces | |
| 13:46:14 | sean-k-mooney | actully you dont need either of those pathces | |
| 13:46:40 | sean-k-mooney | the l2 agent woudl have wired it up because with iptabels we are createing a linux bridge and a veth pair | |
| 13:46:40 | sean-k-mooney | the l2 agent woudl have wired it up because with iptabels we are createing a linux bridge and a veth pair | |
| 13:46:57 | ignaziocassano | I am facing same problems I got with stein | |
| 13:46:57 | ignaziocassano | I am facing same problems I got with stein | |
| 13:47:12 | sean-k-mooney | so the only neutorn patch you needed was https://review.opendev.org/c/openstack/neutron/+/766277/ to avoid the dhcp server race | |
| 13:47:12 | sean-k-mooney | so the only neutorn patch you needed was https://review.opendev.org/c/openstack/neutron/+/766277/ to avoid the dhcp server race | |
| 13:47:36 | ignaziocassano | On stein I solved with your workaround force legacy port binding | |
| 13:47:36 | ignaziocassano | On stein I solved with your workaround force legacy port binding | |
| 13:48:00 | sean-k-mooney | well that wont actuly solve it | |
| 13:48:00 | sean-k-mooney | well that wont actuly solve it | |
| 13:48:54 | sean-k-mooney | when you use legacy port bindign neutron has the port boudn to the souce node until much much later in the live migrtion | |
| 13:48:54 | sean-k-mooney | when you use legacy port bindign neutron has the port boudn to the souce node until much much later in the live migrtion | |
| 13:49:11 | sean-k-mooney | we still create the port on the destitaiton at the same time in both flows | |
| 13:49:11 | sean-k-mooney | we still create the port on the destitaiton at the same time in both flows | |
| 13:49:23 | sean-k-mooney | but we use stale info form nuetorn to do it | |
| 13:49:23 | sean-k-mooney | but we use stale info form nuetorn to do it | |
| 13:50:01 | sean-k-mooney | ignaziocassano: are you still forcing legacy mode in train | |
| 13:50:01 | sean-k-mooney | ignaziocassano: are you still forcing legacy mode in train | |
| 13:51:28 | sean-k-mooney | if you backport https://review.opendev.org/c/openstack/neutron/+/766277 it will only help if you are using multiple port bindings | |
| 13:51:28 | sean-k-mooney | if you backport https://review.opendev.org/c/openstack/neutron/+/766277 it will only help if you are using multiple port bindings | |
| 13:51:37 | ignaziocassano | Sean, I desabled the workaround for using legacy port binding. I think It is automatically disabled when I upgraded from stein to train because workaround.py is covered be new version. Right ? | |
| 13:51:37 | ignaziocassano | Sean, I desabled the workaround for using legacy port binding. I think It is automatically disabled when I upgraded from stein to train because workaround.py is covered be new version. Right ? | |
| 13:52:26 | sean-k-mooney | well you are expecting the new install to overright the exsiting files | |
| 13:52:26 | sean-k-mooney | well you are expecting the new install to overright the exsiting files | |
| 13:52:39 | sean-k-mooney | it should but that depens on how you isntalled | |
| 13:52:39 | sean-k-mooney | it should but that depens on how you isntalled | |
| 13:52:55 | ignaziocassano | yum update | |
| 13:52:55 | ignaziocassano | yum update | |
| 13:53:17 | sean-k-mooney | i think that will yes the rpm should unpack over the modifed one | |
| 13:53:17 | sean-k-mooney | i think that will yes the rpm should unpack over the modifed one | |
| 13:53:52 | sean-k-mooney | so on the neutron side you have backported https://review.opendev.org/c/openstack/neutron/+/766277 to train | |
| 13:53:52 | sean-k-mooney | so on the neutron side you have backported https://review.opendev.org/c/openstack/neutron/+/766277 to train | |
| 13:54:30 | sean-k-mooney | and enabled it by seeing [nova]/live_migration_events=true | |