Earlier  
Posted Nick Remark
#openstack-nova - 2025-07-16
15:45:29 sean-k-mooney the protocol is ment to imply --tls i think although there are 2 qemu connection to consier. you have teh conenction to your local libvirt and the connection to the remote one
15:45:43 noonedeadpunk yes, right, qemu/libvirt fix would be really nice, though I'd guess the lead time might be even higher then waiting for spec to merge
15:45:43 sean-k-mooney it hink --tls is specifying that tls shoudl be used for the remote one
15:46:37 noonedeadpunk sean-k-mooney: well. it seems so, but qemu+tls://compute10/system - compute10 is a remote host...
15:46:55 sean-k-mooney also to be fair i never actully use virsh to do migration manullly so im not famiarly with the specific here
15:47:11 noonedeadpunk and also I have listen_tls = 1 and listen_tcp = 0 for /etc/libvirt/libvirtd.conf
15:47:14 noonedeadpunk so wtrf...
15:48:09 noonedeadpunk probably I should try going to their IRC with this though
15:50:47 sean-k-mooney https://libvirt.org/migration.html implie that the uri si enough but it does nto say one way or another
15:51:25 sean-k-mooney there is a way to force the use fo tls via migrate_tls_force in /etc/libvirt/qemu.conf but that shoudl nto be required espically with nova
15:53:00 sean-k-mooney oh right you use -c to specify the locall connection to virsh
15:54:08 noonedeadpunk sean-k-mooney: https://gitlab.com/qemu-project/qemu/-/issues/1937
15:58:42 sean-k-mooney oh you found a 2023 issue in qemu
16:01:13 noonedeadpunk yeah
16:01:20 sean-k-mooney looks like dan bareeange is activlly engaged
16:01:35 sean-k-mooney i can mentio nto him that this affect nova as well today
16:01:39 noonedeadpunk and they in #virt suggesting using parallel as general rule
16:01:51 sean-k-mooney they also recommended multi-fd migration
16:02:18 sean-k-mooney so thats another reason to consider your proposal and add supprot in nova
16:04:18 noonedeadpunk yeah, I will work on it tomorrow then :)
16:18:43 sean-k-mooney noonedeadpunk: so there is a possibel workaround via cofnig files assuming you do not need fips
16:19:33 sean-k-mooney noonedeadpunk: i was talking to danpb downstream about this and https://issues.redhat.com/browse/RHEL-103240?focusedId=27595864&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27595864 is a workaround
16:20:04 sean-k-mooney noonedeadpunk: you can disabel AES as one fo the allowed encyption methods
16:20:26 noonedeadpunk ah, he mentioned that in IRC actually
16:21:02 noonedeadpunk but thanks for pointing to that report
16:21:15 sean-k-mooney that breaks fips compliance but it might eb a better option then a downstream code change if its somethign that was accpable form a secuirty perspective until the issue is fixed properly
16:21:21 noonedeadpunk I think I will try it, as all other options are kinda not perfect
16:21:50 noonedeadpunk I don't want tunneled migrations as we are have local storages here and there
16:22:09 noonedeadpunk and parallel and compress both not solving issue but making it more distant
16:22:25 noonedeadpunk so it's a question of how big and loaded VM should be
16:23:38 sean-k-mooney well as someone who prefers the simple life of migratin unlooed cirros iamges in my devstack small an light :) but customer want to run real workloads, how unreasonabel :)
16:23:42 noonedeadpunk It's also a question if there could be more side-effects from disabling aes
16:24:22 sean-k-mooney so there are some, if you dont use aes and use one of the other algroatims you may not be able to leverage aes-ni or similer exteions to offload the encyprtion to hardware
16:24:49 noonedeadpunk yeah, and we start talking if customer moved from VMWare with their 1Tb MSSQL with 200gb of ram...
16:24:52 sean-k-mooney the side effect of that would be a bottelneck on througput
16:25:21 noonedeadpunk yeah, but there's also like OVN on host likely using AES as well
16:25:32 sean-k-mooney i remember jay pipes talking about one of the customers mirantas had wehre they litrally ran 1 VM per compute node that used all the cpus/ram
16:25:38 noonedeadpunk or well, ovs
16:26:22 sean-k-mooney the litrally just wanted to have an api to create/delete vms effectivly and provide some levle of security via a vm absrction
16:26:29 noonedeadpunk I wonder how scheduling work for them if they need to evacuate the VM on hypervisor failure
16:26:47 sean-k-mooney hopefully they had hot spares
16:27:04 sean-k-mooney as in free hosts
16:27:18 sean-k-mooney so i beliv ethis dropin file is specific to qemu
16:27:34 sean-k-mooney i.e. its createing /etc/crypto-policies/local.d/gnutls-qemu.config
16:27:48 sean-k-mooney but it woudl apply to all tls coonection use by qemu fro anything it doing
16:28:07 sean-k-mooney but again im not an experit on this so that may be incorrect
16:28:14 noonedeadpunk well, this would be fine then
16:28:42 noonedeadpunk I was a bit more, if crypto-policies just do fileglob of /etc/crypto-policies/local.d/*.config
16:28:50 noonedeadpunk but will check on that
16:29:04 sean-k-mooney i think that is what the QEMU= at the start of it is doing not the file name
16:29:11 sean-k-mooney but again i have not looked into this deaply at all
16:30:04 noonedeadpunk actually, I'd argue that using CHACHA-POLY1305 should be faster then AES
16:32:17 sean-k-mooney it depend aes on sufficlty new enough intel chips will be done in dedicated hardware espiclly if you have access to qat acclerators
16:32:46 sean-k-mooney but it might be faster and you will really only knwo once your try it on your hardware
16:36:59 noonedeadpunk I tottally need to sleep over with all this info
17:19:22 opendevreview Merged openstack/nova master: FUP: Translate scatter-gather to futurist https://review.opendev.org/c/openstack/nova/+/953338
17:19:33 opendevreview Merged openstack/nova master: Add Project Manager role context in unit tests https://review.opendev.org/c/openstack/nova/+/941056
#openstack-nova - 2025-07-17
08:50:05 ralonsoh Hi folks, qq about tempest
08:50:11 ralonsoh I've pushed a patch for devstack
08:50:19 ralonsoh https://review.opendev.org/c/openstack/devstack/+/955187
08:51:04 ralonsoh And tempest-full-py3, devstack-platform-ubuntu-jammy or nova-ceph-multistore are failing in the same 2 tests
08:51:26 ralonsoh --> https://zuul.opendev.org/t/openstack/build/61d7370a71494a2192ee60cfc4eb6cc3/logs
09:25:29 ralonsoh gibi, ^
09:29:27 ralonsoh Ehhhh sorry. Sorry for the noise: because of this patch (^ the one that triggered this log), we are not deploying the OVN agent
09:29:36 ralonsoh please, disregard my comments...
10:40:28 stephenfin gmaan: sean-k-mooney: If you have time today, could you look at https://review.opendev.org/c/openstack/nova/+/952284/ The patches above it are in merge conflict and will need a rebase, but it'd be good get everything below that in first
10:43:04 opendevreview Stephen Finucane proposed openstack/nova master: Migrate mypy configuration to pyproject.toml https://review.opendev.org/c/openstack/nova/+/953703
10:43:05 opendevreview Stephen Finucane proposed openstack/nova master: Migrate codespell configuration to pyproject.toml https://review.opendev.org/c/openstack/nova/+/953704
10:43:06 opendevreview Stephen Finucane proposed openstack/nova master: setup: Remove pbr's wsgi_scripts https://review.opendev.org/c/openstack/nova/+/902688
10:43:06 opendevreview Stephen Finucane proposed openstack/nova master: Migrate setup configuration to pyproject.toml https://review.opendev.org/c/openstack/nova/+/953705
10:44:59 sean-k-mooney stephenfin: sure
11:19:44 gibi ralonsoh: no worries :)
14:12:45 opendevreview Kamil Sambor proposed openstack/nova master: Replace eventlet.event.Event with threading.Event https://review.opendev.org/c/openstack/nova/+/949754
15:21:36 gmaan stephenfin: ack, not sure if I can do today and I am on PTO tomorrow. But I will do early next week. not just this but the remaining series
15:22:19 stephenfin nw. doesn't look like they will merge anytime soon. The gate is super unstable :(
15:23:10 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.1: Add ServersViewBuilderTestV296 unit test class https://review.opendev.org/c/openstack/nova/+/955304
15:23:11 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.1: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/955305
16:17:59 opendevreview Merged openstack/nova master: Move ConductorManager to use spawn_on https://review.opendev.org/c/openstack/nova/+/948187
16:29:25 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.2: Add ServersViewBuilderTestV296 unit test class https://review.opendev.org/c/openstack/nova/+/955309
16:29:26 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.2: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/955310
#openstack-nova - 2025-07-18
04:24:07 aravindh5murugesan Hello folks. I'm running into a problem when I set CPU models to custom and the specifying the models. The default config that we receive from our vendor sets the cpu-model to broadwell-notsx-IBS something. But our CPU model is saphirerapids and the oldest we need to support is Icelake. But When I set it to Icelake or SaphireRapids, I used the same name as listed in virsh cpu-models, but nova complains that CPU
04:27:37 aravindh5murugesan can assist me here. 2025-07-17 20:44:36.072 ERROR oslo_service.service [req-fa1ce5c0-d687-4d09-ac10-7ca05eb98461 None None] Error starting thread.: nova.exception.InvalidCPUInfo: Configured CPU model: SapphireRapids-noTSX and CPU Flags [] ar not compatible with host CPU. Please correct your config and try again. Unacceptable CPU info: CPU doesn't have compatibility
04:28:08 aravindh5murugesan CPU model in hypervisor - Vendor ID: GenuineIntel Model name: Intel(R) Xeon(R) Silver 4416+
09:09:51 sean-k-mooney aravindh5murugesan the problem you are having is that icelake has feature flags like tsk tha tintel disabled in microcode and does tno supprot on saphire rapids
09:11:11 sean-k-mooney *like the flags for tsx that intel ...
10:53:08 opendevreview Takashi Kajinami proposed openstack/nova master: Drop unused parameter type validation method https://review.opendev.org/c/openstack/nova/+/909189
12:03:33 aravindh0murugesan sean-k-mooney: In that case, would it possible to disable those unsupported flags and somehow make this work?
12:20:19 sean-k-mooney yes there are 2 ways, libvirt provide some custom models for older cpu i.e. the *-notsx-IBS variants
12:20:36 sean-k-mooney but nova also has a config option that allows you to add/remove cpu flags
12:37:05 aravindh0murugesan I compared the icelake.xml and my lscpu flags and found these flags are missing in my host cpu - avx512vnni,mpx,pclmuldq,spec-ctrl,sse4.1,sse4.2,tsc-deadline,
12:37:18 aravindh0murugesan so I just do a - on these flags in nova configs?
12:38:45 aravindh0murugesan cpu_models = Cascadelake-Server-noTSX cpu-model-extra-flags = -avx512vnni,-mpx,-pclmuldq,-spec-ctrl,-sse4.1,-sse4.2,-tsc-deadline this does not work either
12:44:45 aravindh0murugesan sean-k-mooney: Editing the XML to say removed='yes' kinda worked. But I'm not sure if this is the suggested way to do things.
12:58:38 aravindh0murugesan My bad, changing this cpu-model-extra-flags to snake case fixed it. Thanks.
13:23:40 sean-k-mooney ack so you were able to get this wokring
13:25:27 sean-k-mooney and yes https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_model_extra_flags is the cofnig opiton
13:26:13 sean-k-mooney by the wya i have alwasy know cpu_model_extra_flags as SLUG case and cpu-model-extra-flags as snake case
13:28:24 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.2: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/955310
13:28:39 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.1: Add ServersViewBuilderTestV296 unit test class https://review.opendev.org/c/openstack/nova/+/955304
13:28:40 opendevreview Wesley Hershberger proposed openstack/nova stable/2024.1: Use dict object for request_specs_dict in the _list_view https://review.opendev.org/c/openstack/nova/+/955305

Earlier   Later