| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-04 | |||
| 11:10:35 | HD|Laptop | thanks :) | |
| 11:14:12 | lyarwood | HD|Laptop: yeah I can't see a way of passing extra args from Nova to libvirt and down to QEMU tbh | |
| 11:14:56 | kashyap | HD|Laptop: lyarwood: There is no way that Nova provides it either. | |
| 11:15:28 | kashyap | If you go behind libvirt (or Nova's) back and use QEMU command-line options, and if something breaks, you get to keep the pieces :-) | |
| 11:15:32 | lyarwood | kashyap: could you use a custom machine type for this? | |
| 11:16:29 | kashyap | lyarwood: Machine types won't help in this case. (They are a particular chipset with additional devices) | |
| 11:17:00 | lyarwood | kashyap: yeah just for the additional devices I mean | |
| 11:17:19 | kashyap | That's a bit too heavy-weight :-) | |
| 11:17:27 | kashyap | (Earlier typo: s/additional/default/) | |
| 11:17:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: Add initial version of metadata configuration https://review.openstack.org/640733 | |
| 11:19:31 | kashyap | lyarwood: Aside: there's already some discusions upstream to propose a separate machine type for 'x86' that is "legacy-free" | |
| 11:19:53 | kashyap | (Just like how AArch64 has a machine type called 'virt', which is expressely designed for virtual machines.) | |
| 11:23:26 | HD|Laptop | kashyap: ah damn. How is qemu called in nova, anyway? Tried to read myself through the libvirt driver, but I couldn't even find out where it gets "-machine pc-i440fx-3.1" from, there isn't even any single mention of that machine type anywhere in the nova git repository | |
| 11:23:52 | HD|Laptop | Maybe I can do a hot-patch in there... | |
| 11:25:17 | kashyap | HD|Laptop: Nova models every guest feature via libvirt classes / objects, which lets libvirt build an opinionated QEMU command-line. | |
| 11:26:26 | kashyap | HD|Laptop: No specific machine types are hard-coded in Nova, obviously. They're selected by what your host hypervisor supports | |
| 11:26:43 | mdbooth | zhubx: Are you the author of https://review.openstack.org/#/c/640271/ ? | |
| 11:26:55 | mdbooth | lyarwood: Looking now. | |
| 11:27:21 | sean-k-mooney | gibi: you are correct that it would make it virt driver dependent in a way but no more then manually adding the pf_interface_name. for xenapi the compute service i belive will be runnin in dom0 i have not deployed xen in quite a long time but i think you could use sysfs the same way. after all if the sriov_nic agent is running in dom0 and can see the interface netdevs then you can also see the vf and | |
| 11:27:22 | HD|Laptop | kashyap: ah, ok. where do I have to look for the final call to libvirt for starting the qemu process? | |
| 11:27:23 | sean-k-mooney | lookup the pf netdev the same way | |
| 11:27:46 | mdbooth | zhubx: If so, I just hit that again. I think this is the right approach and it'll be good to go if you can fix up a few things and add unit tests. | |
| 11:27:56 | kashyap | HD|Laptop: For machine type handling in Nova, see this: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4221,L4248 | |
| 11:28:12 | stephenfin | kashyap: Is required or is not required? | |
| 11:28:20 | kashyap | HD|Laptop: There is no "final call" in Nova; libvirt takes care of it. | |
| 11:28:28 | kashyap | stephenfin: Not required. | |
| 11:29:01 | kashyap | HD|Laptop: If you want additional command-line options that Nova currently doesn't have; then you have to model that into Nova by providing libvirt config class objects. | |
| 11:30:15 | kashyap | stephenfin: (Sorry, saw the typo in my sentence in the scrollback :-)) | |
| 11:30:23 | sean-k-mooney | kashyap: that is allowed to a point. we do not allow the use of the qemu:args element to be genearted to allow raw qemu commands to be added | |
| 11:30:41 | mdbooth | lyarwood: Did you speak to mriedem about removing the timestamp check from the retype tempest test? | |
| 11:30:55 | sean-k-mooney | kashyap: i have tried in the past to enable features that are not supported by libvirt yet or on older versions | |
| 11:31:33 | mdbooth | I'll take your work for it that they're flaky, but IIUC the purpose was to assert functionally that the volume contains the same data after retype. | |
| 11:31:56 | mdbooth | lyarwood: IIRC mriedem was especially keen on this. | |
| 11:32:51 | lyarwood | mdbooth: I had no idea he was attached to it tbh | |
| 11:32:57 | lyarwood | mdbooth: I'll bring it up with him this afternoon | |
| 11:33:13 | lyarwood | mdbooth: and yeah it has been pretty awful for me locally testing this | |
| 11:33:40 | mdbooth | Yeah, I can imagine. Seems to work ok in the gate, though. | |
| 11:34:07 | kashyap | sean-k-mooney: Yeah, that's what I meant: Nova not allowing libvirt's <qemu:commandline> element which allows arbitrary pass-through. | |
| 11:34:32 | sean-k-mooney | yep that is the element i was thinking of | |
| 11:34:34 | kashyap | sean-k-mooney: (And yeah, I've used it for one-off hacks in Nova in the past.) | |
| 11:35:37 | sean-k-mooney | ya i used it to demonstarte that you can run ovs-dpdk without hugepages before i got funding to have the libvirt support for file backed memory developed | |
| 11:36:28 | sean-k-mooney | i never got time to add the nova support for file backed memory the way i wanted it but redhat did it a release or two later for other uses | |
| 11:38:12 | sean-k-mooney | <qemu:commandline> is still useful for POCs of thing that will be comming soon so you can write the nova side of the feature and just swap out the xml generation code when it lands in libvirt | |
| 11:39:20 | kashyap | sean-k-mooney: Yeah, is useful in many scenarios; I consider it as a Swiss Army knife. | |
| 11:49:00 | gibi | sean-k-mooney: thanks. I think I will skip the xen support now due to the shortness of time. But I feel that I will manage to push the libvirt support today | |
| 11:51:22 | sean-k-mooney | gibi: good to hear. i ended up spending my weekend hacking time on figuring out how to get vs-code to debug eventlet code which i did but as a result i didnt get much time to look at the auto generation | |
| 11:51:49 | gibi | sean-k-mooney: no worries you helped a lot by point out the code pieces I need | |
| 11:54:32 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume https://review.openstack.org/614750 | |
| 12:10:17 | cdent | thanks for the response mdbooth, I was doing a run through of patches that touch vmware related stuff (there's an automated thingie that tells me about such stuff). I wasn't sure of the state of that one | |
| 12:10:31 | mdbooth | cdent: thanks | |
| 12:13:35 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Detach/Attach root volume API changes https://review.openstack.org/623981 | |
| 12:53:18 | kashyap | aspiers: Have you noticed this: https://www.redhat.com/archives/libvir-list/2019-February/msg01730.html (New Feature: Intel MKTME Support) | |
| 12:53:39 | kashyap | aspiers: It ("MKTME": Multi-Key Total Memory Encryption) is Intel's equivalent to AMD SEV | |
| 12:54:15 | aspiers | kashyap: ah interesting, so another alternative to the SGX approach? | |
| 12:54:59 | kashyap | aspiers: I don't know much (if anything) about Intel's SGX | |
| 12:55:26 | kashyap | aspiers: But the MKTME isn't yet merged in the kernel (https://lwn.net/Articles/758313/) | |
| 12:55:29 | kashyap | (Near as I see) | |
| 12:55:43 | kashyap | s/MKTME/"Support for MKTME"/ | |
| 12:55:59 | sean-k-mooney | SGX is intels secure enclave technology that prevent the host kernel and userpace processes form acessing meory that is in the enclave and assigend to a specifc process | |
| 12:57:27 | sean-k-mooney | the SGX enclaves are created and managed via system management mode so even the host kernel cannot read or write to if it is not the owner of the enclve but i dont be think SGX actully encrypts the memory | |
| 12:57:52 | kashyap | sean-k-mooney: Ah, thanks for the nice summary | |
| 12:59:23 | sean-k-mooney | so sgx + mktme would give someting simlar but maybe more secure then SEV as teh memory is not just encrypted but partitioned | |
| 12:59:40 | sean-k-mooney | i dont realy know anyting about mktme however | |
| 13:01:01 | artom | ~o~ | |
| 13:01:59 | mdbooth | Perhaps there's some super-small ring -1 which is allowed to do context switches? | |
| 13:04:54 | sean-k-mooney | mdbooth: by the way https://review.openstack.org/#/c/634276/ may have been related to some of the port binding issue you were having with failed migrations | |
| 13:06:10 | mdbooth | sean-k-mooney: Nice, thanks. | |
| 13:09:04 | sean-k-mooney | mdbooth:for sgx. i dont think so. memory in sgx enclaves is not swapable. so other the createing and destroying them there isnt anything that a ring -1 e.g. hypervior layer process would need to do | |
| 13:12:46 | sean-k-mooney | as far as i know the sgx enclaves are mapped into the process virtual memory via the iommu. as such i dont think there is a context switch requried for a process to acess it. that said its been 2 years since i looked at how sgx worked in detail | |
| 13:14:01 | mdbooth | lyarwood: https://review.openstack.org/#/c/639331/ | |
| 13:14:17 | mdbooth | lyarwood: I'd like to get mriedem's opinion on that. | |
| 13:15:43 | mdbooth | Grr, gerrit seems to bogosort the results of a change query. The order changes every time I look at it. | |
| 13:20:05 | openstackgerrit | Merged openstack/nova stable/rocky: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640186 | |
| 13:20:15 | openstackgerrit | Merged openstack/nova master: api-ref: explain aggregate set_metadata semantics https://review.openstack.org/640460 | |
| 13:20:23 | openstackgerrit | Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 13:26:04 | lyarwood | mdbooth: sorry was on the phone | |
| 13:26:10 | lyarwood | mdbooth: ack thanks | |
| 13:26:37 | mdbooth | lyarwood: You've had the same failure 3 times in a row on the migration tempest test, btw. | |
| 13:26:50 | mdbooth | lyarwood: failure to delete type because it's still in use. | |
| 13:26:53 | lyarwood | mdbooth: yeah clean up is racing | |
| 13:26:56 | mdbooth | Have you investigated that already? | |
| 13:27:05 | lyarwood | mdbooth: next on my list | |
| 14:00:28 | openstackgerrit | Merged openstack/nova master: Fixes race condition with privsep utime https://review.openstack.org/625741 | |
| 14:00:39 | efried | n-sch meeting now in #openstack-meeting-alt | |
| 14:04:29 | openstackgerrit | Merged openstack/nova master: Optimize populate_queued_for_delete online data migration https://review.openstack.org/639840 | |
| 14:04:36 | openstackgerrit | Merged openstack/nova master: Remove wrong description for auto resize confirm https://review.openstack.org/638357 | |
| 14:04:43 | openstackgerrit | Merged openstack/nova stable/rocky: Fix overcommit for NUMA-based instances https://review.openstack.org/633197 | |
| 14:24:48 | openstackgerrit | Jim Rollenhagen proposed openstack/nova stable/rocky: ironic: stop hammering ironic API in power sync loop https://review.openstack.org/640771 | |
| 14:24:48 | openstackgerrit | Jim Rollenhagen proposed openstack/nova stable/rocky: ironic: check fresh data when sync_power_state doesn't line up https://review.openstack.org/640772 | |
| 14:25:07 | jroll | turns out we never backported that first one >.> | |
| 14:32:28 | stephenfin | lyarwood: Could you look at https://review.openstack.org/#/c/636919/ today? | |
| 14:37:07 | mriedem | who's ready to rush some crap in | |
| 14:38:04 | sean-k-mooney | i dont know its only monday :P we have 3 whole days left to rush crap in | |
| 14:39:25 | stephenfin | mriedem: Just tell me what I need to blindly +W | |
| 14:44:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nits from Id2beaa7c4e5780199298f8e58fb6c7005e420a69 https://review.openstack.org/640729 | |
| 14:44:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: Rework 'config-drive' user doc https://review.openstack.org/640730 | |
| 14:49:04 | openstackgerrit | Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.openstack.org/621476 | |
| 14:53:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: objects: Store InstancePCIRequest.numa_policy in DB https://review.openstack.org/624444 | |
| 14:53:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: fakelibvirt: Add ability to generate fake PCI devices https://review.openstack.org/640409 | |
| 14:56:49 | mriedem | sounds like a nightmare to me | |