| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-10 | |||
| 11:12:51 | gmann | but even admin-only does it expose more info than nova should ? (from security point of view.) | |
| 11:13:38 | gmann | I think it was discussed previously also but sean-k-mooney or artom might know more on that. | |
| 11:16:31 | artom | gmann, yeah, I still want to do that, I was meant to propose a spec for Train but only have a very WIP up | |
| 11:17:39 | artom | The code exists in RDO project's gerrit, and a Red Hat QE and myself wanted to clear outstanding reviews on there and merging its tests for NUMA live migration | |
| 11:17:47 | artom | But that didn't happen yet | |
| 11:17:54 | gmann | i see. | |
| 11:18:19 | sean-k-mooney | gmann: sorry i was not following chat | |
| 11:18:27 | sean-k-mooney | what were we talking about | |
| 11:18:48 | gmann | sean-k-mooney: question from aspiers on exposing the libvirt XML to the show-server-diagnostics API | |
| 11:18:56 | sean-k-mooney | aspiers: no there is not a way to get the xml form the api | |
| 11:19:00 | sean-k-mooney | and there nerver will be | |
| 11:19:10 | aspiers | that's a bold statement :) | |
| 11:19:35 | sean-k-mooney | it completely violates the cloud abstration to expose that level of detail via the api | |
| 11:19:49 | sean-k-mooney | a non admin is not even ment to know the hypervior that is in use | |
| 11:20:00 | aspiers | sean-k-mooney: as admin-only diagnostics there is no violation | |
| 11:20:17 | aspiers | sean-k-mooney: we're not talking about non-admins | |
| 11:20:26 | sean-k-mooney | as admin only technically be they could jsut ssh into the host and look at the xml | |
| 11:20:37 | aspiers | sean-k-mooney: not from tempest they can't | |
| 11:20:49 | aspiers | plus that's a lot less convenient | |
| 11:20:53 | sean-k-mooney | tempest shoudl not be asserting behavior of the xml generation | |
| 11:20:59 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient master: Microversion 2.80: Add user_id/project_id to migration-list API https://review.opendev.org/675023 | |
| 11:21:13 | sean-k-mooney | that is what functional or white box testing is for | |
| 11:21:13 | aspiers | sean-k-mooney: please first read the use case above to understand the need ^^^ | |
| 11:21:14 | artom | aspiers, yeah, that's quite explicitly out of scope for tempest | |
| 11:21:20 | sean-k-mooney | tempest if for blackbox testing | |
| 11:21:25 | artom | But... quite explicitly *in* scope for whitebox :) | |
| 11:21:35 | gmann | yeah | |
| 11:21:44 | aspiers | again, this is repeating discussion from a few minutes ago when we talked about the white box plugin | |
| 11:21:44 | artom | So now you've landed yourself on the list of people interested, and will be poked mercilessly once it's ready ;) | |
| 11:22:16 | sean-k-mooney | aspiers: so why cant you boot a vm and ssh into an detect that sev is configured from within the vm? | |
| 11:22:16 | aspiers | if there is a white box plugin for tempest, then that means white box testing *is* in scope for the tempest ecosystem, even if not the core | |
| 11:22:20 | sean-k-mooney | or at least available | |
| 11:22:30 | aspiers | sean-k-mooney: how would I detect that? | |
| 11:22:35 | sean-k-mooney | lscpu? | |
| 11:22:45 | aspiers | sean-k-mooney: have you tested that? | |
| 11:22:45 | sean-k-mooney | is there not an msr or cpu flag for sev | |
| 11:22:55 | sean-k-mooney | no i dont have sev hardware | |
| 11:23:20 | gmann | aspiers: within scope of QA ecosystem not Tempest ecosystem. Tempest is just a tool under QA :) | |
| 11:23:24 | artom | aspiers, yeah, we're not saying "don't do it", we're saying "don't propose patches for it to Tempest" | |
| 11:23:46 | aspiers | artom: OK, it sounded like the former before :) | |
| 11:24:02 | aspiers | gmann: the white box tempest plugin isn't in the tempest ecosystem? ;-) | |
| 11:24:10 | sean-k-mooney | aspiers: whitebox and the intel nfv test repo use tempest as a framework | |
| 11:24:16 | sean-k-mooney | to do this type of testing | |
| 11:24:30 | sean-k-mooney | but its not in tempest as its out of scope fo tempest | |
| 11:24:47 | sean-k-mooney | but a whitebox style tempest plugin for sev would be fine | |
| 11:24:53 | sean-k-mooney | or add it to whitebox | |
| 11:25:04 | artom | sean-k-mooney, unrelated, but we had some discussion around saving the new NUMA topology in https://review.opendev.org/#/c/634606/75/nova/compute/manager.py@7223 - and in func tests at least, that instance.refresh() isn't necessary (yes, the tests check the InstanceNUMATopology) | |
| 11:25:21 | gmann | aspiers: It will be QA ecosystem. it can be done via tempest plugin or separate testing framework like extreme-testing( which never got progress ). but it will be separate project under QA with separate team. | |
| 11:25:34 | artom | sean-k-mooney, I'll try to get to the office later this morning, to see what's up with my machine, would you have the bandwidth to play around with that in the meantime in your env? | |
| 11:26:16 | sean-k-mooney | artom: since this is aparently our highest priority i can make time | |
| 11:26:23 | sean-k-mooney | what exactly do you want me to test | |
| 11:26:35 | sean-k-mooney | remove the instace.refresh | |
| 11:26:46 | artom | sean-k-mooney, I did that already in the latest patchset | |
| 11:27:02 | artom | Making sure that the new instance NUMA topology is saved in the DB | |
| 11:27:08 | sean-k-mooney | and check both the db and virsh to confrim that the state is updated correctly? | |
| 11:27:13 | sean-k-mooney | ok | |
| 11:27:29 | sean-k-mooney | ya ill do that now | |
| 11:27:41 | artom | Thank you (for the ∞'s time) | |
| 11:27:43 | artom | :) | |
| 11:28:26 | aspiers | sean-k-mooney: BTW lscpu on the guest does not mention sev at all | |
| 11:28:50 | sean-k-mooney | as i said before i have exposed the servers im using for testing via port forwarding so if you continue to have issue then you can ssh into them | |
| 11:29:12 | sean-k-mooney | aspiers: is there anything in dmidecode/dmesg to indicate sev | |
| 11:29:30 | sean-k-mooney | i though the guest had to set bit 48 to 1 to enable the encryption | |
| 11:29:36 | sean-k-mooney | for pointers | |
| 11:30:32 | aspiers | sean-k-mooney: http://paste.openstack.org/show/774681/ | |
| 11:30:36 | aspiers | doesn't even look right | |
| 11:31:45 | artom | sean-k-mooney, IIRC when I tried connecting last time I couldn't - but yeah, what's the connection info again? | |
| 11:32:09 | sean-k-mooney | https://events.linuxfoundation.org/wp-content/uploads/2017/12/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf looking at slide 12 we might be able to check it via the gurest msr | |
| 11:32:58 | sean-k-mooney | artom: i have two routter my isp one and my ubiquity one. my isp router firwall was blocking it so i truned it off and it started working | |
| 11:33:14 | aspiers | sean-k-mooney: I will ask the experts | |
| 11:34:42 | artom | sean-k-mooney, sure, but I still don't have the IP/FQDN in my bash history for some reason | |
| 11:35:06 | sean-k-mooney | artom: ya i know im looking it up in mine/my router config | |
| 11:41:27 | kashyap | aspiers: Randomly chiming in, but there is an MSR for SEV: https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html | |
| 11:41:40 | kashyap | aspiers: And it's reported via `cpuid` | |
| 11:41:47 | kashyap | "Support for SME and SEV can be determined through the CPUID instruction. The CPUID function 0x8000001f reports information related to SME:" | |
| 11:41:59 | kashyap | And: | |
| 11:42:05 | kashyap | "If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if SEV is active: [...]" | |
| 11:42:16 | aspiers | Yeah, I've already used that in the past | |
| 11:42:49 | kashyap | Ah, then disregard me. | |
| 11:42:57 | aspiers | No, the reminder is appreciated | |
| 11:43:39 | kashyap | aspiers: Your goal is to check if the instance (in the upstream CI) booted has indeed with SEV, yeah? | |
| 11:43:44 | aspiers | right | |
| 11:44:02 | aspiers | I guess the JeOS image will need to include cpuid | |
| 11:44:32 | kashyap | Isn't the JeOS (Just Enough OS, I presume) CirrOS in this case? | |
| 11:44:55 | aspiers | It's whatever tempest is configured with | |
| 11:45:07 | kashyap | (Nod) | |
| 11:47:13 | sean-k-mooney | aspiers: has one of the upstream ci provered provided you with a lable that will run on SEV hardware | |
| 11:47:41 | sean-k-mooney | aspiers: because 90% of the upstream ci cloud are proably runing intel x86_64 | |
| 11:47:57 | sean-k-mooney | although rackspace did run power for a while | |
| 11:48:19 | aspiers | sean-k-mooney: SUSE has our own SEV boxes which can run 3rd party CI | |
| 11:48:42 | sean-k-mooney | ah so its for the suse thrid party ci not for upstream | |
| 11:48:55 | aspiers | well if upstream has SEV hardware then great, but I was not expecting that any time soon | |
| 11:49:10 | sean-k-mooney | aspiers: i dont think it currely does | |
| 11:49:17 | sean-k-mooney | or at least not in a way you can target | |
| 11:49:49 | sean-k-mooney | im sure some of the clould proably have at least a small amd eypc inventory if for nothing else but there own internal validation | |
| 11:50:50 | aspiers | yeah | |
| 12:00:03 | donnyd | sean-k-mooney: have the numa jobs been running? | |
| 12:02:57 | donnyd | I saw last night it was having some inbound ssh timeout issues. | |
| 12:04:09 | sean-k-mooney | i have not checked this morning but i think clarkb kicked off a job around 4/5 am so ill see if that passed | |
| 12:04:51 | sean-k-mooney | donnyd: so that one failed at 04:54 | |