| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-06 | |||
| 09:45:23 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 09:45:23 | opendevreview | melanie witt proposed openstack/nova master: TPM: bump service version and require it for live migration https://review.opendev.org/c/openstack/nova/+/962051 | |
| 09:45:24 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 09:45:24 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 09:45:25 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 09:45:26 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 09:45:26 | opendevreview | melanie witt proposed openstack/nova master: TPM: opt-in to new TPM secret security via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 09:45:28 | opendevreview | melanie witt proposed openstack/nova master: TPM: add documentation and reno for live migration https://review.opendev.org/c/openstack/nova/+/962889 | |
| 09:45:28 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 09:54:46 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | |
| 09:54:47 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Init event handling before connect https://review.opendev.org/c/openstack/nova/+/966249 | |
| 10:01:42 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Init event handling before connect https://review.opendev.org/c/openstack/nova/+/966249 | |
| 10:01:42 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | |
| 11:03:07 | opendevreview | Stephen Finucane proposed openstack/nova master: pre-commit: Bump versions https://review.opendev.org/c/openstack/nova/+/966089 | |
| 11:43:41 | opendevreview | Nell Jerram proposed openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/960284 | |
| 12:29:20 | opendevreview | Nell Jerram proposed openstack/nova master: Add managed='no' flag to libvirt XML definition for VIF type TAP https://review.opendev.org/c/openstack/nova/+/960284 | |
| 13:06:12 | jkulik | Why is `max_unit` for a resource-provider not reduced by `reserved` (in the libvirt driver)? Seems somewhat inconsistent that it reports something that cannot be achieved. | |
| 13:20:00 | sean-k-mooney | it kind of depends | |
| 13:20:34 | sean-k-mooney | reserved and max_unit are typeicly not set on most invetories differntly form the defuals of 0 and total size | |
| 13:20:51 | sean-k-mooney | for floating cpus for example | |
| 13:20:51 | jkulik | it is set for memory_mb though | |
| 13:21:09 | sean-k-mooney | or we can take that example | |
| 13:21:16 | sean-k-mooney | if you have 100G of ram | |
| 13:21:22 | sean-k-mooney | you reserve 10G | |
| 13:21:30 | sean-k-mooney | and you set allcoation ration to 1.5 | |
| 13:21:40 | sean-k-mooney | then its valid to allow a max unit of 100G | |
| 13:21:43 | sean-k-mooney | but not 101 | |
| 13:21:45 | jkulik | oh, I see | |
| 13:21:52 | sean-k-mooney | becasue we do not allow over allcation against yourself | |
| 13:22:24 | jkulik | I thought of reserved more like "No VM may cut into this, because it's provider-reserved" | |
| 13:22:43 | sean-k-mooney | yes but only if allcation ration is 1.0 | |
| 13:23:03 | sean-k-mooney | we treate reseved basically as if there is an allcoation of that size already present | |
| 13:23:44 | sean-k-mooney | but imporantly we do (total*ratio) - reserved | |
| 13:23:46 | jkulik | but before allocation_ratio is applied (at least in computing the "free" part), right? | |
| 13:23:58 | jkulik | ah. do we? | |
| 13:24:00 | sean-k-mooney | its not (total - reserved) * ratio | |
| 13:24:32 | jkulik | I always thought it would be ^ | |
| 13:24:37 | sean-k-mooney | no reseved it subtracted form total*ratio for backward compatibality | |
| 13:24:43 | sean-k-mooney | becaus that how it worked before placment | |
| 13:25:19 | jkulik | > placement/objects/allocation_candidate.py: cap = int((usage.total - usage.reserved) * allocati | |
| 13:25:19 | jkulik | on_ratio) | |
| 13:26:07 | sean-k-mooney | so https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_memory_mb | |
| 13:26:22 | sean-k-mooney | is directly translated into the reseved value for memory mb | |
| 13:27:06 | jkulik | yes. it's report as-is to Placement | |
| 13:27:54 | sean-k-mooney | and the sematic of that are if you have 50G with allcaotion ration 2.0 and resved 10G we will allwo 90G of usage | |
| 13:27:55 | jkulik | https://github.com/openstack/placement/blob/master/placement/objects/allocation.py#L253 | |
| 13:28:13 | jkulik | so Placement does do (total - reserved) * allocation_ratio | |
| 13:28:26 | sean-k-mooney | that for the allcation size | |
| 13:29:18 | jkulik | that does mean, I can allocate more than total right? as long as I set `max_unit` to more than total? | |
| 13:29:54 | jkulik | but you're saying, `max_unit` is capped at `total` anyways. so that's something else, too. | |
| 13:30:17 | sean-k-mooney | so there is what placement allwos you to model | |
| 13:30:20 | sean-k-mooney | and what nova allows | |
| 13:30:25 | jkulik | hm ... ok, I think I understand why it's allowed in Placemeent now. thanks | |
| 13:30:38 | sean-k-mooney | nova does not allow a singel vm to over subscript the host resocues | |
| 13:30:43 | sean-k-mooney | that is part of our contract | |
| 13:31:12 | sean-k-mooney | that does nto mean its part fo placemetn as that might make sesne to someone. i cant think of a valid reaosn for that but it might be valid | |
| 13:31:26 | sean-k-mooney | i woudl expdect placement ot reject a invetoy whre max_ujnit exceed total | |
| 13:31:31 | sean-k-mooney | but i have not checked if ti does | |
| 13:31:45 | jkulik | Nova does allow going into reserved resources, though, when the admin requests an allocation_ratio > 1.0 | |
| 13:33:05 | sean-k-mooney | correct because again nova expect capastiy = (total * allction ratio) - reserved | |
| 13:33:05 | jkulik | Which can make sense for VCPUs, but imho does not make much sense for MEMORY_MB. I wouldn't want my hypervisor to start swapping, because an overcommitted VMs uses all of its RAM. | |
| 13:34:26 | jkulik | and since Placement takes care with the capacity check that things fit, adding a lot of logic in Nova libvirt to report different "max_unit" depending on the allocation_ratio doesn't really make sense | |
| 13:34:29 | sean-k-mooney | so we have docuemtned in nova in the past tha tyou have to multiply host_reserved_ram by the allcation ratio in the config | |
| 13:35:27 | sean-k-mooney | although its not very clear i guess if you jsut look at the config ref | |
| 13:35:35 | sean-k-mooney | so we coudl defintly improve that | |
| 13:35:36 | jkulik | I feel like that would break the allocation capacity check in Placement. | |
| 13:35:59 | sean-k-mooney | i am debating if that is a placement bug | |
| 13:36:19 | sean-k-mooney | the check looks incorect to me jsut lookign at that capstiy line but | |
| 13:36:25 | sean-k-mooney | i have not revied the code properly to say | |
| 13:37:09 | jkulik | the discussion was helpful for me nonetheless. thank you | |
| 13:38:43 | sean-k-mooney | https://github.com/openstack/nova/blob/rocky-eol/nova/scheduler/filters/ram_filter.py#L32-L65 | |
| 13:38:51 | sean-k-mooney | this is what nova used to do before placement | |
| 13:39:41 | sean-k-mooney | placement is ment ot be 1:1 compatible with that | |
| 13:40:02 | jkulik | so what*s "total_usable_ram_mb" here? | |
| 13:40:31 | sean-k-mooney | i was hoping you woudl not ask that :P | |
| 13:40:55 | sean-k-mooney | but its https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L217 | |
| 13:40:57 | jkulik | `compute.memory_mb` ... one more step | |
| 13:41:22 | sean-k-mooney | ya so that is just the total ram on the host | |
| 13:41:37 | sean-k-mooney | at least i think it is | |
| 13:42:31 | jkulik | ah, yes. We patched that downstream to properly include the reserved_host_memory_mb :D | |
| 13:42:52 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L9445 | |
| 13:42:58 | jkulik | it indeed used the reserved_host_memory_mb only as "usage", not as real reduction of the available memory. | |
| 13:43:12 | sean-k-mooney | right | |
| 13:43:26 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1150-L1158 | |
| 13:43:32 | sean-k-mooney | so that is what determisn it upstream | |
| 13:43:41 | jkulik | which is inconsitent with what the vmware driver reports to Placement ... at least in our version :D | |
| 13:43:58 | sean-k-mooney | its either the file backed memory size if your using that or basically the ouput of total memory form free or in thsi cashe virsh capabliteis i belive | |
| 13:44:03 | jkulik | yeah, I read that part. that's fine. just `max_unit` seemed off to me | |
| 13:44:16 | sean-k-mooney | jkulik: well that is the other thing | |
| 13:44:25 | sean-k-mooney | this is virt driver defiened | |
| 13:44:37 | sean-k-mooney | at least to some degree | |
| 13:44:42 | jkulik | why we even looked at that was: we use hugepages from a static pool and libvirt reports not that, but the full memory of the host ... | |
| 13:44:49 | sean-k-mooney | you can use provider.yaml to overried max unit | |
| 13:45:04 | jkulik | hm! | |
| 13:45:23 | sean-k-mooney | well for hugepages you confirue the reservation diffently | |
| 13:45:49 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reserved_host_memory_mb | |
| 13:45:54 | sean-k-mooney | per page size per numa node | |
| 13:46:26 | sean-k-mooney | if you use hw:mem_page_size=small we also use the values form reserved_huge_pages for the system native size i.e. 4 | |
| 13:46:29 | sean-k-mooney | for 4k | |
| 13:47:13 | sean-k-mooney | so if your doing anythign related to numa you are not allowed to oversibcsribe memory | |