| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 21:05:20 | colby_ | mriedem: yea currently we use nova usage for billing purposes. I have gnocchi running and have not looked into if it excludes shelved instances or not from usage data | |
| 21:06:36 | sean-k-mooney | aspiers: i can only exist once in the domain https://github.com/libvirt/libvirt/blob/545b0574fd27b56f243e21711935f99160cec214/docs/schemas/domaincommon.rng#L81-L83 | |
| 21:07:54 | aspiers | sean-k-mooney: yeah, we already have code parsing that https://review.opendev.org/#/c/636318/3/nova/virt/libvirt/config.py | |
| 21:08:42 | aspiers | (which is unfinished BTW) | |
| 21:10:31 | efried | aspiers: I like MEM_ENCRYPTED_CONTEXT | |
| 21:10:51 | aspiers | efried: that's lucky, since I just did a search and replace to change everything to that ;-) | |
| 21:11:25 | efried | I agree with the gripe about _GUEST or _INSTANCE or similar. _SLOT seems too loaded with meaning, like I/O slot. | |
| 21:11:32 | aspiers | yeah fair | |
| 21:11:33 | efried | MEM_ENCRYPTION_CONTEXT would be better actually. | |
| 21:11:47 | efried | ION vs ED | |
| 21:12:01 | aspiers | oh yeah | |
| 21:12:22 | efried | otherwise it's the context that's mem-encrypted. | |
| 21:12:34 | efried | when really you want a mem encryption context | |
| 21:12:42 | efried | for your instance :) | |
| 21:12:52 | aspiers | right | |
| 21:14:17 | aspiers | efried: and the user-friendly extra spec / property name is gonna be what exactly? since we're bike-shedding :) | |
| 21:14:23 | aspiers | I'm adding that to the spec now | |
| 21:15:03 | sean-k-mooney | aspiers: hw:mem_encrypt=True | |
| 21:15:14 | sean-k-mooney | hw:mem_encrypt=sev | |
| 21:15:19 | aspiers | LOL | |
| 21:15:31 | efried | sean-k-mooney: Why the hw: prefix, out of curiosity? | |
| 21:15:33 | aspiers | well the whole point of this one is to be vendor-agnostic | |
| 21:15:54 | efried | otherwise, mem_encrypt=True is fine by me. (Is it True or true?) | |
| 21:15:59 | sean-k-mooney | because all standard flavor extraspecs are namespaced | |
| 21:16:03 | aspiers | especially since it will get mapped to resources:MEM_ENCRYPTION_CONTEXT=1 | |
| 21:16:44 | sean-k-mooney | efried:whatever the user provides we should lower case | |
| 21:17:06 | sean-k-mooney | and document "tRue" to mess with stephenfin | |
| 21:17:25 | efried | heh | |
| 21:18:07 | sean-k-mooney | im jsut catich up with the last few comment on the spec by they way | |
| 21:18:44 | efried | okay, if there's some good reason to have a prefix, and there's some good reason for that prefix to be hw:, then some variant of hw:mem_encrypt=$bool is fine with me. hw:mem_encryption would have a nice symmetry with the resource class name. | |
| 21:19:14 | sean-k-mooney | ya that would be good with me too | |
| 21:20:04 | aspiers | I like the consistency of the hw: prefix | |
| 21:20:13 | efried | btw, aspiers, can I strike this topic from the PTG agenda? | |
| 21:20:24 | efried | since it seems pretty much resolved? | |
| 21:20:35 | aspiers | efried: the spec topic? only if we get it merged before the PTG ;-) | |
| 21:20:48 | sean-k-mooney | :) | |
| 21:20:53 | aspiers | I hope I can still find an excuse to spend time in the nova room though | |
| 21:21:05 | aspiers | invent some more SEV problems for us to solve together ;-) | |
| 21:21:16 | aspiers | well I guess there's still the implementation haha | |
| 21:21:27 | aspiers | I'll just hack away in a corner and occasionally ask stupid questions | |
| 21:21:32 | sean-k-mooney | add numa to the spec somewhere. it will delay it by a decade | |
| 21:21:34 | efried | Compute capabilities traits placement request filter (mriedem) | |
| 21:21:34 | efried | aspiers: You can own this one: | |
| 21:21:39 | aspiers | sean-k-mooney: LOL | |
| 21:21:48 | aspiers | efried: uhoh :) | |
| 21:22:17 | efried | it'll actually be very closely related to what you're doing here. | |
| 21:23:06 | aspiers | well sure that sounds interesting | |
| 21:23:54 | efried | hmph, except for the wrinkle in the existing patch about not being able to get at the multiattach bool from within request_filter.py, the generic solution would be pretty easy there. | |
| 21:24:03 | sean-k-mooney | its also related in a way to the image metadata prefilteing im hoping to work on although not quite the same | |
| 21:24:29 | openstackgerrit | Merged openstack/nova stable/queens: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640198 | |
| 21:24:33 | sean-k-mooney | anyway looking at the sev spec which i just finsished again. | |
| 21:24:55 | sean-k-mooney | we proably could merge it as is and fixup the last few nits in a follow up patch | |
| 21:25:23 | sean-k-mooney | but that up to ye | |
| 21:25:38 | sean-k-mooney | i didnt see any really blocker anymore | |
| 21:25:48 | aspiers | sean-k-mooney: thanks, just got a few minor tweaks based on last few hours of discussion | |
| 21:25:57 | aspiers | I'll submit one more patch set and hopefully that will be enough | |
| 21:26:29 | sean-k-mooney | on the + side your feature already has excelent documentation | |
| 21:26:52 | aspiers | cool | |
| 21:27:08 | aspiers | oh I already got a response from Brijesh at AMD | |
| 21:27:18 | aspiers | he confirms it's 1 unit per guest | |
| 21:27:26 | sean-k-mooney | excelent | |
| 21:27:35 | aspiers | and there will always be a limit, which can be queried through the CPUID | |
| 21:27:50 | sean-k-mooney | ya that is not surprising | |
| 21:27:52 | efried | always always? | |
| 21:28:01 | efried | like, don't need the conf var always? | |
| 21:28:21 | aspiers | always always a limit | |
| 21:28:22 | aspiers | https://marc.info/?l=qemu-devel&m=155502702424182&w=2 | |
| 21:28:27 | sean-k-mooney | well i think they ment there will alway be a limit in hardware | |
| 21:28:31 | aspiers | yes | |
| 21:28:38 | sean-k-mooney | but not sure that mean we can discover it via cpuid yet | |
| 21:28:50 | aspiers | that patch exposes it in QEMU | |
| 21:29:02 | aspiers | next step would be to expose in libvirt getDomainCapabilities() | |
| 21:29:09 | aspiers | at which point we can get it in nova | |
| 21:29:26 | efried | but that would require a bump in the min qemu version and stuff... | |
| 21:29:35 | efried | which I thought was kind of already what was discussed with danpb | |
| 21:29:55 | sean-k-mooney | ok so we need to cary the config option for at least 2 years | |
| 21:31:15 | aspiers | efried: not just with danpb but already covered in the spec | |
| 21:31:21 | aspiers | sean-k-mooney: yeah most likely | |
| 21:33:13 | sean-k-mooney | jaypipes: thanks for reviewing the sriov mighration pathces :) | |
| 21:33:45 | sean-k-mooney | now if only stephenfin or maybe efried could leave the final +2+w it could merge before the ptg | |
| 21:34:03 | sean-k-mooney | or more importantly before one of the 41 conflicting patches does | |
| 21:34:19 | efried | sean-k-mooney: link please | |
| 21:34:29 | sean-k-mooney | https://review.opendev.org/#/c/629589/27 | |
| 21:34:46 | sean-k-mooney | that and https://review.opendev.org/#/c/620115/35 | |
| 21:34:53 | efried | When you say things like sriov and live migration I immediately think, "I hope someone else has got this." | |
| 21:35:27 | aspiers | sean-k-mooney, efried: BTW funnily enough Brijesh's reply when I asked why there is a limit "We have limited number of slots in memory controller, each slot gets a different encryption key." | |
| 21:35:43 | efried | hah! | |
| 21:35:45 | sean-k-mooney | ya | |
| 21:35:52 | efried | MEM_ENCRYPTION_KEY_SLOTS | |
| 21:36:06 | efried | again, pretty impl specific. Let's stick with CONTEXT | |
| 21:36:17 | aspiers | OK X-D | |
| 21:36:52 | sean-k-mooney | it had to be somthign like that e.g. they what a fix number of keys they coudl handel | |
| 21:36:57 | aspiers | yeah | |
| 21:37:27 | sean-k-mooney | with this kid of thing you donw want those stored in ram which means sticking them in a register file somewhere | |
| 21:37:56 | sean-k-mooney | and you only have so much spcae on a die to add that memory so there will always be a limit like this | |
| 21:38:19 | sean-k-mooney | at least 15/16 is resonable | |
| 21:38:47 | aspiers | right | |
| 21:38:53 | sean-k-mooney | i remember being asked to enable QOS policies with intel QAT devices at one point where the limit was 4 | |
| 21:39:00 | aspiers | haha | |
| 21:39:05 | sean-k-mooney | you could have 32 VF | |