| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-02 | |||
| 16:52:59 | gibi | so one can set up a VM with two ports in different neworks with the same MAC | |
| 16:53:05 | gibi | and live migration will fail | |
| 16:53:35 | gibi | question: do we want to fix it, or do we want to state that please don't try to do this | |
| 16:53:48 | dansmith | is the limitation a nova thing or a libvirt/qemu thing? | |
| 16:54:01 | gibi | on nova, how we identifies tap devs across the two XMLs | |
| 16:54:04 | dansmith | i.e. is it just us using the MAC as a primary key for mapping ports? | |
| 16:54:09 | gibi | just us | |
| 16:54:10 | dansmith | ack | |
| 16:54:21 | gibi | I rather not try to touch that XML gen code | |
| 16:54:45 | gibi | as manually managing MAC in the cloud is sort of an edge case in my head | |
| 16:55:07 | dansmith | meanin you prefer we not fix this? | |
| 16:55:21 | gibi | yepp I prefer documenting this as a known limitation | |
| 16:55:28 | bauzas | could we at least fix it by doc ? | |
| 16:55:46 | bauzas | ah too late :) | |
| 16:56:03 | dansmith | I think documenting it as a limitation now is obviously better than having it fail, | |
| 16:56:33 | dansmith | but it is also probably indicative of us using something as a PK that shouldn't be, and I also think there are probably legit reasons for doing this related to HA | |
| 16:57:23 | dansmith | IIRC, we had a todo to make the NICs identifiable by alias like the disks work I did, | |
| 16:57:29 | gibi | I tried to poke the downstream reporter about their use case doing this but so far I got nothing | |
| 16:57:31 | dansmith | which is probably what we _should_ be using instead of MAC right? | |
| 16:58:00 | bauzas | could we fail early with a good self-explaned exception ? | |
| 16:58:02 | gibi | yeah libvirt has aliases. I haven't checked if it fits to our live migration XML manipulation code to use that | |
| 16:59:24 | gibi | bauzas: today we fail here which is probably late https://github.com/openstack/nova/blob/264e868d4931595140260c0f655a10b525be38f7/nova/virt/libvirt/migration.py#L496-L500 | |
| 16:59:33 | gibi | sorry not there | |
| 16:59:40 | gibi | that is the place of the root cause | |
| 16:59:51 | gibi | we fail at | |
| 16:59:52 | bauzas | I'm thinking of when creating the instance | |
| 16:59:52 | gibi | File "/usr/lib64/python3.9/site-packages/libvirt.py", line 2225, in migrateToURI3 | |
| 17:00:30 | gibi | bauzas: that would open a can of worms, 1) pre-existing instance with duplicated MAC 2) interface attach | |
| 17:00:37 | bauzas | if you ask for two ports, can we quick get the MAC addresses already or do we need another roundtrip ? (please, I don't want this if so) | |
| 17:00:49 | gibi | if failing early is the goal then we should fail pre-live migration | |
| 17:01:01 | bauzas | yup, then yes | |
| 17:01:14 | dansmith | well, | |
| 17:01:24 | bauzas | either in the conductor check or later in compute pre-flighyt | |
| 17:01:38 | dansmith | I think if we're going to say it's not allowed, we should prevent it at instance spawn/interface attach right? | |
| 17:01:51 | dansmith | because in this case, a user can do something that prevents an admin from live migrating an instance | |
| 17:01:57 | dansmith | which is not a cool thing to find out later | |
| 17:02:11 | bauzas | then it should be when we attach a port ? | |
| 17:02:14 | dansmith | so if we say "not allowed" it probably needs to be enforced much earlier | |
| 17:02:41 | dansmith | but again, I feel like this is probably something we can/should fix (even if later) with the alias stuff like we did for disks and planned for nics | |
| 17:03:22 | bauzas | right | |
| 17:03:32 | gibi | OK, if preventing it needs a bunch of code then maybe fixing it is comparable complexity (I was on the side of doccing it) | |
| 17:03:37 | dansmith | the disk stuff has fallen out of my brain a bit, but seems like we could use the port uuid as the alias and then we'd be able to match up the port and interface in that code, right? | |
| 17:04:00 | dansmith | gibi: well, I think documenting it also documents "how to prevent your operator from moving your instance around" :) | |
| 17:04:02 | gibi | dansmith: right port uuid is unique in openstack, nic alias is unique in the VM | |
| 17:04:08 | dansmith | yeah | |
| 17:05:04 | gibi | OK I will summarize this discussion back to the bug | |
| 17:05:29 | gibi | I got enough feedback that a simple doc patch will not be enough :) | |
| 17:05:57 | gibi | thanks | |
| 17:06:06 | dansmith | sorry gibi :/ | |
| 17:06:10 | Uggla | gibi thanks to you explaining this. | |
| 17:06:47 | Uggla | We are already overtime, so time to close for this week. | |
| 17:06:57 | cw0306-lee[m] | Hi! I have a question. | |
| 17:07:01 | gibi | dansmith: no worries :) | |
| 17:07:16 | Uggla | cw0306-lee[m] last minute question, please go ahead | |
| 17:07:53 | cw0306-lee[m] | I tried to fix bug and added it to etherpad proposed bugfixes, will they be reviewed in order? | |
| 17:08:55 | Uggla | cw0306-lee[m] we will try. There is no specific order though, really depend on prio and reviewer bandwith. | |
| 17:09:19 | cw0306-lee[m] | Uggla: Thank you! | |
| 17:09:21 | Uggla | readiness too | |
| 17:10:21 | Uggla | ok so now time to close, thanks for joining this meeting. Have a nice day/evening and see you next week. | |
| 17:10:29 | Uggla | #endmeeting | |
| 17:10:29 | opendevmeet | Meeting ended Mon Mar 2 17:10:29 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:10:29 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.html | |
| 17:10:29 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.txt | |
| 17:10:29 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-03-02-16.00.log.html | |
| 17:10:33 | gibi | thanks Uggla | |
| 17:10:36 | elodilles | thanks o/ | |
| 17:11:05 | lajoskatona | o/ | |
| 17:11:09 | Uggla | gibi thanks to you, we have one more bug triaged ! | |
| 17:12:22 | tkajinam | gmaan, regarding that novaclient tests update, do you know any stestr magic to avoid specific tests from being executed concurrently ? | |
| 17:12:25 | tkajinam | https://opendev.org/openstack/python-novaclient/src/branch/master/novaclient/tests/functional/v2/test_quota_classes.py#L79-L107 | |
| 17:13:14 | tkajinam | the problem is that there are few tests accessing quota-class and if we use only the default one then we should refactor these to avoid conflicts among these | |
| 17:15:06 | tkajinam | I'll look into that tomorrow but the test update looks tricky for me now | |
| 17:18:53 | sean-k-mooney | tkajinam: for what its worth even in queens we have notes stating that only the default classs is supproted by nova | |
| 17:18:55 | sean-k-mooney | https://docs.openstack.org/nova/queens/admin/quotas.html#to-update-quota-values-for-an-existing-project | |
| 17:21:16 | sean-k-mooney | https://that.guru/blog/quotas-in-openstack/#quota-classes looking at the history the supprot for this was ripped out in ocata and there was never eally any intree supprot | |
| 17:21:57 | gmaan | tkajinam: for quota concurrent tests, I think you can use LockFixture like tempest is doing https://github.com/search?q=repo%3Aopenstack%2Ftempest%20compute_quotas&type=code | |
| 17:23:14 | gmaan | doing it via stestr also possible but that will be more complicated of grouping them and running in serial mode | |
| 17:25:45 | sean-k-mooney | ya porting the serial decorator is one approch | |
| 17:39:22 | opendevreview | Dominik proposed openstack/nova-specs master: Repurpose NUMA Topology with Resource Providers for 2026.2 https://review.opendev.org/c/openstack/nova-specs/+/978570 | |
| 18:29:12 | Zhan[m] | Hi friends, I have a quick question. Does Nova allow launching/live-migrating VMs to a host with nova-compute disabled? For example, if I want to do a QC before putting the host back to service, I can launch a VM on there with elevated privileges (e.g., using admin credential), make sure everything works, and then finally enable nova-compute. | |
| 18:31:30 | sean-k-mooney | Zhan[m]: no. disbaling a compute node exist to prevent schdulign to the host | |
| 18:31:48 | sean-k-mooney | we enforce this with a frobiden trait via a placment prefilter | |
| 18:33:03 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L243-L255 | |
| 18:34:06 | Zhan[m] | Yeah I saw that earlier too. So the only way is to enable it, launch a VM, disable it, make sure everything's correct, and then re-enable it? | |
| 18:34:58 | sean-k-mooney | normlaly i would suggest using somethign else liek a requried trait to isolate the host or teh tenat affinity filter for exmaple | |
| 18:35:15 | sean-k-mooney | i.e. test it by addign teh host to a host aggreate that can only be used by the admin project | |
| 18:35:46 | sean-k-mooney | https://docs.openstack.org/nova/latest/admin/aggregates.html#tenant-isolation-with-placement | |
| 18:36:40 | sean-k-mooney | so restirct it to your admin project, renebaled it, test it adn then eitehr remove it form teh aggreate or disable it again to do futher maintance | |
| 18:36:47 | Zhan[m] | ahh I see, something like a "maintenance" aggregate where only admin can access | |
| 18:36:56 | sean-k-mooney | yep exactly | |
| 18:37:00 | Zhan[m] | I see, thanks! | |
| 18:38:16 | sean-k-mooney | having a third sate enabeld,disabled and maintance woudl perhaps have been a cleaner way to do that but you can emulate that with aggreates | |
| 18:40:34 | Zhan[m] | I think having a third state make sense too, but both approaches solve the same problem ultimately. Wondering if that can be something to discuss and maybe implement, or aggregate is still the recommended way to go? | |
| 18:43:08 | Zhan[m] | It would be good to put this info somewhere, I can imagine others having this question too. | |
| 18:47:37 | dansmith | being able to target disabled hosts seems reasonable to me, without requiring the aggregate thing | |
| 18:47:47 | dansmith | like, if an admin has disabled a host to prevent regular users from scheduling to it, | |
| 18:48:06 | dansmith | but has (of course) the permission to target hosts specifically either with a boot or a migration, | |
| 18:48:16 | dansmith | it seems totally reasonable to ignore the disabled check for that case | |
| 18:48:42 | dansmith | like if I need to disable a failing host, then send a build to it to see if I've fixed it before I let others go there | |
| 18:48:58 | dansmith | or I disable a host to prevent it from filling up so I can emergency migrate instances to it to escape a failing node | |