| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-05 | |||
| 19:09:34 | sean-k-mooney | but i have no idea if it actully works today with the libvirt driver | |
| 19:09:44 | sean-k-mooney | are they asseting that you can have both on the same host | |
| 19:10:13 | sean-k-mooney | we have config option tha twoudl imply that and the console proxy coudl handel that | |
| 19:10:31 | mikal | To my reading of their comments, they agree you can only have one type per instance, but that different instances can have different console types. I don't think this is true, but maybe I'm on drugs. | |
| 19:10:38 | sean-k-mooney | but teh only time i have mixed it is vnc or spice for livbirt and the serial proxy for ironic | |
| 19:10:56 | mikal | So yeah, I think they think they can mix on a single nova host, not say have different ones per cell. | |
| 19:11:12 | sean-k-mooney | well its not even at the cell level | |
| 19:11:20 | sean-k-mooney | it will work at the indigiual compute node level | |
| 19:11:36 | sean-k-mooney | i can quickly check in devstack i guess | |
| 19:13:18 | mikal | I find https://review.opendev.org/c/openstack/kolla-ansible/+/966111/2/ansible/roles/nova-cell/templates/nova.conf.j2 quite hard to read, but I don't see any logic there which stops it from rendering a nova.conf which has both VNC and SPICE enabled in one nova.conf, which I think we're agreeing wont work? | |
| 19:14:08 | sean-k-mooney | mikal: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7825 | |
| 19:14:20 | sean-k-mooney | so it is posibel in the code to have spice and vnc | |
| 19:14:30 | sean-k-mooney | but you can also conenct via serial too | |
| 19:14:46 | sean-k-mooney | mikal: this alines with what i remember for what its worth | |
| 19:14:50 | sean-k-mooney | its entrily config driven | |
| 19:15:20 | mikal | I didn't think the domain XML could specify both VNC and SPICE, which I think is what that code you link to would do if you enabled both? | |
| 19:15:26 | sean-k-mooney | mikal: no i actully do expect ti to work because that work in libvirt | |
| 19:15:28 | mikal | There's no guard to have only one for a given instance? | |
| 19:15:56 | sean-k-mooney | mikal: im tryign to think if i currently have a debian devstack where i can check this | |
| 19:16:44 | mikal | I am slightly surprised that https://libvirt.org/formatdomain.html#graphical-framebuffers doesn't seem to actually mention any limits. | |
| 19:16:49 | mikal | Huh, maybe I am simply wrong. | |
| 19:19:31 | mikal | I can never tell from the oVirt docs what is a forward looking statement vs what got built, but oVirt appears to have supported this. https://www.ovirt.org/develop/release-management/features/virt/multiple-consoles.html | |
| 19:19:36 | mikal | So yeah, I think I am wrong. | |
| 19:20:33 | sean-k-mooney | to be clear they can enabel that in kolla-ansible without needign any changes to it via config overrieds | |
| 19:20:52 | sean-k-mooney | but it might be nicer not to have to do that | |
| 19:21:30 | mikal | Yeah, I am just going to remove my -1 from that review and bravely run away. I'll let someone else have an opinion on the best way to do things in ansible, that's not really my thing. | |
| 19:23:13 | sean-k-mooney | mikal: https://termbin.com/4c0u | |
| 19:23:39 | sean-k-mooney | so ya nova vm with vnc and spice booted on debian 13 (trixie) | |
| 19:24:19 | mikal | I am comfortable with being wrong here, and will now slink away to pretend none of this happened. | |
| 19:24:29 | mikal | Sorry for bothering you in your evening. | |
| 19:24:39 | sean-k-mooney | mikal: so this is somethign we dont test but can and proably should | |
| 19:24:49 | sean-k-mooney | but tis been a very very long time since i last did this | |
| 19:24:57 | sean-k-mooney | liek eailly 8 + years | |
| 19:25:20 | sean-k-mooney | mikal: dont be sorry | |
| 19:25:25 | sean-k-mooney | its good to know this still works | |
| 19:26:12 | mikal | Yeah, I need to think about it some more. I _could_ add CI for it on the Kerbside side, but its really outside of Kerbside's set of concerns, and I have other priorities like actually getting TLS working right in the Kolla-Ansible role so I can propose it upstream. So I will at it to my backlog and see where that takes me later. | |
| 19:26:24 | mikal | I have to run or I'll be late for work, talk more later. Thanks for your help. | |
| 19:26:34 | sean-k-mooney | we can just enabel it in the job that is currently testing spice | |
| 19:26:58 | sean-k-mooney | mikal: no worreis chat to soon o/ | |
| 19:53:26 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 20:23:07 | opendevreview | Merged openstack/nova master: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | |
| 20:23:20 | opendevreview | Merged openstack/nova master: Add handling for vTPM secret permission error https://review.opendev.org/c/openstack/nova/+/963648 | |
| 20:29:01 | opendevreview | Ghanshyam proposed openstack/nova master: Fix test_simple_tenant_usage test https://review.opendev.org/c/openstack/nova/+/966223 | |
| 20:31:01 | gmaan | zigo: this should fix the issue in test_simple_tenant_usage https://review.opendev.org/c/openstack/nova/+/966223 | |
| #openstack-nova - 2025-11-06 | |||
| 07:44:13 | zigo | gmaan: Thanks ! :) | |
| 07:44:17 | zigo | Saw it, btw. | |
| 07:51:09 | opendevreview | Lajos Katona proposed openstack/nova master: blueprint: iothreads-for-instances https://review.opendev.org/c/openstack/nova/+/939254 | |
| 09:29:43 | gibi | sean-k-mooney: thanks for the review on the native thread defaulting. I answered inline | |
| 09:45:21 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 09:45:22 | opendevreview | melanie witt proposed openstack/nova master: Add vtpm_secret_(uuid|value) to LibvirtLiveMigrateData https://review.opendev.org/c/openstack/nova/+/952628 | |
| 09:45:22 | opendevreview | melanie witt proposed openstack/nova master: TPM: support instances with `host` secret security https://review.opendev.org/c/openstack/nova/+/941795 | |
| 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: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: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: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: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: opt-in to new TPM secret security via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 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:28 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 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: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: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | |
| 10:01:42 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Init event handling before connect https://review.opendev.org/c/openstack/nova/+/966249 | |
| 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 | jkulik | it is set for memory_mb though | |
| 13:20:51 | sean-k-mooney | for floating cpus for example | |
| 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 | on_ratio) | |
| 13:25:19 | jkulik | > placement/objects/allocation_candidate.py: cap = int((usage.total - usage.reserved) * allocati | |
| 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? | |