| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-08-04 | |||
| 14:15:23 | sean-k-mooney | i think crrus can support 24-64 mb somethign in that region | |
| 14:15:47 | sean-k-mooney | kashyap: that is hte main one im concerned about currently | |
| 14:16:02 | kashyap | sean-k-mooney: You mean hw_video_ram is the thing you're concerned about? | |
| 14:16:09 | sean-k-mooney | yes | |
| 14:16:16 | kashyap | sean-k-mooney: Sure, adding a note to test that too (and summarizing what we talked here on the change) | |
| 14:16:26 | sean-k-mooney | i think the max vram that you can use with virtio is less then that for cirrus | |
| 14:16:48 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L417 | |
| 14:18:04 | kashyap | sean-k-mooney: What I'm not clear is the impact of hw_video_ram on the switch to virtio | |
| 14:20:42 | kashyap | Maybe virtio doesn't need that max vRAM. Anyway, to be tested :) | |
| 14:20:49 | sean-k-mooney | kashyap: if you had it set to 16 with cirrus it would work but when you swich to virtio you vm would not boot | |
| 14:21:15 | sean-k-mooney | kashyap: lets concirm since i tought the virt team said it did no that downstream mail thread today | |
| 14:21:17 | kashyap | Another q. is In what scenarios would one bother to set this at all? | |
| 14:21:49 | kashyap | Yes, I will ask the virt graphics maintainer about it | |
| 14:21:53 | sean-k-mooney | to improve guest performacne | |
| 14:22:22 | sean-k-mooney | it allow more frame buffers to be created in the graphic device which is need for higher resolutions | |
| 14:23:13 | sean-k-mooney | without a large enough vram allocation you can do double or triple buffing in the graphic device and xrog has to fall back to copying buffers to/from guest ram | |
| 14:24:05 | kashyap | I see; I really wonder how many users actually know this, and how many, if any at all, change this.. | |
| 14:24:44 | sean-k-mooney | kashyap: from greg " - vga compatibility mode is limited when compared to stdvga. It has | |
| 14:24:46 | sean-k-mooney | 8 MB fixed video memory, whereas stdvga has 16 MB by default can | |
| 14:24:48 | sean-k-mooney | can be configured to have more if needed (for example in case you | |
| 14:24:50 | sean-k-mooney | want use 4k). | |
| 14:24:52 | sean-k-mooney | " | |
| 14:24:55 | sean-k-mooney | that was in context of virtio-vga | |
| 14:25:04 | sean-k-mooney | vs plain vga | |
| 14:25:15 | sean-k-mooney | but i think cirrus also support more the 8MB | |
| 14:25:22 | sean-k-mooney | as does QXL | |
| 14:25:30 | kashyap | Let's confirm if Cirrus actually does | |
| 14:26:42 | sean-k-mooney | looking at https://libvirt.org/formatdomain.html#video-devices yes at least 16MB | |
| 14:26:55 | sean-k-mooney | For a guest of type "kvm", the default video is: type with value "cirrus", vram with value "16384" and heads with value "1". | |
| 14:27:59 | kashyap | sean-k-mooney: Ah, yep | |
| 14:31:02 | sean-k-mooney | lookign at https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#qxl-vga by the way qxl defaults to 64MB which was one of the reasons it perfromed better in the past then other options i know much of the improvemnts have now been surpassed by virtio-gpu or std vga | |
| 14:33:07 | sean-k-mooney | actully from the std vga section | |
| 14:33:10 | sean-k-mooney | "The linux driver supports page-flipping, so having room for 3-4 framebuffers is a good idea. The driver can leave the framebuffers in vram then instead of swapping them in and out. FullHD (1920x1080) for example needs a bit more than 8 MB for a single framebuffer, so 32 or 64 MB would be a good choice for that. " | |
| 14:33:29 | sean-k-mooney | you can see that 8MB is not quite large enough for 1080p | |
| 14:34:34 | sean-k-mooney | so without the virtio gpu driver you perfromace would likely regress goign form cirrus to virtio-vga if you tried to use a 1080p resolution today | |
| 14:43:42 | kashyap | sean-k-mooney: Back ... reading | |
| 14:45:02 | kashyap | I really doubt the seriousness of the "regression" from performance going from 'cirrus' to 'virtio-vga'. If people want performance, you better make sure you're not using deadly-old Linux, and got the virtio-gpu driver. | |
| 14:48:28 | kashyap | I'll check w/ Gerd (the author of the above post) and post my summary on the change | |
| 14:49:08 | sean-k-mooney | ack | |
| 14:56:20 | gibi | aarents: sean-k-mooney: here is the neutron drivers meeting log about deleting bound ports https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-02-14.00.log.html#l-67 | |
| 14:57:41 | gibi | the agreement was that it needs specs | |
| 15:00:05 | gibi | there is a summary in the rfe https://bugs.launchpad.net/neutron/+bug/1930866 | |
| 15:00:31 | sean-k-mooney | gibi: right that is what i recalled | |
| 15:05:46 | bauzas | gibi: I tried to look how to verify whether we would have existing allocations for VGPU RC in case the operator would modify the options but honestly it's difficult to do it as we don't provide the allocations when calling update_provider_tree() without ReshapeNeeded | |
| 15:06:40 | bauzas | honestly, we already don't support the fact that operators could modify the inventories if they modify the options | |
| 15:09:04 | bauzas | but I'll test this | |
| 15:09:20 | aarents | gibi: thank you for the links | |
| 15:17:25 | gibi | bauzas: if we cannot prevent it then at least a big red warning should be added to the docs. | |
| 15:17:35 | bauzas | agreed | |
| 15:17:48 | bauzas | I think we would then have orphaned allocations | |
| 15:18:20 | gibi | probably until the instance is deleted or migrated | |
| 15:18:26 | bauzas | gibi: we *could* try to hardstop in update_provider_tree() | |
| 15:18:58 | bauzas | which is called by the compute service just before we start the RPC service | |
| 15:19:15 | bauzas | (called by pre_start_hook) | |
| 15:19:24 | bauzas | exactly like we do for reshapes | |
| 15:19:39 | bauzas | but then we would need to pass allocations even without reshaping | |
| 15:20:02 | bauzas | or, using the ReshapeNeeded exception | |
| 15:20:05 | bauzas | like a reshape | |
| 15:20:22 | bauzas | either way, not sure I could do it in 2 days | |
| 15:22:53 | gibi | yeah I don't expect that we initiati a rehape just to reject it :) | |
| 15:23:39 | gibi | I suggest to check what will happen (e.g. orphaned allocation) and add a big warning about it in the docs | |
| 15:36:21 | bauzas | gibi: that's just what I'm testing :) | |
| 15:36:30 | gibi | coolio | |
| 15:36:34 | bauzas | fortunately I have an environment <3 | |
| 15:36:47 | bauzas | I don't know yet how long, but... :p | |
| 16:07:01 | opendevreview | Alexandre arents proposed openstack/nova master: libvirt: Abort live-migration job when monitoring fails https://review.opendev.org/c/openstack/nova/+/764435 | |
| 16:49:11 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support move ops with extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | |
| 16:50:28 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | |
| 16:50:28 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | |
| 16:51:49 | bauzas | gibi: still around ? | |
| 16:51:55 | gibi | bauzas: a bit | |
| 16:52:06 | bauzas | gibi: good news, we refuse to change the RC if the operator modifies it | |
| 16:52:11 | gibi | \o/ | |
| 16:52:11 | bauzas | gibi: https://paste.opendev.org/show/807890/ | |
| 16:52:32 | bauzas | gibi: we accept to do this if there are no allocations, but in case we have some of them, we get this ^ | |
| 16:52:49 | gibi | awesome | |
| 16:52:55 | gibi | this is what we need | |
| 16:53:01 | opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | |
| 16:53:02 | gibi | does it casue the compute to refuse to start? | |
| 16:53:06 | bauzas | the compute service continues to work, tho | |
| 16:53:13 | gibi | ;/ | |
| 16:53:14 | bauzas | gibi: no | |
| 16:53:57 | bauzas | gibi: but that's fine | |
| 16:54:04 | gibi | bauzas: do we only hit it in the periodic but not in the inithost? | |
| 16:54:18 | opendevreview | Balazs Gibizer proposed openstack/nova master: WIP support extended res req in heal port allocation https://review.opendev.org/c/openstack/nova/+/802060 | |
| 16:54:32 | bauzas | gibi: yup, because of update_provider_tree() | |
| 16:54:42 | bauzas | gibi: but this method is also called when restarting the compute | |
| 16:54:52 | bauzas | and every 60 secs | |
| 16:54:59 | bauzas | and then* | |
| 16:56:13 | gibi | OK, so we don't create orphans, we are loud in the log about the issue periodically so the admin will notice it. | |
| 16:56:20 | gibi | that is OK to me | |
| 16:56:59 | bauzas | also, when trying to delete the instance, we get an error | |
| 16:57:23 | bauzas | gibi: https://paste.opendev.org/show/807891/ | |
| 16:57:44 | bauzas | so the operator needs to first remodify the options to use again the VGPU RC | |
| 16:58:31 | gibi | auch | |
| 16:58:36 | gibi | that is ugly but meh | |
| 16:58:44 | bauzas | anyway, I'll continue to look at it | |
| 16:59:15 | bauzas | we could hardstop the compute by the exception maybe | |
| 16:59:28 | gibi | that would be ideal if possible | |
| 17:00:08 | gibi | anyhow I will drop of soon. I think you made a good progress with the mdev patches. I can look at them tomorrow again if there are updates | |