| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-19 | |||
| 18:02:35 | gibi | mriedem: I've replied in https://review.openstack.org/#/c/640390/5/doc/source/admin/config-qos-min-bw.rst@98 | |
| 18:07:26 | bryan_stephenson | Accoring to https://libvirt.org/formatdomain.html#elementsMemoryBacking setting "locked" reserves/locks the physical memory. One use is for DMA, which would only be useful if the memory did not move. Do we think that memory might move locations even if it is locked? | |
| 18:07:49 | aspiers | bryan_stephenson: that's what Brijesh said on the call. he said mlock(2) was just a hint | |
| 18:08:02 | aspiers | the man page makes it sound like more than that, but I don't know | |
| 18:08:15 | bryan_stephenson | Then how does DMA not get goofed up? | |
| 18:08:33 | sean-k-mooney | bryan_stephenson we use hugepage memory for dma trasfer with dpdk so i think either hugepage or setting locked expclitly would be suffient | |
| 18:08:45 | aspiers | Honestly it's beyond my paygrade ;-) | |
| 18:09:20 | bryan_stephenson | So the "locked" just calls mlock() which may not be sufficient. Is that a correct understanding? | |
| 18:09:34 | aspiers | That's what I think I heard from Brijesh | |
| 18:12:06 | sean-k-mooney | aspiers: so looking at that funtion it runtrun Unlimited if the memory is locked to this would not caluatle a valide limit for realtime guests | |
| 18:12:08 | sean-k-mooney | https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_domain.c;h=ba3fff607a93533b9b47956cc2cfa70237e7c041;hb=HEAD#l10049 | |
| 18:12:28 | openstackgerrit | Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625 | |
| 18:14:03 | efried | aspiers: Want me to throw a procedural -2 on the bottom SEV patch so you don't have to keep chasing -Ws? | |
| 18:14:18 | openstackgerrit | Merged openstack/nova master: Remove additional policy configuration details from policy doc https://review.openstack.org/644423 | |
| 18:14:25 | openstackgerrit | Merged openstack/nova master: Clarify policy shortcomings in policy enforcement doc https://review.openstack.org/643960 | |
| 18:14:31 | sean-k-mooney | aspiers: so based on https://github.com/libvirt/libvirt/blob/0ec6343a069b21178d4580688a8380dbb6d76620/docs/news-2013.html.in#L1526 | |
| 18:14:56 | sean-k-mooney | aspiers: libvirt used to set RLIMIT_MEMLOCK when you set the locked value | |
| 18:14:59 | aspiers | efried: that would be nice thanks, but depends on which you think is the bottom patch ;-) | |
| 18:15:08 | efried | aspiers: https://review.openstack.org/#/c/633855/ ? | |
| 18:15:19 | sean-k-mooney | aspiers: and it still does https://github.com/libvirt/libvirt/blob/b6aacfc435ce3b7e2665ddf5a422d2153bca88b8/src/util/virprocess.c#L749 | |
| 18:15:49 | efried | aspiers: Done, lmk if there are any stragglers not in the series that you'd like similarly tagged. | |
| 18:15:57 | aspiers | efried: yeah, I think 644554 could maybe merge pre-Stein without doing harm | |
| 18:16:05 | efried | agree | |
| 18:16:05 | aspiers | sean-k-mooney: reading | |
| 18:16:21 | efried | aspiers: if you can get that efried guy to approve it. | |
| 18:16:25 | aspiers | :) | |
| 18:16:33 | aspiers | efried: sounds like a tall order | |
| 18:17:19 | efried | aspiers: I almost did a full rewrite of that method, but I'll settle for nixing backslashes. | |
| 18:18:11 | aspiers | hrm, nix them how? | |
| 18:18:57 | efried | aspiers: Use parens, or use an if, or... | |
| 18:19:29 | aspiers | OK | |
| 18:20:04 | efried | it's just a style rule that nova likes to follow. I'm pretty sure there was a time I didn't care, but now I'm brainwashed. | |
| 18:20:09 | aspiers | sure | |
| 18:22:50 | aspiers | sean-k-mooney: seems like a key question is whether mlock(2) really is enough for SEV or not | |
| 18:26:01 | aspiers | sean-k-mooney, bbobrov: I guess there's also #libvirt | |
| 18:30:16 | sean-k-mooney | aspiers: i think its calling https://linux.die.net/man/2/setrlimit but yes let use know what they determin | |
| 18:33:24 | sean-k-mooney | but as i said before im pretry sure hard_limit is not actully locking the memory its just limiting how much memory can be locked by an unprivalaged process | |
| 18:33:58 | aspiers | sean-k-mooney: yes, I think it needs the combination of setrlimit and mlock | |
| 18:35:18 | sean-k-mooney | which https://github.com/AMDESE/AMDSEV/blob/master/xmls/sample.xml does not do :) | |
| 18:35:44 | sean-k-mooney | anyway im going to grab something to eat | |
| 18:35:49 | sean-k-mooney | be back in a bit | |
| 18:35:57 | aspiers | OK, me too. Cheers for the help! | |
| 18:49:28 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Give the policy vision document a facelift https://review.openstack.org/644615 | |
| 19:30:02 | sean-k-mooney | /away until noon gmt | |
| 19:30:19 | sean-k-mooney | extra space .... | |
| 19:45:54 | spbarbieri | I provision a server with a block_device that specifies a volume to be used as the boot volume. I'd like to use the REST API to determine if a block_device was used to boot the instance, and if so, which attached volume is the boot volume for the server. The "server details" api returns an empty "image" so I guess I can assume it used a volume as the boot device, but I don't know how to determine which attached volume is t | |
| 19:50:58 | artom | spbarbieri, you can list volume attachments with https://developer.openstack.org/api-ref/compute/?expanded=list-volume-attachments-for-an-instance-detail,show-a-detail-of-a-volume-attachment-detail#list-volume-attachments-for-an-instance, but that wouldn't tell you whether one was used for boot | |
| 19:58:45 | spbarbieri | Thanks for the pointer. When creating the server I can specify "block_device_mapping_v2.delete_on_termination". This is saved somewhere because my volume is deleted on server termination. I was hoping that the "this is the boot device" was saved there as well. But, I couldn't find it in any of the server/volume/volume_attach apis. | |
| 20:05:47 | artom | spbarbieri, I *think* boot_index is what you're looking for, but it doesn't look like we expose it anywhere in the API | |
| 20:06:03 | artom | spbarbieri, you can also tag with 'boot' as a workaround | |
| 20:14:22 | spbarbieri | yeah, boot_index would be perfect. I couldn't find it anywhere either. I'm actually trying to do this after the fact. I have a running server and I want to know which volume was used as the boot drive. I only have access to the REST API...sounds like a MacGyver episode...find the boot drive using a paperclip and some duct tape | |
| 20:23:05 | openstackgerrit | Merged openstack/nova master: Use assertXmlEqual() helper for all XML comparison tests https://review.openstack.org/641852 | |
| 20:23:13 | openstackgerrit | Merged openstack/nova stable/rocky: Allow utime call to fail on qcow2 image base file https://review.openstack.org/643011 | |
| 20:24:00 | mriedem | spbarbieri: that's eventually going to show up in the API here https://review.openstack.org/#/c/623981/24 | |
| 20:24:13 | mriedem | e.g. https://review.openstack.org/#/c/623981/24/doc/api_samples/os-volumes/v2.72/volume-attachment-detail-resp.json | |
| 20:25:56 | mriedem | if you're an admin, you could also see the OS-EXT-SRV-ATTR:root_device_name parameter in the response from the GET /servers/{server_id} API | |
| 20:26:21 | mriedem | and match that to the volume with the same device name, although those aren't guaranteed to be where the root volume is mounted in the guest | |
| 20:27:58 | spbarbieri | Thanks for the pointer to the volume-attach details. That will be helpful. I'm running against my local devstack, as admin, and I don't get that returned. I'm calling compute/v2.1/servers/{id}. | |
| 20:55:06 | melwitt | spbarbieri: are you using novaclient or openstackclient? if the latter, you need to pass the necessary compute API microversion to see the volume-attach info. i.e. --os-compute-api-version 2.3 (see https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-kilo) | |
| 20:55:35 | melwitt | s/volume-attach info/root_device_name/ | |
| 20:57:51 | spbarbieri | melwitt: I'm using Postman with direct REST API calls | |
| 21:00:28 | melwitt | spbarbieri: OK, see this doc on how to specify compute API microversion with the HTTP header https://developer.openstack.org/api-guide/compute/microversions.html#client-interaction | |
| 21:04:41 | spbarbieri | melwitt: Yes! Thanks. Adding that header works. I guess now I can match the root_device_name against all of the attached volumes to find a match. Does that seem reasonable? | |
| 21:06:24 | melwitt | spbarbieri: I think so, based on what mriedem said earlier | |
| 21:07:07 | spbarbieri | melwitt: Thank you for the help. | |
| 21:07:18 | melwitt | np, good luck | |
| 21:58:27 | openstackgerrit | melanie witt proposed openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA https://review.openstack.org/644412 | |
| 22:05:13 | efried | melwitt: it's like VOIP in the '90s. | |
| 22:05:18 | efried | or, you know, skype today. | |
| 22:05:24 | melwitt | haha, yeah | |
| 22:20:05 | mriedem | melwitt: efried: cdent: dansmith: also dumped comments in the prelude https://review.openstack.org/#/c/644412/ about vgpu | |
| 22:20:12 | mriedem | i'd either remove that or really dumb it down | |
| 22:21:00 | melwitt | mriedem: thanks | |
| 22:21:30 | efried | mriedem: The part I was concerned about: | |
| 22:21:41 | efried | admins will sometimes list resource providers | |
| 22:21:48 | mriedem | the vcenter driver also supports live migration, that's a long-standing thing that might be worth mentioning | |
| 22:21:50 | efried | Now they're gonna see two instead of one for some hosts | |
| 22:22:02 | efried | that's a user-facing manifestation of the nrp-for-vgpus thing. | |
| 22:22:12 | efried | that's the only reason I think it's worth mentioning | |
| 22:22:20 | melwitt | mriedem: ack | |
| 22:22:23 | efried | otherwise I agree there would be no reason to talk about it. | |
| 22:22:46 | efried | "We did this thing, so don't be surprised if you see two resource providers for a libvirt host with VGPUs." | |
| 22:22:58 | melwitt | I see, yeah | |
| 22:23:33 | mriedem | there is an upgrade release note for it right? so as long as we can really distill the prelude comment on that to something short and sweet | |
| 22:24:06 | efried | sorry I've been entirely ineffectual phrasing that :( I've been trying to nail down the zillion UT failures that happen when you change how ksa is mocked. Different headspace. | |
| 22:24:08 | melwitt | there is an upgrade note, but it doesn't really spell out what an admin would see as a change when they list RPs | |
| 22:24:18 | mriedem | "Upon restarting nova-compute services using the libvirt driver which expose VGPU inventory, the inventory will be moved from the root compute node resource provider to a child resource provider. See the upgrade notes for details." | |
| 22:24:40 | efried | wfm | |
| 22:24:48 | melwitt | yeah, that sounds good | |
| 22:25:16 | mriedem | how about, ""Upon restarting nova-compute services using the libvirt driver which expose VGPU inventory, the inventory will be moved from the root compute node resource provider to a child resource provider. As a result, when listing resource providers, you may see two for the same compute node where there was one before. See the upgrade notes for details." | |
| 22:25:27 | efried | even better | |
| 22:25:30 | melwitt | thumbs up | |
| 22:29:28 | openstackgerrit | Adam Spiers proposed openstack/nova master: Move libvirt calculation of machine type to utils.py https://review.openstack.org/644554 | |
| 22:34:01 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Address old TODO in claim_resources_on_destination https://review.openstack.org/644596 | |
| 22:40:07 | openstackgerrit | melanie witt proposed openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA https://review.openstack.org/644412 | |
| 22:53:23 | openstackgerrit | melanie witt proposed openstack/nova master: Add known issue for minimum bandwidth resource leak https://review.openstack.org/644694 | |
| 22:55:03 | melwitt | mriedem: gibi recommended the above is not an RC blocker, but I thought it might help to add a known issue reno about it ^ | |
| 23:04:18 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: Use SDK instead of ironicclient for node.get https://review.openstack.org/642899 | |
| 23:04:18 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP/PoC: Use openstacksdk for placement https://review.openstack.org/643664 | |
| 23:04:19 | efried | dustinc: Warning: update here ^ | |