| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-07 | |||
| 17:10:01 | hrw | I used 'hyperv on aarch64' as hypotetical impossible option | |
| 17:10:22 | hrw | or rather 'so far impossible' as MS already has windows 10 on aarch64 | |
| 17:10:41 | idlemind | sean-k-mooney ya i have both of those things; in addition i had to do virsh edit for the instance after it's built and add the feature require for svm | |
| 17:10:53 | mriedem | stephenfin: https://libvirt.org/hvsupport.html | |
| 17:10:57 | stephenfin | hrw: Indeed. Never rule it out :) | |
| 17:11:23 | stephenfin | hrw: Alright, I'm mostly convinced and therefore drop my objections. Thanks for working through that with me | |
| 17:11:24 | sean-k-mooney | idlemind: with cpu-mode host-passthough all cpu flags from the host should be available in the guest | |
| 17:11:35 | hrw | stephenfin: thanks | |
| 17:11:46 | mriedem | this is what i was looking for https://libvirt.org/drivers.html#hypervisor | |
| 17:11:47 | idlemind | sean-k-mooney the catch is likely that i'm using amd where most ppl use intel (because of the dc hardware being almost exclusively intel these days) | |
| 17:11:58 | stephenfin | mriedem: Those libvirt guys have too much time on their hands | |
| 17:12:36 | sean-k-mooney | idlemind: that seams like a libvirt/qemu bug to me. it should work on amd or any other processor not just x86 | |
| 17:12:38 | hrw | stephenfin: I like that fact - easier to use same tools despite hypervisor differences | |
| 17:12:38 | idlemind | sean-k-mooney would that be a bug in centos (my base kvm node for openstack) or in nova if all the cpu instructions aren't getting passed into the guest | |
| 17:12:50 | mriedem | yeah so guest.os_mach_type is per image, | |
| 17:12:55 | mriedem | so doesn't belong in _do_quality_warnings | |
| 17:13:16 | stephenfin | mriedem: Yup, just replied. The warning would have to go in that same area of the code | |
| 17:13:17 | mriedem | otherwise based on the host arch | |
| 17:13:20 | sean-k-mooney | idlemind: i think a centos/libvirt/qemu/kvm bug | |
| 17:13:52 | idlemind | sean-k-mooney k thx i can start there; any chance you know which metadata property you were thinking of to add the force for me as a work-around? | |
| 17:13:52 | sean-k-mooney | idlemind: how did you enable nested virt in kvm? what module arg did you set it is different on amd vs intel | |
| 17:14:47 | mriedem | wow even danpb was reviewing this patch | |
| 17:14:54 | idlemind | sean-k-mooney for centos in /etc/modprobe.d/kvm.conf they have the necessary lines for amd and intel you just uncomment the one you need. you can then reload the kvm_amd (in my case) module or reboot the host. i did reboots on both my hosts. | |
| 17:15:50 | bkero- | echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm.conf # or kvm_amd if you have it, then... modprobe -r kvm_intel; modprobe kvm_intel | |
| 17:15:50 | idlemind | sean-k-mooney i set nova.conf overrides to set cpu_mode = passthrough via openstack ansible i did not do anything with cpu_model | |
| 17:16:22 | sean-k-mooney | idlemind: ah its not passthrough its host-passthrough i belive | |
| 17:17:02 | sean-k-mooney | idlemind: yes it should be "host-passthrough" | |
| 17:17:09 | hrw | mriedem, stephenfin: replied | |
| 17:17:09 | sean-k-mooney | see https://docs.openstack.org/nova/queens/configuration/config.html | |
| 17:17:13 | idlemind | i think that's what i use because that comes through fine | |
| 17:17:36 | hrw | mriedem: I asked libvirt guys to take a look to make sure that I got the idea properly | |
| 17:18:14 | hrw | mriedem: as we were discussing (on irc) few ways of handling it and only this one turned out to be proper working without any random glitches | |
| 17:18:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Rename the 'recreate' param in rebuild_instance to 'evacuate' https://review.openstack.org/508190 | |
| 17:19:02 | cdent | well that's not confusing at all | |
| 17:19:04 | idlemind | sean-k-mooney and bkero- http://paste.openstack.org/show/693686/ | |
| 17:19:42 | idlemind | w/o that feature policy='require' name='svm' i don't get svm in my guest and kvm-ok fails | |
| 17:20:00 | mriedem | cdent: you weren't in the room on friday | |
| 17:20:05 | mriedem | when my head exploded | |
| 17:20:25 | cdent | that was the Nth time where N is ? | |
| 17:20:27 | sean-k-mooney | idlemind: and if you do a cat /proc/cpuinfo on the host you see svm listed | |
| 17:20:48 | hrw | stephenfin: thanks for +2 ;) now have to fetch another one and +w ;D | |
| 17:20:49 | idlemind | sean-k-mooney yes w/the feature line i get svm in /proc/cpuinfo ... w/o the feature line no dice | |
| 17:21:08 | sean-k-mooney | idlemind: no i mean on the host not the guest | |
| 17:21:24 | mriedem | bauzas: dansmith: given the rebuild hoopla, and cve regression circus, we should probably get this in and backport as well https://review.openstack.org/#/c/546268/ | |
| 17:21:42 | mriedem | while i'm thinking about rebuild | |
| 17:21:55 | idlemind | sean-k-mooney yes for all 4 cores | |
| 17:21:57 | mriedem | hrw: i've got a tab open, will look in detail later | |
| 17:22:01 | hrw | mriedem: thanks | |
| 17:22:41 | sean-k-mooney | idlemind: strange so ya i think this is a libvirt/kvm/qemu bug and it it is not correctly reading the cpu flags | |
| 17:23:23 | sean-k-mooney | idlemind: i assume you are using qemu/libvirt for the rdo repos not the default centos one? | |
| 17:24:17 | idlemind | sean-k-mooney i'm not sure tbh i'm thinking they would have been brought in by openstack-ansible so i'd have to dig around there | |
| 17:24:52 | idlemind | http://paste.openstack.org/show/693687/ | |
| 17:25:20 | idlemind | looks like a fairly new release | |
| 17:25:23 | sean-k-mooney | the -ev rpms are form rdo | |
| 17:25:42 | sean-k-mooney | the default centos ones are old and busted in many ways | |
| 17:26:46 | dansmith | mriedem: I don't understand the logic in the comment you're removing | |
| 17:26:50 | openstackgerrit | Merged openstack/nova master: Fix version cap when no nova-compute started https://review.openstack.org/549737 | |
| 17:27:06 | dansmith | mriedem: seems like cases 2 and 3 are both covered by recreate=True, why was it even considering the scheduled_node in there? | |
| 17:28:38 | idlemind | sean-k-mooney well at least that's a good sign! | |
| 17:28:43 | mriedem | dansmith: honestly i think the comment was just overthinking things when it was written to fix a similar type of issue with forced host evacuate | |
| 17:28:59 | mriedem | that's why i removed it and just changed the code to check the recreate flag | |
| 17:29:31 | mriedem | the scheduled_node thing was tied into whether or not you were doing a forced host evacuate, | |
| 17:29:43 | mriedem | and the comment was added at the same time as fixing a bug in that scenario, so it was probably just 'on the brain' | |
| 17:30:21 | mriedem | that comment also predates the changes to run the host back through the scheduler on rebuild if the image changes | |
| 17:30:39 | dansmith | mriedem: yeah I just want to make sure I understand what it was trying to do | |
| 17:30:49 | mriedem | anyway, all related to said head explosion at the ptg | |
| 17:30:58 | dansmith | mriedem: looking at the original patch, "if scheduled_node is not None" which is was already there, | |
| 17:31:04 | dansmith | so it was probably just trying to augment that case, | |
| 17:31:14 | dansmith | when really it should have just considered the recreate flag itself | |
| 17:31:46 | mriedem | i'd have to go back and look at that patch to get it all back into context | |
| 17:32:10 | mriedem | i think it boiled down to, forcing a host on evacuate never worked since it was added in newton until that patch fixed it :) | |
| 17:32:30 | mriedem | was also somehow related to pci devices, so maybe it was that it never claimed? can't remember | |
| 17:32:46 | mriedem | the claim is what messes with the pci devices in the migration context right? | |
| 17:32:53 | dansmith | idk | |
| 17:32:57 | mriedem | heh same here | |
| 17:38:17 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Only attempt a rebuild claim for an evacuation to a new host https://review.openstack.org/550545 | |
| 17:41:33 | sean-k-mooney | mriedem: there are two things that mess with pci device for migration. one we dont update allcoation correctly and 2 we dont regenerate the xml for that pci passhtrough section. | |
| 17:42:14 | sean-k-mooney | mriedem: that not a new thing though livemigration with pci devices never worked | |
| 17:42:45 | mriedem | artom is going to fix it | |
| 17:42:49 | mriedem | or die trying | |
| 17:43:09 | mriedem | sean-k-mooney: what do you mean by "don't update allocation correctly"? | |
| 17:43:12 | mriedem | claims? | |
| 17:43:22 | sean-k-mooney | mriedem: yes | |
| 17:43:23 | mriedem | or something in the pci tracker? | |
| 17:43:26 | mriedem | that's all voodoo to me | |
| 17:43:34 | sean-k-mooney | well the pci device table in the db | |
| 17:43:53 | sean-k-mooney | when we migrate we dont claim the device on the new node if i remeber correctly | |
| 17:44:10 | sean-k-mooney | and i dont think we release it on the old node either | |
| 17:45:34 | sean-k-mooney | if someone does fix that then awsome but i basically equate pci passthough = no migration even though we can make it work if we really want | |
| 17:46:26 | mriedem | maybe i'm thinking about pinned cpus | |
| 17:46:28 | mriedem | L226 https://etherpad.openstack.org/p/nova-ptg-rocky-placement | |
| 17:47:05 | sean-k-mooney | pinned cpus has a similar issue in that we dont regenerate the xml to account for the available cpus on the destination | |
| 17:47:29 | mriedem | right i think that's what artom is going to spec up and fix | |
| 17:47:44 | sean-k-mooney | mriedem: artom or stephenfin ? | |
| 17:47:47 | mriedem | artom | |
| 17:48:25 | mriedem | i guess live migrating instances with pci devices will wait for nested RPs (or something) | |
| 17:48:37 | sean-k-mooney | that would be nice to fix too. i think cold migrate works today but just not live migrate | |
| 17:49:18 | sean-k-mooney | mriedem: ya or after the multiple port binding work is done perhaps. | |
| 17:49:49 | sean-k-mooney | i think cold migrate might work with pci passhtouhg though not sure. | |
| 17:49:51 | mriedem | the cpu pinning spec is going to follow the port binding template | |