| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Use native DictOpt for disk_cachemode https://review.opendev.org/c/openstack/nova/+/915390 | 02:38 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Validate valid cache mode at config input layer https://review.opendev.org/c/openstack/nova/+/915391 | 02:47 |
| *** srelf_ is now known as Continuity | 08:22 | |
| opendevreview | Elod Illes proposed openstack/nova stable/2023.2: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/906155 | 09:51 |
| opendevreview | Merged openstack/nova stable/2024.1: Fix nova-manage image_property show unexpected keyword https://review.opendev.org/c/openstack/nova/+/914671 | 11:03 |
| *** blarnath is now known as d34dh0r53 | 12:28 | |
| opendevreview | Merged openstack/nova stable/zed: Remove outdated comment about allocation ratios https://review.opendev.org/c/openstack/nova/+/908692 | 12:38 |
| *** mklejn_ is now known as mklejn | 12:48 | |
| bauzas | fwiesel: tkajinam: hey, which one of you both would want to start to discuss about your topics ? | 12:52 |
| bauzas | Extending memory encryption support or Nova Metadata Optimization ? | 12:53 |
| fwiesel | bauzas: No strong preference. It would just be good to be finished with the metadata optimization before the neutron cross project call. | 12:57 |
| tkajinam | the other 3 topis are mine it seems so I'm fine with metadata discussion going first | 12:57 |
| bauzas | fwiesel: tkajinam: cool, we'll start with the metadata, thanks | 12:58 |
| opendevreview | Merged openstack/nova stable/2023.1: pwr mgmt: make API into a per-driver object https://review.opendev.org/c/openstack/nova/+/913225 | 13:50 |
| opendevreview | Merged openstack/nova stable/2023.2: Fix nova-manage image_property show unexpected keyword https://review.opendev.org/c/openstack/nova/+/914765 | 14:11 |
| zigo | I still have this bug open, unaddress since 2021: https://bugs.debian.org/982241 | 14:33 |
| zigo | Can nova use something else than genisoimage? If not, it'd be a good idea to make it support xorriso ... | 14:33 |
| tkajinam | zigo, ROD switched to xorriso. probably you can follow the same patch. There is a patch to update the default but has been stall. if other distros follow that switch then we can move the defualt switch forward | 14:34 |
| zigo | tkajinam: Just switching the config option is enough? | 14:34 |
| *** gouthamr_ is now known as gouthamr | 14:35 | |
| clarkb | zigo: if that is for config drive building then I think nova can also make a fat32 instead of an iso9660 image | 14:36 |
| zigo | clarkb: Well, grep -r genisoimage points to config drive building indeed. | 14:53 |
| zigo | I'd prefer if I could just switch to xorriso easily... :/ | 14:54 |
| zigo | tkajinam: Do you have the patch handy? | 14:54 |
| tkajinam | zigo, I'm in ptg sessions so will update you sometime later | 14:54 |
| zigo | Thanks. | 14:55 |
| tkajinam | bauzas, I'll take some break during cross project discussion with neutron so please ping me when we resume nova discussions | 15:02 |
| bauzas | ++ | 15:02 |
| tkajinam | I'll try to summarize the discussion during that time, too. sorry I was mostly listening but there were some good points raised during the time | 15:02 |
| opendevreview | Merged openstack/nova stable/2023.1: Reproducer test for live migration with power management https://review.opendev.org/c/openstack/nova/+/913226 | 15:03 |
| kashyap | tkajinam: Hi, a note on that AMD SEV-ES thing: when you get time, see my comments on the spec - https://review.opendev.org/c/openstack/nova-specs/+/907702 | 15:14 |
| kashyap | tkajinam: The main question to think of is: SEV-ES processors are vulnerable to attestation attacks (see the links I provided). SEV-SNP fixes those problems. | 15:15 |
| kashyap | tkajinam: So we should be careful in not investing too much effort on something that will soon be "replaced" / taken over by its next-gen tech (SEV-SNP) | 15:16 |
| kashyap | You can write your thoughts on the spec. I mentioned my concerns there too. | 15:16 |
| tkajinam | kashyap, thanks ! | 15:17 |
| kashyap | It looks like, we won't get to that topic today. So let's keep the discussion on the Etherpad / spec :-) | 15:17 |
| kashyap | tkajinam: A year ago or so, I've spent some time testing SEV-SNP. I need to refresh on it, though. I'll do some more analysis on where are various low-level projects on it, and get back | 15:17 |
| tkajinam | (I'll post the same comments in etherpad and spec but) I agree that we should be careful about the investment. tbvh this work to support SEV-ES is more like a practice of extending the current implementation so that we can quickly work on SEV-SNP | 15:18 |
| tkajinam | once the whole implementations are merged in upstream | 15:19 |
| kashyap | Yeah, I see your point, but we shouldn't go deep into ES-specific impl details in Nova. | 15:22 |
| tkajinam | We have already built PoC with patched kernel/qemu/libvirt/openstack to test SEV-SNP and the proposal is based on the learning in that work. the items specific to SEV-ES is the detection of ES capability and additional policy flag bit in libvirt and the other parts will be reused by SEV-SNP | 15:25 |
| bauzas | tkajinam: Extending memory encryption support is planned at 1545UTC | 15:28 |
| bauzas | now this is break time | 15:28 |
| tkajinam | bauzas, ack. thanks | 15:29 |
| dansmith | melwitt: the glance encryption thing will be in the cinder room, fyi | 15:30 |
| melwitt | dansmith: ah ok, thanks | 15:30 |
| dansmith | melwitt: nowish | 15:31 |
| melwitt | oh, k | 15:31 |
| dansmith | if you can | 15:31 |
| bauzas | tobias-urdin: oh shit, just saw you weren't available neither today or tomorrow :( | 17:15 |
| bauzas | any possibility tho to join us for only one hour ? | 17:15 |
| bauzas | I can arrange ourselves on a specific time for you | 17:15 |
| bauzas | stephenfin: are you okay discussing your topic tomorrow ? | 17:17 |
| kashyap | bauzas: I missed the 17:45 slot :( But I added my thoughts in the Etherpad and the spec | 17:18 |
| bauzas | np | 17:19 |
| kashyap | tkajinam: Okay, we can talk more tomm. So you've also been testing SNP based on upstream on-list patches? I'm not sure who you mean by "we" :) | 17:21 |
| tkajinam | kashyap, sure | 17:22 |
| tkajinam | kashyap, I'm now part of a small team here in NTT DATA(my current employer), we have been using kernel/qemu/ovmf maintained in https://github.com/AMDESE (I think these contain patches proposed in lists) with libvirt and OpenStack additionally patched. | 17:24 |
| kashyap | tkajinam: Ah, I see. Nice. I work w/ some of the confidential computing folks at RHT. Although, I'm not up2date on this area now, I poked some the SEV-SNP stuff w/ `sevtool`, etc back on Oct 2022. | 17:26 |
| tkajinam | We've built a small PoC system which provides VM with its memory and disk encrypted and protected from hosts. Because we wanted some mechanism to detect any tampered bootchain elements(like kernel with any backdoor installed) we decided to use SEV-SNP which was most heading last year. I saw some works have done recently by Intel and am planning to try Intel TDX this year as well. | 17:27 |
| kashyap | s/back on/back in/ | 17:27 |
| kashyap | tkajinam: I see, nice. Do you also care about the whole attestation / measured boot thing? (I'm guessing you do) | 17:28 |
| tkajinam | kashyap, yeah, I read their articles actually during my on-boarding process. | 17:28 |
| kashyap | tkajinam: Nice. Shameless plug, I once wrote this too, but I'm a bit out-of-date now :D - https://lwn.net/Articles/838488/ | 17:29 |
| kashyap | Some of the tools mentioned at the end got deprecated, or new tools came in. And the "remote attestation" problem noted there is still a bit of a "beast" upstream, w/ various vendors coming up with their schemes. | 17:29 |
| kashyap | tkajinam: Consolidating on one approach to remote attestation seems to be a multi-year effort. | 17:30 |
| tkajinam | kashyap, yeah. we built a PoC which releases disk encryption key based on successful remote attestation, which uses attestation reports containing boot chain measurement. | 17:30 |
| tkajinam | kashyap, yeah but an interesting point is that hyperscalers already created their own services. that's why we are looking into it | 17:31 |
| tkajinam | one of our current main strategies, after we finished PoC, is to make sure we work closely with upstream and contribute anything we can. that's why I'm starting some work in nova and would probably spend some time in lower layers such as libvirt | 17:32 |
| kashyap | tkajinam: Huh, I see. So you have your own remote-attestation mechanism too? :) | 17:32 |
| kashyap | tkajinam: Do you use tools like 'sev-snp-measure'? | 17:33 |
| kashyap | tkajinam: I see, fair enough. Hyperscalars will come around once the dust settles upstream, I guess | 17:33 |
| tkajinam | I use sev-snp-measure or a few other tools for testing but mainly we built remote attestation api, which is created from the one maintained in https://github.com/confidential-containers/trustee | 17:35 |
| kashyap | tkajinam: Good to hear! BTW, I also saw your mail on the upstream 'libvirt-devel' list about exposing SEV-ES via the new 'model' element | 17:35 |
| tkajinam | yeah. that's one of the "practices" I'm doing for the overall work | 17:35 |
| tkajinam | kashyap, In our PoC we inject a script into geust which reads attestation report and send it to that remote attestation api, and then remote attestation api returns disk encryption key only when it can verify the report. | 17:36 |
| kashyap | Okay, good to know that your aim is to work with the relevant upstreams. As you know, there are many moving parts here: kernel, OVMF, QEMU, libvirt, and Nova. | 17:36 |
| tkajinam | yeah | 17:36 |
| tkajinam | honestly speaking I'm not much familiar with the lower level things like kernel or even qemu, but am hoping that I can work on more control-plane layers like libvirt or nova because resource coordination is one of the topics for which I've been working for some time. | 17:37 |
| kashyap | tkajinam: Okay, cool. One last thing before I go out: on your libvirt thing: I saw DanPB's response on using "maxESGuests" to detect number of SEV-ES availability. I also saw your response; let's see what the other maintainers say there. | 17:39 |
| tkajinam | kashyap, thanks! I was wondering if I made something wrong which caused no response for some time but probably people are just busy | 17:40 |
| kashyap | tkajinam: I'm also not an expert on those; but I work w/ KVM/QEMU/libvirt devs on other areas, so I can ping the "right person" if nedeed on an upstream thread | 17:40 |
| kashyap | tkajinam: No, you didn't do anything wrong. Dan Berrange seems to be away for a few days. | 17:41 |
| tkajinam | good to hear :-) | 17:41 |
| kashyap | tkajinam: I can ping him once he's back; I don't see him around. | 17:41 |
| tkajinam | kashyap, it'd be nice if I can have some conversations with Red Hat people working in this area, to discuss plans in both sides (if possible and interesting). I also find recent working about TDX in CentOS quite interesting and was willing to have some conversation about its status and future plan. | 17:42 |
| kashyap | tkajinam: I saw your v2; don't hesitate to send a "3rd ping" on the list after a few more days. That's how it works on that list sometimes. | 17:42 |
| tkajinam | kashyap, ack. will do ! | 17:42 |
| kashyap | tkajinam: Sure, you can join #virt on OFTC. | 17:42 |
| kashyap | tkajinam: And the SEV measurement folks hang out on Matrix, #virtee: https://virtee.io/ | 17:42 |
| kashyap | I need to step out now; back later :) | 17:43 |
| tkajinam | ok. yeah I know VirTEE but haven't looked into its communication channel. will check it ! | 17:43 |
| tkajinam | kashyap, thanks. I'm stepping away too now. Have a good day ahead :-) | 17:43 |
| opendevreview | Mark Goddard proposed openstack/nova master: Support creating servers with RBAC SGs https://review.opendev.org/c/openstack/nova/+/811521 | 18:23 |
| tkajinam | zigo, hmm. it seems the problem is a bit more tricky in debian and ubuntu. | 20:52 |
| tkajinam | xorriso package in CentOS provides the simple mkisofs command. IIUC this is a wrapper internally calls 'xorriso -as mkisofs' | 20:53 |
| tkajinam | because current nova doesn't allow adding additional options we need such single command replacing genisoimage. probably is the xorrisofs command the one ? | 20:56 |
| tkajinam | the package in CentOS provides xorriso, too, it seems, so probably switching to it is the wise option | 20:58 |
| tkajinam | I thought I saw a patch to update the default but I could not find it for some reason. | 20:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!