| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-04 | |||
| 09:10:11 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360 | |
| 09:15:00 | openstackgerrit | Michael Still proposed openstack/nova master: Implement simple prometheus metrics for nova. https://review.openstack.org/640688 | |
| 09:45:50 | openstackgerrit | Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.72 https://review.openstack.org/637234 | |
| 10:13:49 | openstackgerrit | Boxiang Zhu proposed openstack/nova master: Raise error when force_raw_images and images_type are incompatible https://review.openstack.org/640271 | |
| 10:37:01 | kashyap | stephenfin: Hi, when you get a moment, I am sure a bug here is required (it might only cause confusion): https://review.openstack.org/#/c/637578/1/nova/virt/libvirt/driver.py ("Omit needless check on 'CONF.serial_console'") | |
| 10:37:35 | kashyap | (And the small refactorings we discussed there should be done as follow-ups.) | |
| 10:38:31 | aspiers | morning kashyap :) | |
| 10:38:41 | kashyap | aspiers: Morning | |
| 10:38:58 | lyarwood | mdbooth: https://review.openstack.org/#/q/topic:bug/1803961+(status:open+OR+status:merged) - can you take a look at this today if you have time? | |
| 10:39:31 | aspiers | kashyap: https://review.openstack.org/#/c/640483/1 is ready for review now | |
| 10:39:49 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix wrong consumer type in logging https://review.openstack.org/640723 | |
| 10:42:02 | kashyap | aspiers: Thanks for reworking: https://review.openstack.org/#/c/633855/7/nova/virt/libvirt/host.py | |
| 10:42:46 | kashyap | aspiers: Yep, looking at the 'emulator' one | |
| 11:01:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add nits from Id2beaa7c4e5780199298f8e58fb6c7005e420a69 https://review.openstack.org/640729 | |
| 11:01:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Rework 'config-drive' user doc https://review.openstack.org/640730 | |
| 11:01:45 | gibi | sean-k-mooney: I made some progress with the pf_interface_name auto detection but I realized that this makes the feature virt driver dependent. As far as I see xenapi also supports VF and PF passthrough but I don't know how to autodetect pf_interface_name in xenapi :/ | |
| 11:04:01 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add compute service support for attach/detach root volume https://review.openstack.org/614750 | |
| 11:05:44 | kashyap | gibi: It is OK to update a spec file retroactively, yes? Specifically something cosmetic like changing the name of config attribute | |
| 11:06:10 | kashyap | gibi: E.g. I'm suggesting the patch poster to change from 'cpu_models' to 'cpu_model_list' (to better distinguish from the existing 'cpu_model') | |
| 11:06:10 | gibi | kashyap: it is even encuraged to update the spec file if the design diverged | |
| 11:06:17 | kashyap | https://review.openstack.org/#/c/637834/4/nova/conf/libvirt.py@548 | |
| 11:06:26 | kashyap | gibi: Good, thought so. Because that's the most sensible thing. | |
| 11:06:30 | HD|Laptop | hey all | |
| 11:06:44 | HD|Laptop | is there a way to force nova to only use Cinder for all kinds of block storage, both for the images it fetches from Glance as well as for "ordinary" servers created via a simple "openstack server create" without manually allocating/attaching a Cinder volume? | |
| 11:07:57 | lyarwood | HD|Laptop: no, it has been discussed at recent Forum / PTGs etc but nothing has been worked on AFAIK. | |
| 11:08:41 | HD|Laptop | oh damn. 'cause all my compute nodes have 128GB SSDs only and that's it, for storage I have a nice 80TB QNAP NAS :'D | |
| 11:09:06 | HD|Laptop | another thing: can I somehow specify additional parameters for qemu/kvm? I need to match https://github.com/kholia/OSX-KVM/blob/master/boot-macOS.sh | |
| 11:09:18 | HD|Laptop | (and yes I do only run this on original Macs, 9x 2010-era Mac Pro cheesegraters, so I don't violate licenses) | |
| 11:10:06 | lyarwood | HD|Laptop: you can supply additional QEMU params via libvirt but I don't recall a way of doing that part via Nova | |
| 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. | |