Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-08-04
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: [func test] refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088
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: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 bauzas gibi: https://paste.opendev.org/show/807890/
16:52:11 gibi \o/
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
17:01:53 bauzas ++
17:47:58 sean-k-mooney hard stoping the compute i guess is due to some configuration erro or something discovered wehn the update_provider_tree is run?
17:48:48 sean-k-mooney bauzas: the only way we allow operatros to modify the resouce provider by the way is via provider.yaml
17:49:16 sean-k-mooney if they tried to do that via plamcent or similar they are off in undefiend behavior land and get to keep what ever mangical bugs they find there
19:01:53 opendevreview Artom Lifshitz proposed openstack/nova master: WIP: PCI resize tests https://review.opendev.org/c/openstack/nova/+/803506
21:06:17 NobodyCam Good afternoon Nova folks, I am running into a situation where ironic nodes appear to available in both Ironic and Nova but when attempting to provision we are hitting errors with placement records not being cleaned up... My question is there a event we can listen for or api we can check that could be used to verify the node is ready for provisioning placement / inventory wise
21:13:02 NobodyCam I should add that we listen for compute.instance.delete.start and compute.instance.delete.end
22:59:45 opendevreview Ade Lee proposed openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519
#openstack-nova - 2021-08-05
02:21:28 opendevreview zhen proposed openstack/nova stable/victoria: Fix request path to query a resource provider by uuid https://review.opendev.org/c/openstack/nova/+/803550
06:32:49 opendevreview Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from List/Update Servers APIs https://review.opendev.org/c/openstack/nova/+/764292
06:58:02 opendevreview Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects in List Server APIs https://review.opendev.org/c/openstack/nova/+/765311
07:31:36 gibi fyi the Asia friendly nova meeting starts in 29 minutes here in the channel
07:58:49 bauzas gibi: maybe another email for telling we have an Asian friendly meeting now ?
07:58:55 bauzas (and good morning ;) )
07:59:04 gibi bauzas: morning
07:59:28 gibi I think I'm late with that mail now, but good idea
08:00:04 gibi I will note that for the next meeting
08:00:26 bauzas np
08:00:35 gibi #startmeeting nova_xtra
08:00:35 opendevmeet Meeting started Thu Aug 5 08:00:35 2021 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:00:35 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:35 opendevmeet The meeting name has been set to 'nova_xtra'
08:00:43 gibi #endmeeting
08:00:43 opendevmeet Meeting ended Thu Aug 5 08:00:43 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
08:00:43 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova_xtra/2021/nova_xtra.2021-08-05-08.00.html
08:00:43 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova_xtra/2021/nova_xtra.2021-08-05-08.00.txt
08:00:43 opendevmeet Log: https://meetings.opendev.org/meetings/nova_xtra/2021/nova_xtra.2021-08-05-08.00.log.html
08:00:46 gibi #startmeeting nova_extra

Earlier   Later