Monday, 2021-03-22

*** rcernin has joined #openstack-nova00:14
*** Techy2493 has quit IRC00:21
*** rcernin has quit IRC00:22
*** ircuser-1 has quit IRC00:22
*** rcernin has joined #openstack-nova00:22
*** tosky has quit IRC00:26
*** LinPeiWen has joined #openstack-nova00:55
*** swp20 has joined #openstack-nova01:53
*** swp20 has quit IRC02:05
*** sapd1 has joined #openstack-nova02:19
*** macz_ has joined #openstack-nova03:17
*** psachin has joined #openstack-nova03:22
*** macz_ has quit IRC03:22
*** rcernin has quit IRC03:22
*** mkrai has joined #openstack-nova03:24
*** hemanth_n has joined #openstack-nova03:27
*** rcernin has joined #openstack-nova04:02
*** rcernin has quit IRC04:07
*** tinwood has quit IRC04:10
*** mkrai has quit IRC04:10
*** tinwood has joined #openstack-nova04:13
*** mkrai has joined #openstack-nova04:15
*** rcernin has joined #openstack-nova04:48
*** rcernin has quit IRC04:48
*** sapd1 has quit IRC04:53
*** vishalmanchanda has joined #openstack-nova05:11
*** rcernin has joined #openstack-nova05:26
*** whoami-rajat_ has joined #openstack-nova05:51
*** khomesh24 has joined #openstack-nova06:17
*** ralonsoh has joined #openstack-nova06:43
*** gokhani has joined #openstack-nova06:49
*** Luzi has joined #openstack-nova07:02
Luzigibi: i made a backport to victoria as you told me: https://review.opendev.org/c/openstack/nova/+/78121107:04
*** pawan-gupta_ has joined #openstack-nova07:36
*** mkrai has quit IRC07:39
*** mkrai_ has joined #openstack-nova07:39
*** slaweq has quit IRC07:40
pawan-gupta_Hi, I am trying to create an instance using `adminPass` option and `nova.conf` is updated with `inject_password = True` but the provided password in `adminPass` does not work. I am using KVM hypervisor. Am I missing something?07:42
*** slaweq has joined #openstack-nova07:46
*** ociuhandu has joined #openstack-nova07:46
fricklerpawan-gupta_: are you running under py3? iirc this feature is broken there, check for errors in your logs07:49
gibiLuzi: awesome, thank you. I've added two stable cores to the review to get it merged :)07:52
Luzigibi, thank you :)07:52
*** ociuhandu has quit IRC07:52
gibifrickler: I guess you are referring to https://review.opendev.org/c/openstack/nova/+/78121107:56
gibifrickler: sorry07:56
gibinot that07:56
gibifrickler: this https://bugs.launchpad.net/nova/+bug/188242107:56
openstackLaunchpad bug 1882421 in OpenStack Compute (nova) "inject_password fails with python3" [Medium,Confirmed]07:56
*** mkrai_ has quit IRC07:58
*** khomesh24 has quit IRC08:08
*** andrewbonney has joined #openstack-nova08:13
*** rpittau|afk is now known as rpittau08:19
*** rcernin has quit IRC08:23
openstackgerritBalazs Gibizer proposed openstack/nova master: trivial: fix word duplication in api ref  https://review.opendev.org/c/openstack/nova/+/78202808:25
*** mkrai has joined #openstack-nova08:28
gibibauzas: hi! the rpc bump is in merge conflict08:28
*** sapd1 has joined #openstack-nova08:29
pawan-gupta_frickler: thanks for the response but I am running it under py2.7.508:31
*** ociuhandu has joined #openstack-nova08:33
*** ociuhandu has quit IRC08:38
*** tosky has joined #openstack-nova08:49
*** ociuhandu has joined #openstack-nova08:56
*** lucasagomes has joined #openstack-nova08:56
*** rcernin has joined #openstack-nova08:58
*** macz_ has joined #openstack-nova09:02
*** macz_ has quit IRC09:06
*** sapd1 has quit IRC09:12
*** ociuhandu has quit IRC09:18
*** mkrai has quit IRC09:22
*** mkrai_ has joined #openstack-nova09:22
*** derekh has joined #openstack-nova09:27
*** rcernin has quit IRC09:37
*** ociuhandu has joined #openstack-nova09:44
*** ociuhandu has quit IRC09:46
*** ociuhandu_ has joined #openstack-nova09:46
openstackgerritBalazs Gibizer proposed openstack/nova master: Add compute rpc version alias for wallaby as 5.13  https://review.opendev.org/c/openstack/nova/+/78211509:49
*** viks____ has joined #openstack-nova09:56
bauzasgibi: yup, I need to rebase it09:58
bauzasgibi: I'm working on the prelude atm09:58
gibibauzas: ack, thanks10:03
*** sapd1 has joined #openstack-nova10:04
*** links has joined #openstack-nova10:06
*** dtantsur|afk is now known as dtantsur10:06
openstackgerritBalazs Gibizer proposed openstack/nova master: Update min supported service version for Xena.  https://review.opendev.org/c/openstack/nova/+/78217110:13
*** mkrai_ has quit IRC10:13
*** ociuhandu_ has quit IRC10:16
*** mkrai has joined #openstack-nova10:16
openstackgerritSylvain Bauza proposed openstack/nova master: Wallaby 22.0.0 prelude section  https://review.opendev.org/c/openstack/nova/+/78217210:17
bauzasgibi: first round of prelude ^10:17
gibibauzas: on it :) thank you10:17
bauzasI need to dad taxi10:17
bauzasgibi: do we have deprecations or removals this cycle ? AFAIK, nope10:17
* bauzas disappears for 20 mins-ish10:17
gibibauzas: I will check that but I don't remember any deprecation10:22
lyarwoodgibi / bauzas ; do workarounds count?10:28
* lyarwood isn't sure if you're just talking about configurable deprecations or feature deprecation10:29
*** stephenfin has joined #openstack-nova10:33
*** ociuhandu has joined #openstack-nova10:34
*** ociuhandu has quit IRC10:36
*** ociuhandu has joined #openstack-nova10:37
*** ociuhandu has quit IRC10:37
*** ociuhandu has joined #openstack-nova10:38
*** ociuhandu has quit IRC10:38
*** ociuhandu has joined #openstack-nova10:38
*** ociuhandu has quit IRC10:38
*** ociuhandu has joined #openstack-nova10:40
gibilyarwood: it is in context of the reno prelude. If this is an important to highlight in the prelude then lets do that10:42
lyarwoodgibi: it already has it's on releasenote so I wouldn't bother tbh, I just wasn't sure what the criteria was for the prelude10:42
gibiI think there are no hard criterias10:43
*** ociuhandu has quit IRC10:43
*** ociuhandu has joined #openstack-nova10:44
MrClayPoleHi, We are looking to start regular "apt" patching in our test environment we a view of pushing to production. Currently we are running on Ubuntu 18.04.1 with OSA Rocky in test. Is there anything we need to be aware or look at first before we start testing from a Nova prospective? I believe there may have been some issue is the past with live migration? Is that still an issue?10:51
gibiMrClayPole: I suggest to read https://docs.openstack.org/nova/latest/user/upgrade.html10:53
MrClayPoleThanks I'll take a look10:53
gibiMrClayPole: and also suggest to read the relese notes related to the version you are upgrading to https://docs.openstack.org/releasenotes/nova/10:53
*** mgariepy has quit IRC10:54
*** brtknr has quit IRC10:56
*** mkrai has quit IRC11:00
*** gokhani has quit IRC11:02
*** stephenfin has quit IRC11:04
*** stephenfin has joined #openstack-nova11:05
*** rcernin has joined #openstack-nova11:13
*** ociuhandu has quit IRC11:18
*** rcernin has quit IRC11:18
*** ociuhandu has joined #openstack-nova11:28
*** ociuhandu has quit IRC11:30
*** ociuhandu has joined #openstack-nova11:31
*** sapd1 has quit IRC11:38
*** rcernin has joined #openstack-nova11:44
*** mkrai has joined #openstack-nova11:56
*** mgariepy has joined #openstack-nova12:02
*** whoami-rajat_ is now known as whoami-rajat12:04
*** artom has joined #openstack-nova12:05
*** ociuhandu has quit IRC12:09
*** rcernin has quit IRC12:31
*** rcernin has joined #openstack-nova12:31
gibibauzas: left feedback in the reno prelude12:32
*** ociuhandu has joined #openstack-nova12:39
*** jamesdenton has quit IRC12:48
*** jamesdenton has joined #openstack-nova12:49
*** ociuhandu has quit IRC13:02
*** gokhani has joined #openstack-nova13:04
*** psachin has quit IRC13:04
*** pawan-gupta_ has quit IRC13:05
*** brinzhang has joined #openstack-nova13:05
*** ociuhandu has joined #openstack-nova13:08
*** hemna has quit IRC13:18
*** hemna has joined #openstack-nova13:18
*** hemanth_n has quit IRC13:20
*** hemna has quit IRC13:30
*** tbachman has joined #openstack-nova13:30
*** hemna has joined #openstack-nova13:30
*** hemna has quit IRC13:36
*** amodi has joined #openstack-nova13:37
*** sean-k-mooney has joined #openstack-nova13:37
*** hemna has joined #openstack-nova13:39
*** lpetrut has joined #openstack-nova13:41
*** ociuhandu has quit IRC13:44
*** ociuhandu has joined #openstack-nova13:46
*** ociuhandu has quit IRC13:46
*** ociuhandu has joined #openstack-nova13:49
*** ociuhandu has quit IRC13:50
*** ociuhandu has joined #openstack-nova13:50
lyarwoodelod / melwitt / bauzas ; some stable/victoria changes ready for review if anyone has time btw - https://review.opendev.org/c/openstack/nova/+/773320 https://review.opendev.org/c/openstack/nova/+/772480 https://review.opendev.org/c/openstack/nova/+/773320 https://review.opendev.org/c/openstack/nova/+/773321/13:53
* lyarwood is trying to burn down his stable backlog of reviews13:53
lyarwoodif there's anything I can review in return let me know!13:53
*** ociuhandu has quit IRC13:55
*** ociuhandu has joined #openstack-nova13:58
*** ociuhandu has quit IRC14:00
elodlyarwood: ack, will try to review some14:00
*** ociuhandu has joined #openstack-nova14:01
*** jhesketh has quit IRC14:02
*** jhesketh has joined #openstack-nova14:04
*** rcernin has quit IRC14:05
*** luksky has joined #openstack-nova14:16
*** ociuhandu_ has joined #openstack-nova14:21
*** ociuhandu has quit IRC14:22
*** ociuhandu has joined #openstack-nova14:23
*** ociuhand_ has joined #openstack-nova14:24
*** ociuhandu has quit IRC14:24
*** ociuhandu has joined #openstack-nova14:25
*** ociuhandu_ has quit IRC14:26
*** ociuhand_ has quit IRC14:28
gibicores, as far as I see we have a sort of rule that only admin can list deleted instances. What about soft-delete instances? As far as I see today only admins can list soft-delete instances. So a user knows the uuid of its accidentally deleted server then they can restore it but if they only know the name of the server then there is no way for the user to list the soft-delete instances to find out14:31
gibiwhich one they want to restore14:31
*** sapd1 has joined #openstack-nova14:31
*** ociuhandu_ has joined #openstack-nova14:33
gibiso if I know the uuid then I can show it and restore it, but if I only know the name then there is no way I can find the uuid14:34
*** ociuhandu has quit IRC14:34
*** ociuhand_ has joined #openstack-nova14:34
*** lbragstad__ is now known as lbragstad14:36
*** ociuhandu_ has quit IRC14:38
*** jangutter_ has joined #openstack-nova14:39
*** jangutter has quit IRC14:42
gibiwe do not list soft-delete vms by default https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/db/sqlalchemy/api.py#L1557 and a filter like vm_state=soft-delete does not change this14:43
sean-k-mooneygibi: im not sure that only admin can list deleted instance or at least all info about them14:43
sean-k-mooneygibi: what im thinking about is the simple tenant usage api14:43
sean-k-mooneywhere the interval will include the usage for deleted instancen that were active in that interval14:44
sean-k-mooneywe may or may not require admin for listing them normally, havent check the api ref14:44
gibisean-k-mooney: https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/api/openstack/compute/servers.py#L26814:44
sean-k-mooneybut normal teant shave at least limited awarenes14:44
*** jraju__ has joined #openstack-nova14:45
gibiso GET /servers does not return deleted instances to non admins14:45
sean-k-mooney gibi  are you sure that takes effect if you use v214:45
*** links has quit IRC14:45
sean-k-mooneyi guess it should14:46
sean-k-mooney"Show deleted items only. In some circumstances deleted items will still be accessible via the backend database, however there is no contract on how long, so this parameter should be used with caution. 1, t, true, on, y and yes are treated as True (case-insensitive). Other than them are treated as False.14:47
sean-k-mooneyThis parameter is only valid when specified by administrators. If non-admin users specify this parameter, it is ignored.14:47
sean-k-mooneyso ya admin only in the api ref too14:47
gmannyes, for v2 or v2.1, deleted instances are admin only14:48
gibiand I agree that we cannot garantee data about deleted instances14:48
gibiso there admin onlyness is OK to me14:48
sean-k-mooneyyep same14:49
gibibut soft-delete instances are always kept in the db so there we could return them to the owner14:49
sean-k-mooneysoft delete is not even guarentted by the api14:49
sean-k-mooneywell isnt soft delete resoration an admin only api too14:49
gibino14:49
gibisoft delete is allowed to owner14:50
gmannyeah admin-or-owner14:50
gibiPolicy defaults enable only users with the administrative role or the owner of the server to perform this operation14:50
gibiyepp14:50
sean-k-mooneyah https://docs.openstack.org/api-ref/compute/?expanded=list-servers-detail,restore-soft-deleted-instance-restore-action-detail#restore-soft-deleted-instance-restore-action14:50
sean-k-mooneyPolicy defaults enable only users with the administrative role or the owner of the server to perform this operation.14:51
gibialso GET /servers/<uuid> returns the soft-delete instance for the owner14:51
gibijust GET /servers doesn't14:51
gibiand GET /servers/details14:51
sean-k-mooneyi mean i guess it would be oke to list your soft-deleted instances14:51
gibiyeah I feel the same ^^14:51
sean-k-mooney{14:52
sean-k-mooney    "restore": null14:52
gmannas long as they know uuid they can get it via GET /servers/<uuid>14:52
sean-k-mooney}14:52
gibiyes14:52
gibiif you know the uuid you can restore it14:52
sean-k-mooney... this looks like another case where we force null instead of allowing restore: {}14:52
gmannsean-k-mooney: that inconsistency is in our most of the action APIs14:53
*** dklyle has joined #openstack-nova14:53
*** dansmith has quit IRC14:53
sean-k-mooneygmann: yep im hoping we fix that sooner rather then later and allow {} everhwere null is allowed today14:53
sean-k-mooneyto correct the regression we intoduced a few years ago in this regard14:54
gmannyeah14:54
sean-k-mooneythats said customer have not completed about it so low priority14:54
gmanngibi: sean-k-mooney +1 on returning soft deleted instances in GET /servers GET /servers/detail14:54
*** Luzi has quit IRC14:55
gibigmann: thanks14:56
sean-k-mooneygmann: does changing the policy rule require a microverions14:56
gmannsean-k-mooney: no.14:56
sean-k-mooneyor can it be made admin_or_owner14:56
sean-k-mooneyok14:56
gmannsean-k-mooney: this is code check not policy14:56
sean-k-mooneywell yes14:57
gmannhttps://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/api/openstack/compute/servers.py#L26514:57
sean-k-mooneybut we should still be limiting it to admin_or_owner right14:57
sean-k-mooneye.g. i should not be able to list your deleted instances14:57
gmannbut it is same things, we are just opening the permission here. no new filed added in response or return code change14:57
sean-k-mooneyso we should likely remove the code check and contol it via policy14:57
openstackgerritSylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0  https://review.opendev.org/c/openstack/nova/+/76145214:58
gmannsean-k-mooney: exactly. hard code is_admin are not so good14:58
*** dansmith has joined #openstack-nova14:58
bauzasgibi: rebased the compute RPC API change https://review.opendev.org/c/openstack/nova/+/76145214:58
gibibauzas: ack, looking14:58
* bauzas looks at gibi's comments for the prelude14:58
gmannsean-k-mooney: and that is one of the next step after new secure rbac, to remove all is_admin hard coded checks from everywhere(API or DB etc)14:59
*** whoami-rajat has quit IRC15:00
*** macz_ has joined #openstack-nova15:01
*** macz_ has quit IRC15:01
*** macz_ has joined #openstack-nova15:02
sean-k-mooneyyep makes sense15:04
stephenfinmelwitt: Can you look at https://review.opendev.org/c/openstack/osc-placement/+/743976 again today? Looks like gibi is waiting on you to spin back around to it first15:06
melwittstephenfin: yes, sorry, I had meant to look at that friday but didn't :( I will look today15:07
stephenfinAll good. Thanks!15:08
*** mgariepy has quit IRC15:12
*** lpetrut has quit IRC15:18
*** ralonsoh has quit IRC15:21
*** __ministry1 has joined #openstack-nova15:23
*** martinkennelly has joined #openstack-nova15:23
*** mgariepy has joined #openstack-nova15:24
*** ralonsoh has joined #openstack-nova15:27
*** mkrai has quit IRC15:28
*** mgariepy has quit IRC15:31
*** __ministry1 has quit IRC15:40
*** mlavalle has joined #openstack-nova15:48
*** links has joined #openstack-nova15:49
*** jraju__ has quit IRC15:49
*** vishalmanchanda has quit IRC16:11
*** manuvakery1 has joined #openstack-nova16:13
*** mgariepy has joined #openstack-nova16:22
openstackgerritSylvain Bauza proposed openstack/nova master: Wallaby 23.0.0 prelude section  https://review.opendev.org/c/openstack/nova/+/78217216:28
bauzasdansmith: gibi: thanks for looking at the prelude, updated ^16:28
bauzasarf, just saw stephenfin's comments16:29
sean-k-mooneystephenfin: melwitt  coul ye take a look at the discussion at https://review.opendev.org/c/openstack/nova/+/769614/2//COMMIT_MSG#18 again16:29
stephenfinwill do16:29
openstackgerritSylvain Bauza proposed openstack/nova master: Wallaby 23.0.0 prelude section  https://review.opendev.org/c/openstack/nova/+/78217216:30
sean-k-mooneystephenfin: melwitt  now that we are passed FF and i have a littel brain power back i have 3 bugs i would like to make progress on https://review.opendev.org/c/openstack/nova/+/769614, https://review.opendev.org/c/openstack/nova/+/777679 and https://review.opendev.org/c/openstack/nova/+/60243216:32
melwittsean-k-mooney: I have been watching the discussion but not really understanding what's going on. all I know is experts on numa are disagreeing :) and I was thinking with discussion maybe a new option that yall agree would be possible16:33
sean-k-mooneymelwitt: ack, my view is the proported optimisation was never valid or functional in any meaningful way and it was broken by design16:34
*** penick has joined #openstack-nova16:35
*** penick has quit IRC16:35
*** penick has joined #openstack-nova16:35
sean-k-mooneyi think alex agreed with the design part in his last comment but was unsure if the optimiasation acutlly provided a performance imporment16:35
manuvakery1Hi.  what could be a acceptable load average on compute host. I can see its  consistently between 30-40  when i stress the vm with same no of cores as compute host16:36
sean-k-mooneyand stephenfin  was concerend about a regression in functionality and belive the optimisation may have been valid in some cases16:36
*** lpetrut has joined #openstack-nova16:37
melwittah, ok16:37
sean-k-mooneyif you have 40 cores then a load average of 40 means you are fully utilising the system and not over stressing the cpus16:37
sean-k-mooneymanuvakery1:^16:37
sean-k-mooneyso a load average fo <= number of cores meens you are below or at capasity16:38
manuvakery1its a 48 core host16:38
sean-k-mooneyif you exceed it it means there is contention between prcoess to execute  cpu instrucutions16:38
sean-k-mooneymanuvakery1: 30-40 is prefectly accpable in that case16:38
manuvakery1thanks sean-k-mooney16:38
sean-k-mooneyif the load avergae exceed core count it means the vms are under perferoming because they are cpu starved16:39
sean-k-mooneythat may or may not matter depening on your use case but i would not be concerned with your current values16:39
*** ociuhand_ has quit IRC16:42
*** ociuhandu has joined #openstack-nova16:43
manuvakery1that means when using cpu over commit,  I can expect high load average and my vms  can under  perform when all are trying to gather cpu . I am ok if my vms are performing  little slow but don't want my host machine to be non responsive16:43
kashyapstephenfin: I take it that when you move content, you're _only_ moving content -- or are you also mixing in little fix-ups?16:43
kashyapstephenfin: E.g. I'm looking at the SEV guide16:44
stephenfinI might fix spellings and messed with the structure but it general the content is the same. I tried to keep major reworks separate16:44
sean-k-mooneymanuvakery1: we generally recommend confinging the guest to run on a subset of host cores16:44
kashyapRight; I see that you've also added hyperlinks where you can16:44
sean-k-mooneymanuvakery1: using vcpu_pin_set before train or cpu_share_set and cpu_dedicated_set after train16:45
kashyapE.g. on line-17 I see you've added the link to _deploying-sev-capable-infrastructure16:45
sean-k-mooneymanuvakery1: that way you can ensure that the host os never locks up16:45
kashyapstephenfin: Okay; figured as much - major rework separate.  Thx16:45
sean-k-mooneymanuvakery1: our general recommendateion is to reserve at least the first core from each numa node or for the OS to use16:45
manuvakery1sean-k-mooney: ok. I will try that16:46
kashyapstephenfin: Err, thinko above: it's not a link, but an "anchor".16:46
sean-k-mooneymanuvakery1: so assuming you have 2 sockets each wtih 12 cores and 24 hypertreads you weroul ideally reserved cores 0,12,24,3616:46
sean-k-mooneymanuvakery1: before train that would be done with vcpu_pin_set=1-11,13-23,25-35,37-4716:48
*** lpetrut has quit IRC16:48
sean-k-mooneyafter train cpu_shared_set=1-11,13-23,25-35,37-4716:48
sean-k-mooneyvcpu_pin_set was in the [DEFAULT] sechtion and cpu_*_set are in the [compute] section of the nova.conf, this need to be set on each compute node16:49
manuvakery1sean-k-mooney:  I am using train. I will see to it. Thanks for your response16:50
*** ociuhandu_ has joined #openstack-nova16:55
*** ociuhandu has quit IRC16:58
*** ociuhandu_ has quit IRC16:59
*** lucasagomes has quit IRC17:07
*** dtantsur is now known as dtantsur|afk17:09
*** whoami-rajat_ has joined #openstack-nova17:10
*** penick has quit IRC17:11
*** rpittau is now known as rpittau|afk17:11
MrClayPoleWe are troubleshooting and issue with our Openstack backup provider (Trilio) and our Storage vender/cinder driver (Zadara). As part of this troubleshooting we've been asked to disable iSCSI multipathing. I can see that this installed as part of the nova deployment in Openstack ansible from the mutipath-tools package. Is it OK to just stop and disable the multipathd services. Then run mutipath -F. Then check with multipath17:18
MrClayPole -ll to ensure its no longer active?17:18
*** jamesdenton has quit IRC17:24
*** jamesdenton has joined #openstack-nova17:24
openstackgerritMerged openstack/osc-placement master: Include usage in 'inventory list', 'inventory show'  https://review.opendev.org/c/openstack/osc-placement/+/74397617:34
*** amodi has quit IRC17:53
sean-k-mooneylyarwood: whats the status of nova-grenade-multinode17:55
sean-k-mooneydid you have a patch to move that to v3? or am i just wishing you did17:55
sean-k-mooneyah https://review.opendev.org/c/openstack/nova/+/77888517:56
sean-k-mooneyis ^ going to happen this cycle?17:56
*** amodi has joined #openstack-nova17:58
*** whoami-rajat_ is now known as whoami-rajat18:06
*** andrewbonney has quit IRC18:09
*** links has quit IRC18:12
*** ricolin has joined #openstack-nova18:19
ricolinstephenfin, hi about https://review.opendev.org/c/openstack/nova/+/78121018:19
ricolinI update some logs in comments, for what I can tell it only happen to bionic environment from aarch64. it disappear once I moved to focal18:21
openstackgerritMerged openstack/nova stable/victoria: Add config parameter 'live_migration_scheme' to live migration with tls guide  https://review.opendev.org/c/openstack/nova/+/78121118:32
*** dtantsur has joined #openstack-nova18:35
stephenfinricolin: That looks like a bug. Can you open a bug on launchpad and I'll take a look tomorrow?18:36
stephenfinricolin: Referring to this http://paste.openstack.org/show/803788/18:36
*** slaweq_ has joined #openstack-nova18:37
*** dtantsur|afk has quit IRC18:41
*** slaweq has quit IRC18:41
ricolinstephenfin, thanks I will open one for both errors I found18:47
sean-k-mooneythat a python2 vs python3 issue i think19:06
sean-k-mooneyricolin: master is not intended to run on bionic by the way19:07
sean-k-mooneyit might be compatiable but its not part of the offical testing runtimes anymore19:07
sean-k-mooneywe have 1/2 jobs that use it for reasons but the arm jobs should be on focal19:08
sean-k-mooneyricolin: ussuri was the last release to use bionic19:09
sean-k-mooneyall jobs for victoria wallaby and master shoudl be useding 20.04/focal if they are ubuntu based19:09
*** manuvakery1 has quit IRC19:11
sean-k-mooneyricolin: is there a reason the aarch64 job was using bionic19:12
sean-k-mooneyricolin: stephenfin  we have seen issue with libs incorrectly monkeypactching codecs.py in the past19:14
sean-k-mooneythis looks like we are hitting https://github.com/openstack/nova/commit/b862f6ff35d1611d0d63623a6254fc889012bfb919:15
sean-k-mooneywhere blockdiag was messing with   codecs.getreader19:16
*** hamalq has joined #openstack-nova19:27
*** ralonsoh has quit IRC19:28
*** Anticime1 is now known as Anticimex19:29
*** rouk has joined #openstack-nova19:31
*** gokhani has quit IRC19:31
roukafter updating to the latest stable/ussuri nova version, live migrations are broken due to cpu features being added that shouldnt be.19:34
rouki have merged the patches in master which allow disabling cpu features, but even that doesnt make migrations work.19:35
roukeven after disabling these features, live migrate fights back with libvirt.libvirtError: operation failed: guest CPU doesn't match specification: extra features: npt,nrip-save19:35
*** sapd1 has quit IRC19:36
roukhow do i stop nova from adding features on migration and breaking things?19:36
roukseems like a pretty big breaking change that made it into a patch...19:40
sean-k-mooneyrouk: that is not a breaking change in nova19:42
sean-k-mooneythat is a breaking change in your kernel19:43
sean-k-mooneyrouk: nova does not add those features19:43
roukit only appeared after patching nova a week ago to stable/ussuri...19:43
roukand is present on old-kernel boxes.19:43
openstackgerritMerged openstack/nova stable/train: Prevent archiving of pci_devices records because of 'instance_uuid'  https://review.opendev.org/c/openstack/nova/+/76097819:44
sean-k-mooneynova does not add those features19:44
sean-k-mooneyrouk: so i think you got some other change you did not intend19:44
roukit never used to, no. but these new changes that came in to "fix" live migrations, are adding features19:44
sean-k-mooneywhich change are you refering too19:45
rouksec while i grab the commit19:45
sean-k-mooneythis ? https://github.com/openstack/nova/commit/b6c473159ec45e0aa715edd45cde28f77484a5f719:49
roukthere was one a bit earlier19:49
sean-k-mooneythre is no nova code to add those extrapsec explitly19:49
sean-k-mooney*extra features19:49
sean-k-mooneycan you share how you have configured the cpu_mode/cpu_model/extra cpu flags19:50
sean-k-mooneyin your nova.conf19:50
rouki have model, i added extra flags to try and fix this, as i merged support for - syntax to remove features.19:50
roukbut, just epyc-ibpb19:51
sean-k-mooneyare all you servers amd eypc ?19:51
roukyep.19:51
roukhttps://patchwork.kernel.org/project/qemu-devel/patch/20190121155051.5628-1-vkuznets@redhat.com/19:52
roukwhich, this happened a while ago, which added these as features retoactively in qemu for the model.19:52
sean-k-mooneythise appears to be the defintion of that model19:52
sean-k-mooneyhttp://paste.openstack.org/show/803793/19:52
roukand then this got picked up by nova, which then added these as required features on migrate19:53
*** tbachman has quit IRC19:53
sean-k-mooneyok so this is not a nova bug so19:53
sean-k-mooneythose requiremtns are coming form libvirt19:53
roukso how do we stop them from retoactively being added on migrate from nova?19:54
sean-k-mooneydid you update the qemu/libvirt version when you updated ussuir19:54
sean-k-mooneyhave you confrim that is what is happening19:54
sean-k-mooneydo the vms actully have them?19:54
sean-k-mooneyif hte vm was hard rebooted it could have had teh feature exposted to it19:54
roukwe were on 4.0+ (where this qemu change happened) the whole time during ussuri, migrations only broke recently.19:54
roukhard rebooting the vm does fix it, by adding the feature19:55
rouki dont want to reboot an entire cloud.19:55
sean-k-mooneyfair but do you have the nova fix i mentioned above19:55
sean-k-mooneyhttps://github.com/openstack/nova/commit/b6c473159ec45e0aa715edd45cde28f77484a5f719:55
roukyes, i am on stable/ussuri as of a week ago.19:56
roukbuilt from git.19:56
sean-k-mooneyok so what it sounds like is the current vm definiton which is based on epyc-ibpb19:57
sean-k-mooneywas generated before the model was updated19:57
sean-k-mooneyand now that its  migrating to the new host the info we get from the dest libvirt is expecting the new defintions19:57
sean-k-mooneyand its failing as a result of the abi break that libvirt/qemu did to the model19:58
rouklibvirt migrations usually dont add features during migrate, usually you wait for reboot for that.,19:58
sean-k-mooneycorrect it cant19:58
sean-k-mooneyand i dont think nova is19:58
sean-k-mooneyi think this is happening lower down the stack19:59
roukhow would libvirt add its own policy19:59
roukcpu check mode is now full, instead of partial before.19:59
roukso that also changed. vms before the latest patch had no feature policy mentioned, just the model19:59
roukhere, let me paste the 3 iterations i have observed20:00
sean-k-mooneyrouk: we ask libvirt to dump the migratable xml here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/migration.py#L5820:00
sean-k-mooneyrouk: just so you are aware the xml that libvirt uses and dispalas is not the same one that nova gives it20:01
sean-k-mooneyrouk: libvirt parses the xml we give it and add extra info to it20:01
roukyeah, gotta use --live, etc20:01
sean-k-mooneyam if you have nova-compute in debug mode we will print the xml that we set to libvirt20:02
sean-k-mooneybut the one that is shown in any virsh output is not the one we gave it20:02
sean-k-mooneyits the one after it updates it and files in things like guest pci devices20:02
roukhttp://paste.openstack.org/show/opnX0PSXurwehQCWsSbg/20:03
sean-k-mooneythe migrate xml we use is one that we retive from libvirt20:03
sean-k-mooneythen we modify it20:03
sean-k-mooneywith https://github.com/openstack/nova/blob/master/nova/virt/libvirt/migration.py#L59-L6920:03
roukso the --migratable doesnt have those cpu flags required.20:03
sean-k-mooneybut we dont modify the cpu flags20:03
sean-k-mooneybut are they listed20:04
rouknope.20:04
rouksee paste, first block.20:04
sean-k-mooneyjust looking at you link now20:04
sean-k-mooneyso looking at the paste20:05
sean-k-mooneythe very old vms are the ones booted and not rebooted since the model defineiton was updated20:05
rouk"very old vms" is pre ussuri20:05
rouk"somewhat old" is post ussuri, pre update.20:05
sean-k-mooneyok20:05
roukall of ussuri had libvirt 4.0+, which is where the features got retroactively added20:06
roukunless kolla changed base distro... which is... well i can check.20:06
roukdang, i only have newer versions running, id have to check if kolla has a history somewhere.20:07
sean-k-mooneykolla has different images per disto20:08
sean-k-mooneyare you on centos or ubuntu or debian20:08
sean-k-mooneyit wont chagne the os version witin a release20:08
roukwe are on ubuntu, which is based on 18.04 right now for ussuri, havnt jumped version.20:08
sean-k-mooneyso one thing i notice is <cpu mode='custom' match='exact' check='full'>20:08
sean-k-mooneynova does not sett check=full20:09
sean-k-mooneythat might be part of the issue here20:09
rouki tried to find any code in libvirt or nova for that, and couldnt find either. im... not sure what changed.20:09
roukit used to be partial.20:09
sean-k-mooneythis is a default change in libvirt20:09
roukand i confirmed, vms that used partial, do migrate20:10
roukeven if theyre ancient20:10
sean-k-mooneyso libvirt is from the ubuntu cloud archive in your case20:10
sean-k-mooneykolla just uses the libvirt form uca for the given version20:10
rouki dont think ubuntu tampered with libvirt defaults... but ive seen worse, but also that would be a very strange mid-release change...20:11
roukso, what i dont get is i merged e0a8cd7ca8a907a3d178c759212e1685d0fa35c6 and c60f4df8b19b75c8c98ec570b2a506aece9a5a3420:12
roukand backported them correctly, to try and just -npt to solve it, and migration still adds it.20:12
roukeven though new vms properly have it explicitly disabled.20:13
roukim not sure what i should be doing? other than a reboot, what can i do? custom libvirt config override? this issue will affect more than me.20:13
sean-k-mooneycan you do "virsh dumpxml  <vm> --update-cpu --migratable" on one of the instances that cannot live migrate20:14
rouki have played with that, but yes, i can get one i havnt touched and get you the before/after etc, sec.20:14
sean-k-mooneyrouk: so we get the xml form libvirt similar to ^20:15
sean-k-mooneybut we do not update the cpu flags part20:15
sean-k-mooneyim wondiering if we are getting those flags form libvirt in that call20:15
sean-k-mooneythe patch that we have for removing cpu flag only takes effect for new instances20:16
roukone way to find out, when i saw the commit from qemu that retroactively changed epyc/opteron i just sighed, cause now we got vms stuck with old and new.20:16
rouktook a couple weeks after rollout to notice.20:16
sean-k-mooneyya20:16
sean-k-mooneythey should have versioned the model definiton20:17
sean-k-mooneythey should never update them in place20:17
roukyep.20:17
roukhttp://paste.openstack.org/show/5ozPeL4s49EoSssXRvK7/20:19
rouknot the result i expected20:19
*** whoami-rajat has quit IRC20:19
sean-k-mooneythats similar to what i expected20:20
roukso wheres it being added if thats nova's starting point?20:20
sean-k-mooney--update-cpu should only change thigns for host model20:20
sean-k-mooneypossible form the cpu basline check on the dest20:20
roukis there any way i can trick nova into not seeing these new features somewhere?20:21
roukor any other output you want20:22
sean-k-mooneythe only way to trick it would be to copy the file and revert the change20:24
sean-k-mooneyim trying to get virsh cpu-baseline to work20:25
*** rcernin has joined #openstack-nova20:25
roukthe edits are in C, so it would be a recompile to fix it seems.20:25
roukbut, the only way this could be responsible is if ubuntu jumped from 3.x to 4.x, as this qemu change is only in 4.0+20:26
sean-k-mooneyno you would jst need to edit the files in /usr/share/libvirt/cpu_maps/*.xml20:26
sean-k-mooney/usr/share/libvirt/cpu_map/x86_EPYC-IBPB.xml in your case20:26
roukhttps://patchwork.kernel.org/project/qemu-devel/patch/20190121155051.5628-1-vkuznets@redhat.com/ these qemu changes arent related?20:26
rouknrip nor npt are in my xml20:27
roukits not part of the qemu cpu_map20:27
rouks/qemu/libvirt20:27
roukits being added higher up, in qemu itself?20:28
*** tbachman has joined #openstack-nova20:28
sean-k-mooneyi think what we do is basically http://paste.openstack.org/show/803802/20:28
sean-k-mooneyor rather what libvirt does and then its  comparing the baseline cpus between the source and dest host20:29
*** tbachman has quit IRC20:29
roukit is present there, yeah.20:30
*** tbachman has joined #openstack-nova20:30
sean-k-mooneycould you try "virsh capabilities > /tmp/caps.xml ; virsh cpu-baseline /tmp/caps.xml --migratable --features; rm  -f /tmp/caps.xml"20:30
rouk<feature policy='require' name='nrip-save'/>20:31
roukyeah its there.20:31
*** adrianc has quit IRC20:31
sean-k-mooney so that is where its coming from20:31
sean-k-mooneylet me see if i can find the nova code20:31
*** adrianc has joined #openstack-nova20:32
sean-k-mooneyso this is not form the xml update20:32
sean-k-mooneyits form the eariler cpu compatiablity check20:32
sean-k-mooneyin pre livemigrate i think20:32
rouk:( and i hoped backporting those cpu feature changes would help me, heh.20:32
sean-k-mooneythis is where its failing https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8991-L906020:35
sean-k-mooneywe ask libvirt if the xml is comparitble https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/host.py#L142420:36
rouka migration should survive adding features no? could it be made soft/warn for new features?20:36
sean-k-mooneyrouk: no the cpu flag cannot have addtion or removales in a live migration20:36
roukalright. then new features could be trimmed off?20:37
*** ociuhandu has joined #openstack-nova20:37
rouknew features on migrate shouldnt happen... even if its qemu being dumb and retroactively changing things.20:37
sean-k-mooneyam yes but im trying to see how nova is in this state20:38
sean-k-mooneywe can generate the cpu xml we pass in 3 ways20:38
sean-k-mooneyhttps://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L9017-L903220:38
*** rcernin has quit IRC20:38
sean-k-mooneyits only caled in 2 places https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8701-L8708 and here https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L872-L88820:41
roukwhy would the vm be checked against target host features? if the vm doesnt have the feature, it shouldnt be checked on the vm side...20:42
rouknova doesnt care if the vm is missing a feature the host has20:43
roukif it fits within the features of the new host, it should pass.20:43
roukwhich, it does.20:43
roukif i was to change some of these checks to only care about the host having what the vm has, itd work, no?20:45
roukor would it migrate with host features and die20:46
sean-k-mooneyso nova does need to check the that host has all feature that the vm uses20:46
sean-k-mooneyyou are right ti does not care about ones that are disabled20:46
sean-k-mooneyso nova should ignore onces that are disabeld20:46
roukyeah, vm needs to fit inside the host, not the other side.20:46
sean-k-mooneyright so libvirt did not previoulsy have disabeld feature we had to ignore until recenlty20:47
sean-k-mooneyand nova did not provide a way to disable them20:47
roukif these checks pass, will it migrate with the bad config, or the current vm config (which will work)?20:48
roukis it as simple as making these checks looser on the vm side?20:48
sean-k-mooneyit will migrate with teh current config20:48
sean-k-mooneywhich should work20:48
roukyeah20:48
sean-k-mooneywell20:48
sean-k-mooneyactully not nessisarly20:48
sean-k-mooneyso hte issue we have is that how migration work is actully different then most people think20:49
rouki got confused once i had to patch nova-ssh :p20:49
sean-k-mooneylibvirt on the source house ask libvirt on the dest host to spawn a qemu instance using an xml we provide20:49
sean-k-mooneyso that qemu instance i like a norm new instance that was booted with a given xml20:49
sean-k-mooneyif libvirt addes flags to that qemu becuase it has a different cpu model definiton20:50
sean-k-mooneythe qne qemu tryes to do the migration form the source to dest it will fail20:50
roukso on move, vm-side missing features need to be added as disabled?20:51
sean-k-mooneyyes20:51
roukinstead of just missing20:51
sean-k-mooneyi belive they would if they weere enabled in the model20:51
roukyeah, thats what i tried to do with those patches, cause when i manually tested migration, i could make it move by disabling features on the target20:51
roukwhats the most elegant way to add missing as disabled on migrate?20:52
roukor should i be forking qemu till i can get vms onto new features organically?20:53
roukheh20:53
sean-k-mooneyso the current failure is here https://github.com/openstack/nova/blob/3de7fb7c327db348d04d15d4cd3c4f811a336126/nova/virt/libvirt/driver.py#L8702-L8706  i ruled out the other code path20:53
roukid... rather not do that.20:53
sean-k-mooneyrouk: you dont need to fork qemu20:53
sean-k-mooneyfor testing you could comment out both checks on the dest host20:54
roukbut wouldnt libvirt then add the feature on move?20:55
sean-k-mooneyam well the xml we provide wont reference them20:55
sean-k-mooneybut yes your right it might do it implcitly20:56
rouki can try, if you think its a worthy test20:56
sean-k-mooneyi think what will happne is the libvirt error will go away but you might get a qemu error when we actully call migrate20:57
roukprobably, if nova isnt the one adding these in the first place.20:57
sean-k-mooneywhat i was thinking was we could modify the migrate xml to remove/add the cpu feature based on the config20:57
sean-k-mooneyrouk: basically what you were orginally trying to do20:57
sean-k-mooneybut also on migrate20:58
sean-k-mooneythe orginal patch only did it on spawn20:58
roukyeah, but wont that be a problem for people in other cases?20:58
roukfor me, sure, it fixes my problem20:58
sean-k-mooneyyep im sure ill get a downstream bug for this ill have to help fix in a rush20:58
sean-k-mooneyim tyrin g to think through 2 things currently20:59
sean-k-mooneywhat would not be a horrible hack for you20:59
sean-k-mooneyand waht we could do to workaround the libvirt/qemu abi break more generally20:59
roukwell, more generally, cant we just edit the migration xml on compare error, we have the missing features, and we know which direction the failure is.21:00
roukif the vm is at fault, and its a new feature on the host, disable it, it will get enabled next reboot.21:00
sean-k-mooneymaybe we are also currently reqorking how we do the cpu compare21:00
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/76233021:01
rouki might need a horrible hack though, depending on how long the fix will take.21:01
sean-k-mooneyalthough i dont think that will fix it21:01
roukevery day this sits, new vms come up depending on new features, and old vms are stranded.21:01
roukgot hosts with broken NICs i cant evict, heh21:01
roukthanks supermicro21:01
sean-k-mooneyya so this will only affect exsiting instance now that you have updated all the contianers21:02
roukif i didnt have like 1/3rd of my capacity having nics all blow up at once.21:02
sean-k-mooneyso option 1 is cold migration  or hardreboot + libve migration21:03
rouki would hardly mind this cpu change, cause id just uh... wait till everyone reboots.21:03
sean-k-mooneynot grate but it would work21:03
roukyeah, its about 1500 VMs to reboot.21:03
roukand ill get quite the tomatoes thrown at me21:03
sean-k-mooneyoption 2 patch the cpu model xml and to use the old values21:03
*** rcernin has joined #openstack-nova21:03
roukits not in the xml.21:03
roukits added higher up, in qemu cpu.c21:04
sean-k-mooneyno one sec21:04
sean-k-mooneyi mean /usr/share/libvirt/cpu_map/x86_EPYC-IBPB.xml21:04
*** gyee has joined #openstack-nova21:04
roukyeah, it doesnt mention these features.21:04
sean-k-mooneyyep you could add them and set them disabled21:04
roukah21:04
roukdidnt see an arg for disabled on any of the existing lines.21:04
sean-k-mooneythen make a copy of the file as normal with a new name21:04
sean-k-mooneyand update the nova.conf to use that for new vms21:05
roukwill nova know to use the old name on migrate?21:05
sean-k-mooneyyes because that is in the xml which we dont update21:05
*** tbachman has quit IRC21:05
roukah yeah21:05
roukits quite the hack, but... i can do it pretty trivially.21:06
roukjust make it part of my nova build.21:06
sean-k-mooneyya so basically mv <file>.xml <file>_v2.xml21:06
sean-k-mooneywell cp21:06
sean-k-mooneyand then edit <file.xml>21:07
sean-k-mooneyyou could do that as a layer in the nova-libvirt container21:07
sean-k-mooneyif you want new vms to use the new defintion just set cpu_model=eypc-ibpb-v221:08
sean-k-mooneynew vms will get that but migrated ones wont until you hard reboot21:08
sean-k-mooneybasically with a kolla build overried file you would be patching in the versioning that libvirt should have done21:08
sean-k-mooneyrouk: 3 is we figure out how to do  this in code which could take a little while to do21:10
sean-k-mooneyrouk: have you filed a bug?21:10
sean-k-mooneyrouk: its not really a nova bug but we could workaround it i think21:11
sean-k-mooneywe would need to create a functional repoducer first as while i undersatd why this happended its really not due to an external change that we cant contol21:13
rouki havnt filed a bug, no.21:14
roukbut yeah, ill build a nova-libvirt with another model.21:14
*** ociuhandu has quit IRC21:15
sean-k-mooneyactully i think there is something else you could try21:15
sean-k-mooneyso they added teh "fix" for this to https://github.com/qemu/qemu/blob/1b507e55f8199eaad99744613823f6929e4d57c6/hw/i386/pc.c#L125-L14721:16
roukyeah whats this compat, i googled it on friday21:16
*** rcernin has quit IRC21:17
sean-k-mooneyyou might be able to use a versioned machinve type for this21:17
rouki couldnt find any docs for how these compat versions work.21:17
sean-k-mooneyso i have nver looked at this before but i think it might eb related to machine tyeps21:17
rouki just have no idea what arg or config i need to do to activate this 3.1 compat21:18
rouki cant find a single note of documentation on it21:20
sean-k-mooneyso these are the machine type i have on centos they are disto specific21:21
sean-k-mooneyhttp://paste.openstack.org/show/803804/21:21
sean-k-mooneyim going to check a ubuntu vm21:22
roukoh... that notation, i saw some stuff for that in virt-manager before.21:22
*** jangutter has joined #openstack-nova21:22
roukwonder if it has it listed21:22
sean-k-mooneyhttp://paste.openstack.org/show/803805/21:23
sean-k-mooneythat is ubuntu 20.0421:23
sean-k-mooneyi wonder if you can use pc-i440fx-3.121:24
roukpc-i440fx-3.1        Standard PC (i440FX + PIIX, 1996)21:24
roukyeah21:24
roukcan nova set machine type... sec21:24
sean-k-mooneyyep21:25
sean-k-mooney1 of two ways. in the image which wont help and in the nova.conf which should21:25
roukyeah, libvirt.hw_machine_type21:25
*** jangutter_ has quit IRC21:25
roukcan do that, that sounds a lot cleaner.21:25
sean-k-mooneyhttps://docs.openstack.org/nova/latest/configuration/config.html#libvirt.hw_machine_type21:25
sean-k-mooneyyep so add x86_64=pc-i440fx-3.121:25
roukill get that tested after some food, been at this issue most of the day, heh.21:26
roukthanks for all the help, even though its not nova's fault, at least the knowledge that this dumb editing can happen from qemu means nova can defend against it.21:26
sean-k-mooneyya. if using the version machine type fixes it then great21:27
roukmaybe that needs to be a default thing thats recommended to set, idk21:27
sean-k-mooneythat would at least give use time to think about what to do in nova if anything in the futrue21:27
sean-k-mooneywell there are two camps21:28
sean-k-mooneyone camp is alwasy uses the versioned machine type21:28
sean-k-mooneyand ooo/ redhat openstack does this by default21:28
sean-k-mooneythe other camp is alwasy use the latest one21:28
sean-k-mooneyso that you get the latest fixes/abi21:28
rouksure, that works great till qemu screws you21:29
roukwith machine type though, we cant really move to the new instructions well21:29
roukthe xml change would at least persist in the vm config and be fixed on reboot.21:29
roukversion, we just delay till nova can handle it, i guess.21:30
rouknot sure which is better.21:30
sean-k-mooneyhttps://github.com/qemu/qemu/blob/c40ae5a3ee387b13116948cbfe7824f03311db7e/hw/i386/pc_piix.c#L510-L52521:30
sean-k-mooneythere we go21:30
sean-k-mooneyso yes those are the version machine type defintions21:31
roukis there any way to make nova migrate between versions on reboot?21:31
roukor will i need to use a custom model to do that21:31
sean-k-mooneyam nova used too but we now wont21:31
roukso i guess the custom model is better21:32
roukat least then i can get everyone to move organically next time they reboot without breaking migrations21:32
*** derekh has quit IRC21:32
roukeven if its a dirtier fix21:32
sean-k-mooneyrouk: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/libvirt-stash-instance-machine-type.html21:32
sean-k-mooneywell no so on ussuri you could set the machine type explcitly21:33
sean-k-mooneymigrate all teh vms21:33
sean-k-mooneythen set it back to pc which is the default or leave it unset21:33
sean-k-mooneythen they would update on hard reboot21:33
roukbut their migrations will break.21:33
roukor once its migrated once, it will stick in the config.21:33
sean-k-mooneynot unless this happens again21:34
roukhmm, i guess thats an okay upgrade plan21:34
roukas long as im not stranded on a setting forever.21:34
sean-k-mooneyso what the new spec say21:34
sean-k-mooneyis going forward we will recored the machinve type a vm boots with the first time21:34
sean-k-mooneyand it will have that forever21:34
sean-k-mooneyunless21:35
sean-k-mooneyyou use the new nova-manage update_machine_type21:35
sean-k-mooneycommand to change it21:35
sean-k-mooneyrouk: before that we would use what ever was in the config when generting the xml21:35
sean-k-mooneyif unset it would default to pc21:36
sean-k-mooneyanyway i need to grab food too21:37
sean-k-mooneyhopefully that hels and you can use a machine-type or update the cpu model for now21:37
sean-k-mooneythe reason you hit this issue is 1 you are not using a version machine type today and 2 qemu backported that abi break21:38
*** artom has quit IRC21:46
*** rcernin has joined #openstack-nova21:51
*** rcernin has quit IRC21:51
*** rcernin has joined #openstack-nova21:52
*** tbachman has joined #openstack-nova21:55
*** artom has joined #openstack-nova22:00
*** artom has quit IRC22:06
*** ociuhandu has joined #openstack-nova22:13
*** ociuhandu has quit IRC22:14
rouksean-k-mooney: with the option set, still breaks.22:27
roukdoes it not take effect on migrate?22:27
roukhw_machine_type = x86_64=pc-i440fx-3.122:27
*** slaweq_ has quit IRC22:30
*** hoonetorg has quit IRC22:37
roukah, the vm got the default  machine='pc-i440fx-4.2' from before.22:37
roukwill it be honored if i change the xml? hmm22:40
rouknah, so i guess the custom model is the only way.23:03
*** macz_ has quit IRC23:12
rouksean-k-mooney: <feature policy='disable' name='npt'/> in the destination epyc-ibpb.xml also doesnt work.23:32
roukdont think anything can be disabled here?23:32
*** macz_ has joined #openstack-nova23:46
*** macz_ has quit IRC23:50
roukbut yes, qemu moved from 3.1 to 4.2 in a single release version on ubuntu cloud repo23:53
roukguess i can rollback23:53
*** mlavalle has quit IRC23:57

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!