| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-08-27 | |||
| 12:57:53 | sean-k-mooney | but its mac shoudl be still enforced by nova/neutron to be the neutron port mac | |
| 12:59:03 | sean-k-mooney | the kernel dirver is free to rest the mack to all 0000 when the vm is stopped but if it is started again it shoudl be programed by nova/libvirt to the requsted mac again | |
| 12:59:20 | sean-k-mooney | changes to things like link state in the guest or phsysical on the host shoudl not impact the mac at all | |
| 13:00:24 | sean-k-mooney | chanign the mac in the guest shoudl not propagate to the vf in trusted mode and if it does i woudl consider that to be a security issue | |
| 13:00:37 | sean-k-mooney | specificly in the vendors PF and VF driver | |
| 13:01:40 | ralonsoh | sean-k-mooney, but port bonding (and MAC changing) is also considered in the nova spec | |
| 13:01:49 | sean-k-mooney | yes an no | |
| 13:01:54 | sean-k-mooney | what we were descibeing there | |
| 13:02:11 | sean-k-mooney | was the ablity to create a bond port in the guest with a diffent mac then what is on the VF | |
| 13:02:17 | sean-k-mooney | on the host | |
| 13:02:36 | sean-k-mooney | how this used to work is if you change the mac on the guest interface the host mac woudl remain the same | |
| 13:02:45 | sean-k-mooney | in ip tools | |
| 13:02:50 | sean-k-mooney | or ifconfig | |
| 13:03:05 | sean-k-mooney | btu the mac on the packet that was sent on the wire would be updated | |
| 13:03:25 | ralonsoh | sean-k-mooney, ahhhh I thought that if you add two interfaces to a bond (inside the VM) you also change the VF MAC | |
| 13:03:26 | sean-k-mooney | ralonsoh: i think that is what has changed | |
| 13:03:38 | sean-k-mooney | you can change the guest visable side | |
| 13:04:03 | ralonsoh | ahhhh so you can update the bond MAC but it will eventually use the VF MAC outside the VM | |
| 13:04:06 | ralonsoh | I didn't know that | |
| 13:04:12 | sean-k-mooney | btu on niantic for exampel that never actully changed the mac on the host side form the perspecitive of libvirt or ifconfig | |
| 13:04:38 | sean-k-mooney | it would change the mac on the wire which wi why it worked btu the comtople plane view was nto updated | |
| 13:04:58 | sean-k-mooney | i woudl assume at some point they hooked up the mailbox protocol to propagate the mac change | |
| 13:05:21 | ralonsoh | yeah, this is what is happening now | |
| 13:05:30 | sean-k-mooney | ralonsoh: ideaaly the sriov nic agent would use the pci adddress not the the mac/name | |
| 13:05:35 | ralonsoh | and this is of course an issue (at least from Neutron point of view) | |
| 13:05:58 | ralonsoh | sriov agent uses the MAC/PCI tuple to identify a port | |
| 13:06:04 | sean-k-mooney | is this the cause of the customer bug where tehy were seeing the state flap | |
| 13:06:19 | ralonsoh | yes | |
| 13:06:38 | sean-k-mooney | ah ok. im glad i updated that to the netwrokign team so :P | |
| 13:06:55 | sean-k-mooney | so ya i woudl consider just using the pci adress | |
| 13:07:07 | sean-k-mooney | the reason you check both is because of connectx-3 | |
| 13:07:15 | ralonsoh | so that would require a refactor of the sriov agent | |
| 13:07:19 | sean-k-mooney | in that generation of nic and only in that nic | |
| 13:07:39 | sean-k-mooney | you could have 2 pfs with the same pci adress | |
| 13:07:57 | sean-k-mooney | it was dumb and broke a bunch of other things and no one does that anymore | |
| 13:08:09 | ralonsoh | that's another story... | |
| 13:08:22 | ralonsoh | but of course, that won't work with ML2/SRIOV | |
| 13:15:20 | sean-k-mooney | ralonsoh: well just using the pci address shoudl work for ml2/sriov in general | |
| 13:16:08 | ralonsoh | sean-k-mooney, maybe, I need to check that. We need, at least, to write a warning if the expected MAC address is not set | |
| 13:16:41 | ralonsoh | how do I know a VF is used if I the MAC is the only thing I can check (for a PCI address) | |
| 13:16:59 | sean-k-mooney | you know its used by checkign the binding profile in the port | |
| 13:17:14 | sean-k-mooney | we pass the pci_slot | |
| 13:17:28 | sean-k-mooney | var which has the full pci adress | |
| 13:18:05 | ralonsoh | yes but I mean, in the SR-IOV agent we are detecting the port binding checking that the VF in a specific PCI has the expected MAC | |
| 13:18:24 | ralonsoh | and the MAC is set by nova compute | |
| 13:18:34 | sean-k-mooney | ya so it never actully needed to do that for what it worth | |
| 13:18:38 | ralonsoh | that was the trigger to send the vif-plugged event | |
| 13:18:47 | sean-k-mooney | orginally the sriov nic againe was entirly optional and not needed for intel nics | |
| 13:19:09 | sean-k-mooney | it was created by melanonx ot all managing things like link state via the admin state of the port | |
| 13:19:18 | sean-k-mooney | the mac programming to this day is done by nova | |
| 13:19:29 | ralonsoh | or qos or changing the propagation flag | |
| 13:20:01 | ralonsoh | I'll raise this issue in the Neutron community, I'll create a LP bug | |
| 13:20:08 | sean-k-mooney | as with everythign else the l2 part of the networing (seting the mac) is done by nova based on the mac set in the neutron port | |
| 13:20:13 | sean-k-mooney | ack | |
| 13:20:42 | sean-k-mooney | i think its fair to raise a warnign if it not the expectev version and its not using trusted VF | |
| 13:20:53 | sean-k-mooney | if it is then it shoud be info level IMO | |
| 13:21:58 | sean-k-mooney | maybe warning is valid but this is apprently vendor and drive rdependnet beahivor | |
| 13:22:22 | sean-k-mooney | warnings are normmly a call to arms for an operator to fix somethign and i dont think there is anything for them to fix in this case | |
| 13:22:32 | ralonsoh | warning is better than forcing the resync | |
| 13:22:44 | sean-k-mooney | oh im not saying we shoudl resync | |
| 13:23:07 | ralonsoh | well, if the mac is changed and doesn't match with the Neutron port one, this is indeed a warning | |
| 13:23:08 | sean-k-mooney | im just sayign the log message shoudl maybe be at a lower level | |
| 13:23:26 | sean-k-mooney | ack | |
| 13:23:28 | ralonsoh | I'll raise the bug and propose a patch, we can decide this in the review | |
| 13:23:50 | sean-k-mooney | you could also cosnider deprecating trusted_vf.... | |
| 13:24:05 | ralonsoh | for sure, that should only happen with trusted VF | |
| 13:24:20 | ralonsoh | if the port is not trusted, this is for sure something more serious | |
| 13:24:28 | sean-k-mooney | i dont like that feature becasue we stilll have not fixed the fact it required you to write data to a field only nova shoudl modify | |
| 13:25:06 | sean-k-mooney | i.e. there shoudl be a seprate trunsted vF extention that does not require you to mess with the binding profile | |
| 13:25:20 | sean-k-mooney | since humans shoudl never write to that | |
| 13:25:55 | ralonsoh | sorry, I don't get your point here | |
| 13:26:23 | ralonsoh | Neutron does not set the VF trusted flag | |
| 13:26:26 | sean-k-mooney | the trusted VF feature required you to requet it by writign data to the binding:profile field | |
| 13:26:34 | ralonsoh | ahhh ok ok | |
| 13:26:40 | ralonsoh | now I understand | |
| 13:26:51 | sean-k-mooney | correct neutron does not a human has to inject data into a filed that only nova should modify | |
| 13:26:59 | ralonsoh | well, we have done this before (removing things from the binding profile) | |
| 13:27:00 | sean-k-mooney | there shoudl be a port extenion for it instead | |
| 13:27:08 | sean-k-mooney | yep | |
| 13:27:11 | ralonsoh | agree | |
| 13:27:21 | ralonsoh | ok, I'll open another LP bug heheheheh | |
| 13:27:25 | sean-k-mooney | it woudl be nice to finally fix this so we dont need custom policy for the binding:profile filed | |
| 13:27:34 | sean-k-mooney | thanks | |
| 13:55:33 | gibi | I'm cancelling the eventlet sync today for the sake of the FeatureFreeze. I'm not tracking anything that is critical for the FF from the eventlet-removal series. The nova-conductor change is blocked by a bug in futurist so that is moved to GG. | |
| 13:56:08 | dansmith | gibi: I'm just reading that now | |
| 13:56:21 | dansmith | futurist aside, we could just make a list of threads and wait for them manually right? | |
| 13:56:28 | gibi | dansmith: right | |
| 13:56:35 | dansmith | probably best to move to G anyway given it's not critical | |
| 13:56:38 | gibi | we have a list of futures we can wait on | |
| 13:56:45 | dansmith | ack | |
| 13:57:05 | gibi | I will file a futurist bug as it might effect us or others elswhere when we shutting down executors | |
| 13:57:19 | gibi | but that is also post FF :) | |
| 13:57:45 | sambork_ | gibi, ack, I will work on that after ff then | |
| 13:58:22 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | |
| 13:58:22 | opendevreview | Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814 | |
| 13:58:23 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | |
| 13:58:23 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | |
| 13:58:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Purge nested SEV RPs when SEV is disabled https://review.opendev.org/c/openstack/nova/+/958626 | |
| 13:58:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: Add functional test scenario for mixed SEV RPs https://review.opendev.org/c/openstack/nova/+/958562 | |
| 14:00:09 | ralonsoh | sean-k-mooney, just a heads-up: https://review.opendev.org/c/openstack/neutron/+/926068 | |